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 abilitata per impostazione predefinita per qualsiasi comunicazione tra nodi Cassandra e tra client Nodi Cassandra.
Puoi configurare l'autenticazione utilizzando combinazioni di nome utente e password posizionati direttamente nel file degli override o aggiunti a un secret di Kubernetes, come spiegato in questo argomento.
Informazioni sull'autenticazione utente Cassandra
La piattaforma ibrida utilizza Cassandra come datastore di backend per il runtime del piano di controllo. Per impostazione predefinita, qualsiasi comunicazione client con Cassandra richiedono l'autenticazione. Più utenti del cliente comunicano con Cassandra. Per questi utenti vengono fornite password predefinite. Consulta: Modifica in corso le password predefinite nel file degli override per i passaggi richiesti per cambiare le password predefinite.
Questi utenti, compreso un utente predefinito, vengono descritte di seguito:
- Utente DML: utilizzato dalla comunicazione 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 lo spazio delle chiavi creazione, aggiornamento ed eliminazione.
- Utente amministratore:utilizzato per qualsiasi attività amministrativa svolta sull'ammasso Cassandra.
- Utente Cassandra predefinito:Cassandra crea un utente predefinito quando
L'autenticazione è attivata e il nome utente è
cassandra
- Utente JMX:utilizzato per l'autenticazione e la comunicazione con JMX di Cassandra a riga di comando.
- UtenteJolokia:utilizzato per l'autenticazione e la comunicazione con Cassandra JMX tramite Google Cloud CLI o tramite l'API Compute Engine.
Informazioni sull'utente Cassandra predefinito
Quando viene creato un cluster ibrido Apigee e viene abilitata l'autenticazione Cassandra, l'account utente iniziale è l'utente Cassandra predefinito, identificato dal nome utente cassandra
. L'utente predefinito cassandra
funziona come super user, responsabile di attività quali l'aggiunta dei ruoli utente e la modifica dello schema del database.
Il job apigee-cassandra-user-setup
ibrido di Apigee utilizza l'utente cassandra
predefinito per stabilire nuovi ruoli e aggiornare la password associata a questo utente predefinito. L'esecuzione del job apigee-cassandra-user-setup
avviene durante l'installazione iniziale di un'istanza ibrida Apigee, i successivi upgrade dell'istanza e il provisioning di una nuova istanza come parte dell'espansione della regione.
Quando viene eseguito il job apigee-cassandra-user-setup
ibrido Apigee, il job deve avere la possibilità di aggiornare e modificare le configurazioni a livello di database nell'ambito di una nuova installazione o di un upgrade. L'utente cassandra
predefinito è l'unico utente garantito di essere presente quando il job apigee-cassandra-user-setup
configura i nuovi pod Cassandra. Senza un utente noto con accesso come super user, gli upgrade ibridi di Apigee e le espansioni delle regioni non funzionerebbero correttamente.
La password utente predefinita di cassandra
viene modificata dopo il primo utilizzo nell'ambito di misure di sicurezza aggiuntive. Ciò significa che anche se l'utente cassandra
predefinito è ancora attivo, la nuova password deve essere nota per poter utilizzare l'utente cassandra
predefinito. L'utente predefinito cassandra
non viene utilizzato da altri componenti, ad eccezione del job apigee-cassandra-user-setup
, nell'ambito della nuova installazione e della nuova espansione della regione.
Modifica delle password predefinite nel file degli override
Come best practice per la sicurezza, ti consigliamo di cambiare le password predefinite per Cassandra. Puoi farlo nel
overrides.yaml
. Aggiungi la seguente configurazione, modifica quella predefinita
le password in base alle tue esigenze e applica la modifica
nel tuo 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
Tieni presente quanto segue:
- La rotazione dell'autorità di certificazione (CA) non è supportata.
- Un certificato del server generato con una passphrase non è supportato.
Impostare nomi utente e password in un secret di Kubernetes
Questa sezione spiega come configurare Cassandra per l'utilizzo dei secret di Kubernetes per l'autenticazione.
Crea il secret
Utilizza il seguente modello per configurare il secret di Kubernetes. Salva il modello
in un file YAML e modificare gli attributi richiesti, ad esempio my-secret.yaml
.
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: 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
Dove SECRET_NAME è il nome che scegli per il secret, APIGEE_NAMESPACE
è lo spazio dei nomi in cui viene eseguito il deployment dei pod Apigee (il valore predefinito è apigee
),
e ogni _USERNAME e _PASSWORD sono il nome utente e la password di ogni
utente. Tieni presente che il nome utente e la 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 all'avvio di Cassandra. 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...