Cet article explique comment configurer l'authentification pour la communication entre les nœuds Cassandra et entre les clients et les nœuds Cassandra.
Procédure de configuration du protocole TLS pour Cassandra dans le plan d'exécution
Cassandra assure une communication sécurisée entre une machine cliente et un cluster de base de données, et entre les nœuds d'un cluster. L'activation du chiffrement garantit que les données en cours de transfert ne sont pas compromises et sont transférées en toute sécurité. Dans Apigee hybride, TLS est activé par défaut pour toute communication entre les nœuds Cassandra et entre les clients et les nœuds Cassandra.
Vous pouvez configurer l'authentification à l'aide de combinaisons nom d'utilisateur/mot de passe placées directement dans le fichier de remplacement ou ajoutées à un secret Kubernetes, comme expliqué dans cette rubrique.
À propos de l'authentification des utilisateurs Cassandra
La plate-forme hybride utilise Cassandra comme datastore backend pour les données du plan d'exécution. Par défaut, toute communication client vers Cassandra nécessite une authentification. Plusieurs utilisateurs communiquent avec Cassandra. Les mots de passe par défaut sont fournis à ces utilisateurs, et vous n'êtes pas obligé de les modifier.
Ces utilisateurs, y compris un utilisateur par défaut, sont décrits ci-dessous :
- Utilisateur LMD : permet à la communication du client de lire et d'écrire des données sur Cassandra (KMS, KVM, Cache et Quota).
- Utilisateur LDD : utilisé par MART pour toutes les tâches de définition de données telles que la création, la mise à jour et la suppression d'espace de clés.
- Utilisateur administrateur : utilisé pour toutes les activités d'administration effectuées sur le cluster cassandra.
- Utilisateur par défaut Cassandra : Cassandra crée un utilisateur par défaut lorsque l'authentification est activée et que le nom d'utilisateur est
cassandra. - Utilisateur JMX : permet l'authentification et la communication avec l'interface Cassandra JMX.
- Utilisateur de Jolokia : permet l'authentification et la communication avec l'API Cassandra JMX.
Modifier les mots de passe par défaut dans le fichier de remplacement
Apigee hybride fournit des mots de passe par défaut pour les utilisateurs Cassandra. Si vous souhaitez modifier les mots de passe utilisateur par défaut, vous pouvez le faire dans le fichier overrides.yaml. Ajoutez la configuration suivante, modifiez les mots de passe par défaut ("loveapis123") comme vous le souhaitez et appliquez la modification à votre cluster.
cassandra: auth: default: ## the password for the new default user (static username: cassandra) password: "iloveapis123" admin: ## the password for the admin user (static username: admin_user) password: "iloveapis123" ddl: ## the password for the DDL User (static username: ddl_user) password: "iloveapis123" dml: ## the password for the DML User (static username: dml_user) password: "iloveapis123" jmx: username: "jmxuser" ## the username for the JMX User password: "iloveapis123" ## the password for the JMX User jolokia: username: "jolokiauser" ## the username to access jolokia interface password: "iloveapis123" ## the password for jolokia user
Veuillez noter les points suivants :
- La rotation de l'autorité de certification (CA) n'est pas prise en charge.
- Un certificat de serveur généré avec une phrase secrète n'est pas accepté.
Définir les noms d'utilisateur et les mots de passe dans un secret Kubernetes
Cette section explique comment configurer Cassandra pour utiliser les secrets Kubernetes pour l'authentification.
Créer le secret
Utilisez le modèle suivant pour configurer le secret Kubernetes. Enregistrez le modèle dans un fichier et modifiez les attributs requis. Notez que si vous utilisez cette option, vous devez fournir le nom d'utilisateur pour chaque mot de passe.
apiVersion: v1 kind: Secret metadata: name: $SECRET_NAME namespace: $APIGEE_NAMESPACE type: Opaque data: default.password: $PASSWORD #base64-encoded string admin.user: $USERNAME #base64-encoded string admin.password: $PASSWORD #base64-encoded string dml.user: $USERNAME #base64-encoded string dml.password: $PASSWORD #base64-encoded string ddl.user: $USERNAME #base64-encoded string ddl.password: $PASSWORD #base64-encoded string jmx.user: $USERNAME #base64-encoded string jmx.password: $PASSWORD #base64-encoded string jolokia.user: $USERNAME #base64-encoded string jolokia.password: $PASSWORD #base64-encoded string
Où $SECRET_NAME est le nom que vous choisissez pour le secret, $APIGEE_NAMESPACE est l'espace de noms dans lequel les pods Apigee sont déployés (par défaut, apigee), $USERNAME et $PASSWORD sont les noms d'utilisateur et les mots de passe de chaque utilisateur. Notez que les noms d'utilisateur et les mots de passe doivent être encodés en base64.
Appliquez le secret au cluster. Exemple :
kubectl apply -f $SECRET_FILE
Ajoutez le secret à votre fichier de remplacement :
cassandra: auth: secret: $SECRET_NAME
Appliquez au cluster le remplacement Cassandra mis à jour :
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore
Vérifier les journaux Cassandra
Vérifiez les journaux dès le démarrage de Cassandra. Le journal ci-dessous indique que les connexions client Cassandra sont chiffrées.
kubectl logs apigee-cassandra-2 -n apigee -f INFO 00:44:36 Starting listening for CQL clients on /10.0.2.12:9042 (encrypted)... INFO 00:44:36 Binding thrift service to /10.0.2.12:9160 INFO 00:44:36 enabling encrypted thrift connections between client and server INFO 00:44:36 Listening for thrift clients...