Questo argomento spiega come configurare l'autenticazione per la comunicazione tra i nodi Cassandra e tra i client e i nodi Cassandra.
Come configurare l'autenticazione per Cassandra nel piano di runtime
Cassandra fornisce una comunicazione sicura tra una macchina client e un cluster di database e tra i nodi all'interno di un cluster. L'attivazione della crittografia garantisce che i dati in transito non vengano compromessi e vengano trasferiti in modo sicuro. In Apigee Hybrid, TLS è abilitato 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 di override o aggiunte a un secret Kubernetes, come spiegato in questo argomento.
Informazioni sull'autenticazione utente di 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 più utenti client che comunicano con Cassandra. Per questi utenti vengono fornite password predefinite. Consulta Modifica delle password predefinite nel file di override per i passaggi necessari per modificare le password predefinite.
Questi utenti, incluso un utente predefinito, sono descritti di seguito:
- Utente DML: utilizzato dal 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 di keyspace.
- 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 autenticare e comunicare con l'interfaccia JMX di Cassandra.
- Utente Jolokia:utilizzato per autenticare e comunicare con l'API Cassandra JMX.
Informazioni sull'utente Cassandra predefinito
Quando viene creato il cluster ibrido Apigee e l'autenticazione Cassandra è abilitata, l'account utente iniziale è l'utente Cassandra predefinito, identificato dal nome utente cassandra. L'utente cassandra predefinito funge da superuser, responsabile di attività quali l'aggiunta di ruoli utente e la modifica dello schema del database.
Il job Apigee Hybrid apigee-cassandra-user-setup 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 Apigee hybrid, gli upgrade successivi dell'istanza e il provisioning di una nuova istanza nell'ambito dell'espansione della regione.
Quando viene eseguito il job Apigee Hybrid apigee-cassandra-user-setup, il job deve essere in grado 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 presente quando il job apigee-cassandra-user-setup configura i nuovi pod Cassandra. Senza un utente noto con accesso superuser, gli upgrade e le espansioni delle regioni di Apigee Hybrid non funzionerebbero correttamente.
La password utente cassandra predefinita viene modificata dopo l'utilizzo iniziale 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 utilizzare l'utente cassandra predefinito. L'utente cassandra predefinito non viene utilizzato da altri componenti, ad eccezione del job apigee-cassandra-user-setup nell'ambito della nuova installazione e dell'espansione della regione.
Modifica delle password predefinite nel file di override
Come best practice per la sicurezza, ti consigliamo di modificare le password predefinite per Cassandra. Puoi farlo nel file
overrides.yaml. Aggiungi la seguente configurazione, modifica le password predefinite come preferisci e applica la modifica al cluster. Vedi
cassandra. Puoi visualizzare le password predefinite
nel file values.yaml.
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 server generato con passphrase non è supportato.
Impostazione di nomi utente e password in un secret Kubernetes
Questa sezione spiega come configurare Cassandra per utilizzare i secret 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 modifica 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 vengono implementati i pod Apigee (il valore predefinito è apigee),
e ogni _USERNAME e _PASSWORD sono i nomi utente e le password per 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 di override:
cassandra: auth: secret: SECRET_NAME
Applica l'override di Cassandra aggiornato al cluster:
Helm
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
apigeectl
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE.yaml --datastore
Controlla i log di Cassandra
Controlla i log non appena viene avviato Cassandra. Il log seguente 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...