Configurazione dell'autenticazione per Cassandra

Questo argomento spiega come configurare l'autenticazione per la comunicazione tra nodi Cassandra e tra client e nodi Cassandra.

Come configurare l'autenticazione per Cassandra nel piano di runtime

Cassandra fornisce comunicazioni sicure tra un computer client e un cluster di database e tra i nodi all'interno di un cluster. L'abilitazione 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 nome utente/password inserite direttamente nel file di override o aggiunte 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 i dati del piano di runtime. Per impostazione predefinita, qualsiasi comunicazione del client a Cassandra richiede l'autenticazione. Esistono diversi utenti client che comunicano con Cassandra. Per questi utenti vengono fornite le password predefinite. Consulta la pagina relativa alla 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:

  1. Utente DML: utilizzato dal client per leggere e scrivere dati in Cassandra (KMS, KVM, cache e quota).
  2. Utente DDL:utilizzato da MART per qualsiasi attività di definizione dei dati, come la creazione, l'aggiornamento e l'eliminazione dello spazio delle chiavi.
  3. Utente amministratore:utilizzato per qualsiasi attività amministrativa eseguita nel cluster cassandra.
  4. Utente Cassandra predefinito:Cassandra crea un utente predefinito quando l'autenticazione è abilitata e il nome utente è cassandra
  5. Utente JMX:utilizzato per l'autenticazione e la comunicazione con l'interfaccia JMX di Cassandra.
  6. Utente Jolokia: utilizzato per l'autenticazione e la comunicazione 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 predefinito di cassandra funziona come super user, responsabile di attività quali l'aggiunta di ruoli utente e la modifica dello schema del database.

Il job di 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 ibrida Apigee, i successivi upgrade dell'istanza e il provisioning di una nuova istanza nell'ambito dell'espansione della regione.

Quando viene eseguito il job di Apigee hybrid apigee-cassandra-user-setup, il job deve poter 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 che sarà presente quando il job apigee-cassandra-user-setup configura i nuovi pod Cassandra. Senza un utente noto con accesso come super user, gli upgrade di Apigee ibridi e le espansioni della regione 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 l'utilizzo dell'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 cambiare le password predefinite per Cassandra. Puoi farlo nel file overrides.yaml. Aggiungi la configurazione seguente, cambia le password predefinite come preferisci e applica la modifica al cluster. Consulta la pagina 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 del server generato con una passphrase non è supportato.

Impostazione di 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 modello seguente 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 specificare i nomi utente per 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), mentre _USERNAME e _PASSWORD sono i nomi utente e le 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 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 all'avvio di 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...