Configurer mTLS natif de Cassandra

Introduction

Par défaut, différents composants d'Edge for Private Cloud, tels que les processeurs de messages, les serveurs de gestion et les routeurs, se connectent aux nœuds Cassandra via un canal en texte brut. Sur ces canaux, les données envoyées à et depuis Cassandra sont communiquées en clair. Apigee mTLS est une fonctionnalité basée sur le maillage de services Consul qui renforce la sécurité des communications entre les composants du cluster Edge pour le cloud privé. Cette offre d'Apigee ajoute également la sécurité TLS au canal de communication entre les composants client et Cassandra.

Cet article présente une nouvelle offre alternative d'Apigee, dans laquelle la communication entre les composants client et Cassandra dans Edge pour le cloud privé est sécurisée via TLS mutuel (également appelé TLS bidirectionnel) à l'aide de fonctionnalités disponibles nativement dans Cassandra, sans utiliser de maillage de services externe.

Fonctionnalité mTLS native

L'activation de mTLS entre Cassandra et les composants client décrits dans cet article repose sur les fonctionnalités TLS fournies en mode natif par Apache Cassandra. Lorsqu'il est activé, les connexions client à Cassandra (sur le port de transport natif CQL 9042) effectuent un handshake TLS bidirectionnel avec les clients avant d'autoriser l'établissement de connexions. Pour cette connexion TLS bidirectionnelle, Cassandra fait office de serveur et les différents clients qui se connectent à Cassandra (comme edge-message-processor, l'outil cqlsh, etc.) font office de clients.

Pour le protocole TLS bidirectionnel (ou TLS mutuel ou mTLS), Cassandra et les clients doivent être configurés avec leur propre keystore. Le keystore de chaque nœud Cassandra doit contenir sa propre clé et son propre certificat. Le keystore de chaque application cliente doit contenir la clé et le certificat spécifiques à ce client. Un truststore contenant les certificats et la chaîne associée de la contrepartie doit être ajouté à Cassandra et aux clients. Le truststore de chaque nœud Cassandra doit contenir les certificats des clients, et le truststore de chaque client doit contenir les certificats de tous les nœuds Cassandra. Pour en savoir plus sur le fonctionnement général du handshake TLS bidirectionnel, consultez l'article sur le protocole TLS/SSL bidirectionnel d'Apigee.

Chaînage de certificats

En général, dans le protocole TLS bidirectionnel, les certificats de serveur, les certificats de client, les chaînes de certificats, les keystores et les truststores peuvent être créés de différentes manières. Il en va de même pour Cassandra et le mTLS natif du client. Compte tenu de la façon dont les organisations exploitent généralement les clusters Edge pour le cloud privé et du nombre de paires uniques de connexions client-Cassandra pouvant être établies, Apigee recommande d'adopter l'approche générale suivante pour configurer les clés et les certificats pour cette fonctionnalité. Il existe d'autres méthodes viables, mais celle ci-dessous offre probablement un bon équilibre entre sécurité et charge de maintenance.

  1. Obtenez un certificat racine et une paire clé/certificat intermédiaire signée par la racine. Il est possible que vous possédiez déjà de telles clés et de tels certificats. Sinon, vous pouvez créer des clés et des certificats racine et intermédiaires autosignés en suivant les étapes de l'annexe 1.

  2. Utilisez la clé/le certificat intermédiaire commun ci-dessus pour signer toutes les clés et tous les certificats spécifiques à l'application (feuille).

Le fait d'avoir une clé/un certificat intermédiaire commun dans un cluster permet de configurer un truststore commun (contenant la même chaîne de certificats racine et intermédiaire) sur chaque nœud Cassandra et client. Chaque nœud Cassandra et chaque application cliente reçoit sa propre clé et son propre certificat de feuille uniques, signés par la clé/le certificat intermédiaire commun.

  1. La rotation d'un certificat feuille d'un nœud Cassandra ou d'une application cliente est simple.
  2. La rotation d'un certificat intermédiaire ou racine reste une opération assez complexe, mais la fréquence de ces rotations sera beaucoup plus faible que celle des certificats feuille.

Utilisez les pratiques de sécurité de votre organisation pour décider d'utiliser ou non des certificats racine et intermédiaires communs dans différents clusters de cloud privé. Pour d'autres configurations de certificats, consultez l'Annexe 2.

Les étapes restantes de cet article fournissent des informations détaillées sur la méthodologie ci-dessus pour concevoir des clés et des certificats.

Limites et mises en garde

Les limites suivantes s'appliquent à cette fonctionnalité.

  • Cette offre de mTLS natif entre les composants client et Cassandra n'est PAS compatible avec apigee-mtls. Si vous utilisez cette fonctionnalité, vous ne pouvez pas utiliser apigee-mtls et vice versa.
  • L'activation de mTLS entre les composants client et Cassandra aura un impact sur les performances des connexions établies entre les clients et Cassandra. Les opérations telles que le démarrage des clients ou la mise à l'échelle des connexions Cassandra peuvent être plus lentes, car Cassandra et les clients doivent d'abord négocier TLS avant de commencer à communiquer. L'impact devrait être minime et généralement imperceptible.
  • Sur Cassandra, mTLS peut être appliqué aux connexions client entrantes. Bien que l'application puisse être activée, elle doit être désactivée lors des tâches opérationnelles telles que les mises à niveau du logiciel Apigee, l'activation/la désactivation des fonctionnalités TLS et certains types de rotations de certificats. Pour en savoir plus, consultez la section Opérations et configurations.
  • Il incombe au client de gérer et de conserver les certificats.
  • La rotation des certificats présente différentes nuances. Pour en savoir plus, consultez la section Rotation des certificats.

Activer l'authentification mTLS native

Dans les grandes lignes, l'activation de l'authentification mTLS native se déroule en trois étapes, comme décrit ci-dessous :

  1. Obtenez un certificat racine et une paire clé/certificat intermédiaire.
  2. Créez une paire clé/certificat feuille pour un nœud Cassandra, signez-la, stockez-la dans un keystore et configurez Cassandra pour le mTLS facultatif. Répétez les étapes pour chaque nœud Cassandra, un à la fois.
  3. Créez une paire clé/certificat d'entité finale pour une application cliente, signez-la, stockez-la dans un keystore et configurez l'application cliente pour mTLS. Répétez ces étapes pour chaque application cliente, une par une. Applications clientes :
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

Voici les étapes à suivre :

Obtenir des certificats racine et intermédiaires

Obtenez un certificat racine et une paire clé/certificat intermédiaire signée par la racine. Utilisez le certificat racine et intermédiaire signé par l'autorité de certification de votre organisation, ou créez des certificats autosignés. Stockez la chaîne de certificats racine et intermédiaire dans un truststore. Pour obtenir des commandes utiles, consultez l'Annexe 1. Les commandes suivantes supposent que vous avez accès aux fichiers suivants :

  • intermediate.key : fichier de clé pour le certificat intermédiaire permettant de signer les certificats de feuille
  • intermediate-cert.pem : certificat intermédiaire

Configurer les nœuds Cassandra

  1. Choisir un nœud Cassandra
  2. Générez une paire clé/certificat de feuille et signez-la avec le certificat intermédiaire. Stockez la clé et le certificat signé dans un keystore. En voici un exemple : 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    Placez les fichiers keystore et truststore dans un emplacement spécifique du nœud et assurez-vous qu'ils sont accessibles par l'utilisateur Apigee. 

    cp cass-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties. Ajoutez le contenu suivant dans ce fichier : 
    ### Enable Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=true

### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

### Keystore details
conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
conf_cassandra_client_encryption_keystore_password=keystorepass
conf_cassandra_server_encryption_store_type=PKCS12

### Whether to enable 2-way TLS (or mTLS) - true or false
conf_cassandra_client_encryption_require_client_auth=true

### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_client_encryption_truststore_password=trustpass
conf_cassandra_client_encryption_store_type=PKCS12

    En outre, pour les systèmes d'exploitation compatibles avec FIPS, ajoutez la propriété suivante au fichier /opt/apigee/customer/application/cassandra.properties : 

    conf_cassandra_client_encryption_protocol=TLSv1.2

    Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire :

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Configurer et redémarrer le nœud Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  5. Répétez les étapes ci-dessus sur chaque nœud Cassandra, un à la fois.

Configurer les applications clientes

Cette section s'applique aux composants client suivants qui se connectent à Cassandra :

  • edge-management-server
  • edge-message-processor
  • edge-router

  1. Sélectionnez un composant client
  2. Générez une paire clé/certificat de feuille et signez-la avec le certificat intermédiaire. Stockez la clé et le certificat signé dans un keystore. En voici un exemple : 
    
# Generate Leaf key and csr
openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"

# leaf cert signed by intermediate
openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem

# keystore packaging leaf key and cert
openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    Placez les fichiers keystore et truststore dans un emplacement spécifique du nœud et assurez-vous qu'ils sont accessibles par l'utilisateur Apigee.

    cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
cp truststore.pfx /opt/apigee/customer/application/

chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. Créer et modifier un fichier de configuration en fonction de l'application que vous configurez
    Application Fichier de configuration
    Serveur de gestion /opt/apigee/customer/application/management-server.properties
    Processeur de gestion /opt/apigee/customer/application/message-processor.properties
    Routeur /opt/apigee/customer/application/router.properties

    Ajoutez les configurations suivantes dans le fichier : 

    ### Enable TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=true
conf_cassandra_sslconfig.enable.mtls=true

### Keystore Details
conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
conf_cassandra_sslconfig.keystore.password=keystorepass
conf_cassandra_sslconfig.keystore.type=PKCS12

### Truststore Details
conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
conf_cassandra_sslconfig.truststore.password=trustpass
conf_cassandra_sslconfig.truststore.type=PKCS12

    Assurez-vous que le fichier de configuration appartient à l'utilisateur Apigee et qu'il peut le lire. 

    chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties

  4. Redémarrez l'application cliente. 
    # Configure and restart service:
apigee-service component configure
apigee-service component restart
# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
  5. Vous pouvez vérifier que SSL a été correctement configuré dans l'application cliente en recherchant des journaux semblables à ceux ci-dessous dans le journal système de l'application concernée :

    Options SSL ajoutées à la connexion Cassandra

  6. Répétez les étapes ci-dessus pour chaque application cliente, une par une.

Opérations et configurations

Appliquer mTLS

Lorsque mTLS n'est pas appliqué dans Cassandra, Cassandra accepte les connexions en texte brut des clients ou des clients avec lesquels il peut effectuer un handshake TLS bidirectionnel. Pour que l'application de mTLS fonctionne, mTLS doit d'abord être configuré dans Cassandra. Pour configurer l'application mTLS dans Cassandra, procédez comme suit :

  1. Choisir un nœud Cassandra
  2. Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties. Ajoutez ou modifiez la propriété suivante dans ce fichier : 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=false

    Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Configurer et redémarrer le nœud Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. Répétez les étapes ci-dessus sur chaque nœud Cassandra, un à la fois.

Une fois que mTLS est appliqué dans Cassandra, l'outil de requête Cassandra standard cqlsh ne peut pas se connecter directement à Cassandra. Pour configurer cqlsh pour SSL, générez une clé et un certificat de feuille (semblables à la clé et au certificat de feuille pour les applications clientes), puis procédez comme suit :

  1. Créer ou modifier le fichier $HOME/.cassandra/cqlshrc
  2. Ajoutez le contenu suivant au fichier : 
    [ssl]
certfile = /home/admin-user/certs/inter-root.pem
validate = false
userkey = /home/admin-user/certs/cqlsh1.key
usercert = /home/admin-user/certs/cqlsh1-cert.pem
    • certfile : fichier de certificat contenant la chaîne de certificats racine et intermédiaire
    • userkey : clé client à utiliser par cqlsh. Il doit s'agir d'une paire clé/certificat de feuille que vous pouvez générer et signer avec le certificat intermédiaire.
    • usercert : certificat client à utiliser par cqlsh. Il doit s'agir d'une clé/d'un certificat feuille que vous pouvez générer et signer avec le certificat intermédiaire.
  3. Exécutez la commande cqlsh comme d'habitude en fournissant l'argument --ssl. Par exemple : 
    $  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
Connected to Apigee at X.X.X.X:9042
[cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>

Désactiver l'application de l'authentification mTLS sur Cassandra

Pour désactiver l'application de mTLS dans Cassandra, procédez comme suit :

  1. Choisir un nœud Cassandra
  2. Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties. Ajoutez ou modifiez la propriété suivante dans ce fichier : 
    ### Optional TLS - true or false
conf_cassandra_client_encryption_optional=true

    Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire.

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  3. Configurer et redémarrer le nœud Cassandra 
    apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
  4. Répétez les étapes ci-dessus sur chaque nœud Cassandra, un à la fois.

Désactiver l'authentification mTLS native

La désactivation de l'authentification mTLS native est un processus en plusieurs étapes, semblable à l'activation de l'authentification mTLS native. Voici les principales étapes à suivre :

  1. Désactivez l'application de l'authentification mTLS dans Cassandra (si elle est appliquée).
  2. Désactivez mTLS dans tous les nœuds des applications clientes suivantes, un par un :
    • edge-management-server
    • edge-message-processor
    • edge-router
    1. Créez et modifiez le fichier de configuration en fonction de l'application que vous configurez :
      Application Fichier de configuration
      Serveur de gestion /opt/apigee/customer/application/management-server.properties
      Processeur de gestion /opt/apigee/customer/application/message-processor.properties
      Routeur /opt/apigee/customer/application/router.properties
    2. Ajoutez ou modifiez les propriétés suivantes dans le fichier de configuration : 
      ### TLS on CQL connections
conf_cassandra_sslconfig.enable.tls=false
conf_cassandra_sslconfig.enable.mtls=false
    3. Assurez-vous que le fichier de configuration appartient à l'utilisateur Apigee et qu'il peut le lire : 
      chown apigee:apigee configuration file

### Example:
chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. Redémarrez l'application cliente : 
      
# Configure and restart service:
apigee-service component configure
apigee-service component restart

# Example, to configure and restart message processor application
apigee-service edge-message-processor configure
apigee-service edge-message-processor restart
    5. Répétez les étapes #a à #d sur chaque application cliente, une par une.
  3. Désactivez l'authentification mTLS sur tous les nœuds Cassandra, un par un :
    1. Choisissez un nœud Cassandra.
    2. Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties. Ajoutez ou modifiez la propriété suivante dans ce fichier : 
      ### Cassandra TLS on CQL connections
conf_cassandra_client_encryption_enabled=false

      Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire.

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    3. Configurer et redémarrer le nœud Cassandra
      4. apigee-service apigee-cassandra configure
apigee-service apigee-cassandra restart
    4. Répétez les étapes #a à #c sur chaque nœud Cassandra, un à la fois.

Rotation des certificats

Rotation pour les certificats feuille uniquement (en conservant les mêmes certificats intermédiaires et racines)

Vous pouvez suivre des étapes semblables à celles de la section Configurer les applications clientes :

  1. Générer une clé/un certificat feuille pour une application à l'aide de la même clé/du même certificat intermédiaire
  2. Configurez le chemin d'accès à la nouvelle clé/au nouveau certificat de feuille dans l'application, ainsi que le mot de passe et le type de keystore.
  3. Redémarrer l'application
Rotation des certificats racines ou intermédiaires

Si vous prévoyez de faire tourner un certificat intermédiaire ou racine, il est recommandé de le faire en plusieurs étapes :

  1. Désactivez le protocole mTLS natif de Cassandra dans votre cluster.
  2. Utilisez les nouveaux certificats racine et intermédiaire pour générer des certificats feuille ou d'application.
  3. Suivez la procédure pour activer mTLS natif Cassandra à l'aide du nouvel ensemble de clés et de certificats.

Opérations Apigee générales

Pour effectuer des opérations Apigee générales, comme la mise à niveau du logiciel Apigee, l'ajout ou la suppression de nœuds Cassandra, l'ajout ou la suppression de centres de données, l'activation ou la désactivation de l'authentification Cassandra, etc., assurez-vous que mTLS n'est pas appliqué dans Cassandra. Si vous avez appliqué mTLS, désactivez l'application avant de poursuivre ces opérations.

Annexe 1

Vous pouvez suivre les étapes de cet appendice pour générer une paire clé/certificat racine et intermédiaire autosignée, et ajouter cette chaîne de certificats à un truststore.

Générer des certificats racine et intermédiaires autosignés

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

Générer un truststore

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

Annexe 2 : Autres configurations de chaînes de certificats

Cet article recommande une configuration de chaîne de certificats particulière qui équilibre la sécurité et la facilité d'utilisation. Toutefois, d'autres configurations existent et sont décrites ci-dessous. La plupart des principes généraux s'appliquent également à d'autres méthodologies, par exemple :

  1. Avoir des clés et des certificats feuilles directs pour chaque nœud ou application cliente Cassandra (sans certificat racine ni certificat intermédiaire de signature). Cela compliquera probablement la rotation des certificats.
  2. Avoir plusieurs ensembles racine et intermédiaire pour différents cas d'utilisation. Par exemple, les nœuds Cassandra disposent d'un ensemble de certificats racine/intermédiaires à l'aide duquel tous les certificats feuille de Cassandra sont signés. De même, toutes les applications clientes peuvent disposer d'un ensemble racine/intermédiaire distinct pour signer les certificats feuille des applications. Ces configurations sont viables, mais impliquent d'ajouter la chaîne de certificats racine/intermédiaires au truststore approprié. Dans cet exemple, les truststores de Cassandra doivent contenir les certificats racine/intermédiaires du client, et les applications clientes doivent avoir la chaîne racine/intermédiaire des nœuds Cassandra dans leur truststore.
  3. Comme indiqué ci-dessus, vous pouvez disposer de plusieurs ensembles de certificats racine et intermédiaires pour différentes régions. Toutefois, tous les clients et tous les serveurs de toutes les régions doivent être informés de toutes les chaînes racine et intermédiaires en les ajoutant toutes au truststore configuré.