Configurazione di TLS per Cassandra

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

Come configurare TLS 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'abilitazione della crittografia assicura che i dati in corso non siano compromessi e vengano trasferiti in modo sicuro. In Apigee ibrido, TLS è abilitato per impostazione predefinita per qualsiasi comunicazione tra i nodi Cassandra e tra client e nodi Cassandra.

Puoi configurare l'autenticazione utilizzando combinazioni nome utente/password, posizionate direttamente nel file delle sostituzioni o aggiunte a un secret di 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, tutte le comunicazioni client a Cassandra richiedono l'autenticazione. I clienti che comunicano con Cassandra utilizzano tre utenti. Vengono fornite password predefinite per questi utenti e non devi cambiarle.

Questi utenti, incluso un utente predefinito, sono descritti di seguito:

• Utente DML: utilizzato dalla comunicazione client per leggere e scrivere dati su 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 spazi dei tasti.
• Utente amministratore: utilizzato per qualsiasi attività amministrativa eseguita sul cluster cassandra.
• Utente predefinito di Cassandra: Cassandra crea un utente predefinito quando Authentication è abilitato e il nome utente è cassandra
• JMX User:utilizza questo metodo per eseguire l'autenticazione e comunicare con l'interfaccia di Cassandra JMX.
• Jolokia User: utilizzato per l'autenticazione e la comunicazione con l'API Cassandra JMX.

Modificare le password predefinite nel file delle sostituzioni

Apigee ibrido fornisce password predefinite per gli utenti di Cassandra. Se vuoi cambiare le password utente predefinite, puoi farlo nel file overrides.yaml. Aggiungi la configurazione seguente, cambia le password predefinite ("iloveapis123") come preferisci e applica la modifica al tuo cluster.

Nota: puoi modificare queste impostazioni predefinite solo al momento della configurazione iniziale. Non è possibile ruotare o cambiare la password dopo la configurazione ibrida.

Tutti i nomi utente devono essere minuscoli e non sono consentiti caratteri speciali.

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.
• Non è supportato un certificato server generato con passphrase.

Impostazione di 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 modello seguente per configurare il secret di Kubernetes. Salva il modello in un file e modifica gli attributi obbligatori. Tieni presente che, se utilizzi questa opzione, devi fornire i nomi utente 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 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 $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 tuo file di 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 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...