Questo argomento spiega come configurare l'autenticazione per la comunicazione tra Nodi Cassandra e tra client e nodi Cassandra.
Configurare TLS per Cassandra nel piano di runtime
Cassandra fornisce comunicazioni sicure tra un computer client e un database cluster e tra i nodi all'interno di un cluster. L'abilitazione della crittografia garantisce che i dati mentre è in transito non viene compromesso e viene trasferito in modo sicuro. In Apigee Hybrid, TLS è attivo per impostazione predefinita per qualsiasi comunicazione tra i nodi Cassandra e tra i client e i nodi Cassandra.
Puoi configurare l'autenticazione utilizzando combinazioni di nome utente/password inserite direttamente nel file delle sostituzioni o aggiunte a un secret Kubernetes, come spiegato in questo argomento.
Informazioni sull'autenticazione utente Cassandra
La piattaforma ibrida utilizza Cassandra come datastore di backend per i dati del piano di runtime. Per impostazione predefinita, qualsiasi comunicazione del client con Cassandra richiede l'autenticazione. Esistono tre utenti utilizzati dai clienti che comunicano con Cassandra. Per questi utenti vengono fornite le password predefinite e tu non devi necessario per modificarle.
Questi utenti, compreso un utente predefinito, vengono descritte di seguito:
- Utente DML: utilizzato dalla comunicazione con il client per leggere e scrivere dati in Cassandra (KMS, KVM, Cache e Quota).
- Utente DDL: utilizzato da MART per qualsiasi attività di definizione dei dati, come la creazione, l'aggiornamento e l'eliminazione dello spazio chiavi.
- Utente amministratore: utilizzato per qualsiasi attività amministrativa eseguita sul cluster Cassandra.
- Utente Cassandra predefinito: Cassandra crea un utente predefinito quando l'autenticazione è abilitata e il nome utente è
cassandra - Utente JMX: utilizzato per autenticarsi e comunicare con l'interfaccia JMX di Cassandra.
- UtenteJolokia:utilizzato per l'autenticazione e la comunicazione con Cassandra JMX tramite Google Cloud CLI o tramite l'API Compute Engine.
Modifica delle password predefinite nel file delle sostituzioni
Apigee hybrid fornisce password predefinite per gli utenti Cassandra. Se vuoi modificare
le password utente predefinite, puoi farlo nel
overrides.yaml. Aggiungi la seguente configurazione, modifica le password predefinite ("iloveapis123") come preferisci e applica la modifica al tuo 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
Tieni presente quanto segue:
- La rotazione dell'autorità di certificazione (CA) non è supportata.
- Un certificato del server generato con passphrase non è supportato.
Impostare nomi utente e password in un secret di Kubernetes
Questa sezione spiega come configurare Cassandra per utilizzare i secret di Kubernetes per l'autenticazione.
Crea il secret
Utilizza il seguente modello per configurare il secret di Kubernetes. Salva il modello a un file e modifica gli attributi richiesti. Tieni presente che, se utilizzi questa opzione, devi fornire i nomi utente con ogni password.
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
dove $SECRET_NAME è il nome scelto per il secret, $APIGEE_NAMESPACE
è lo spazio dei nomi in cui vengono dipartiti i pod Apigee (il valore predefinito è apigee) e $USERNAME
e $PASSWORD sono i nomi utente e le password di ciascun utente. Tieni presente che
nome utente e password devono essere codificati in Base64.
Applica il secret al cluster. Ad esempio:
kubectl apply -f $SECRET_FILE
Aggiungi il secret al file degli override:
cassandra: auth: secret: $SECRET_NAME
Applica l'override di Cassandra aggiornato al cluster:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore
Controlla i log di Cassandra
Controlla i log non appena Cassandra si avvia. Il log riportato di seguito mostra che Le connessioni client Cassandra sono criptate.
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...