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. Des mots de passe par défaut sont fournis à ces utilisateurs. Pour connaître la procédure à suivre pour modifier les mots de passe par défaut, consultez Modifier les mots de passe par défaut dans le fichier de remplacement.
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.
À propos de l'utilisateur Cassandra par défaut
Lorsque le cluster hybride Apigee est créé et que l'authentification Cassandra est activée, le compte utilisateur initial est l'utilisateur Cassandra par défaut, identifié par le nom d'utilisateur cassandra. L'utilisateur cassandra par défaut fonctionne comme un super-utilisateur, responsable de tâches telles que l'ajout de rôles utilisateur et la modification du schéma de base de données.
Le job Apigee hybrid apigee-cassandra-user-setup utilise l'utilisateur par défaut cassandra pour établir de nouveaux rôles et mettre à jour le mot de passe associé à cet utilisateur par défaut. L'exécution du job apigee-cassandra-user-setup a lieu lors de l'installation initiale d'une instance Apigee hybrid, des mises à niveau ultérieures de l'instance et du provisionnement d'une nouvelle instance dans le cadre de l'expansion de la région.
Lorsque le job Apigee hybrid apigee-cassandra-user-setup est exécuté, il doit pouvoir mettre à jour et modifier les configurations au niveau de la base de données dans le cadre d'une nouvelle installation ou d'une mise à niveau. L'utilisateur cassandra par défaut est le seul utilisateur dont la présence est garantie lorsque le job apigee-cassandra-user-setup configure les nouveaux pods Cassandra. Sans utilisateur connu disposant d'un accès super-utilisateur, les mises à niveau et les expansions de région Apigee hybrid ne fonctionneraient pas correctement.
Le mot de passe utilisateur cassandra par défaut est modifié après l'utilisation initiale dans le cadre de mesures de sécurité supplémentaires. Autrement dit, même si l'utilisateur par défaut cassandra est toujours activé, le nouveau mot de passe doit être connu pour utiliser l'utilisateur cassandra par défaut. L'utilisateur cassandra par défaut n'est utilisé par aucun autre composant, à l'exception du job apigee-cassandra-user-setup dans le cadre de la nouvelle installation et de l'expansion de région.
Modifier les mots de passe par défaut dans le fichier de remplacement
Pour des raisons de sécurité, nous vous recommandons de modifier les mots de passe par défaut pour Cassandra. Vous pouvez le faire dans le fichier overrides.yaml. Ajoutez la configuration suivante, modifiez les mots de passe par défaut comme vous le souhaitez et appliquez la modification à votre cluster.
cassandra: auth: default: ## the password for the new default user (static username: cassandra) password: "NEW_PASSWORD" admin: ## the password for the admin user (static username: admin_user) password: "NEW_PASSWORD" ddl: ## the password for the DDL User (static username: ddl_user) password: "NEW_PASSWORD" dml: ## the password for the DML User (static username: dml_user) password: "NEW_PASSWORD" jmx: username: "jmxuser" ## the username for the JMX User password: "NEW_PASSWORD" ## the password for the JMX User jolokia: username: "jolokiauser" ## the username to access jolokia interface password: "NEW_PASSWORD" ## 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 YAML et modifiez les attributs requis, par exemple my-secret.yaml.
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: DEFAULT_PASSWORD #base64-encoded string admin.user: ADMIN_USERNAME #base64-encoded string admin.password: ADMIN_PASSWORD #base64-encoded string dml.user: DML_USERNAME #base64-encoded string dml.password: DML_PASSWORD #base64-encoded string ddl.user: DDL_USERNAME #base64-encoded string ddl.password: DDL_PASSWORD #base64-encoded string jmx.user: JMX_USERNAME #base64-encoded string jmx.password: JMX_PASSWORD #base64-encoded string jolokia.user: JOLOKIA_USERNAME #base64-encoded string jolokia.password: JOLOKIA_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...