Authentifizierung für Cassandra konfigurieren

In diesem Thema wird erläutert, wie Sie die Authentifizierung für die Kommunikation zwischen Cassandra-Knoten und zwischen Clients und Cassandra-Knoten konfigurieren.

So konfigurieren Sie die Authentifizierung für Cassandra auf der Laufzeitebene

Cassandra bietet eine sichere Kommunikation zwischen einem Clientcomputer und einem Containercluster und zwischen Knoten innerhalb eines Clusters. Durch die Aktivierung der Verschlüsselung werden Daten während der Bearbeitung nicht beeinträchtigt und werden sicher übertragen. In Apigee Hybrid ist TLS standardmäßig für jede Kommunikation zwischen Cassandra-Knoten und zwischen Clients und Cassandra-Knoten aktiviert.

Sie können die Authentifizierung mit Nutzernamen/Passwort-Kombinationen konfigurieren, die direkt in der Überschreibungsdatei abgelegt oder einem Kubernetes Secret hinzugefügt werden, wie in diesem Thema erläutert.

Cassandra-Nutzerauthentifizierung

Die Hybridplattform verwendet Cassandra als Backend-Datenspeicher für Laufzeitebenendaten. Standardmäßig ist für jede Clientkommunikation mit Cassandra eine Authentifizierung erforderlich. Es gibt mehrere Clientnutzer, die mit Cassandra kommunizieren. Für diese Nutzer werden Standardpasswörter bereitgestellt. Weitere Informationen zum Ändern der Standardpasswörter finden Sie unter Standardpasswörter in der Überschreibungsdatei ändern.

Diese Nutzer, einschließlich eines Standardnutzers, werden im Folgenden beschrieben:

  1. DML-Nutzer: Wird vom Client zum Lesen und Schreiben von Daten in Cassandra (KMS, KVM, Cache und Quota) verwendet.
  2. DDL-Nutzer: Wird von MART für beliebige Datendefinitionsaufgaben wie das Erstellen, Aktualisieren und Löschen von Schlüsselbereichen verwendet.
  3. Administratornutzer: Wird für alle administrativen Aktivitäten verwendet, die im Cassandra-Cluster ausgeführt werden.
  4. Standard-Cassandra-Nutzer: Cassandra erstellt einen Standardnutzer, wenn die Authentifizierung aktiviert ist und der Nutzername cassandra ist
  5. JMX-Nutzer: Wird zur Authentifizierung und Kommunikation mit der Cassandra JMX-Benutzeroberfläche verwendet.
  6. Jolokia-Nutzer: Wird zur Authentifizierung und Kommunikation mit der Cassandra JMX API verwendet.

Über den Cassandra-Standardnutzer

Wenn ein Apigee Hybrid-Cluster erstellt und die Cassandra-Authentifizierung aktiviert ist, ist das anfängliche Nutzerkonto der Cassandra-Standardnutzer, der durch den Nutzernamen cassandra identifiziert wird. Der cassandra-Standardnutzer fungiert als Superuser und ist für Aufgaben wie das Hinzufügen von Nutzerrollen und das Ändern des Datenbankschemas zuständig.

Der Apigee Hybrid-apigee-cassandra-user-setup-Job verwendet den cassandra-Standardnutzer, um neue Rollen einzurichten und das mit diesem Standardnutzer verknüpfte Passwort zu aktualisieren. Die Ausführung des apigee-cassandra-user-setup-Jobs wird während der Erstinstallation einer Apigee Hybrid-Instanz, der nachfolgenden Instanz-Upgrades und der Bereitstellung einer neuen Instanz als Teil der Regionserweiterung ausgeführt.

Wenn der Apigee Hybrid-apigee-cassandra-user-setup-Job ausgeführt wird, muss der Job Konfigurationen auf Datenbankebene entweder im Rahmen einer Neuinstallation oder eines Upgrades aktualisieren und ändern. Der cassandra-Standardnutzer ist der einzige, der definitiv vorhanden ist, wenn der apigee-cassandra-user-setup-Job die neuen Cassandra-Pods einrichtet. Ohne einen bekannten Nutzer mit Superuser-Zugriff funktionieren die Apigee Hybrid-Upgrades und die Regionserweiterung nicht ordnungsgemäß.

Das cassandra-Standardnutzer-Passwort wird nach der ersten Verwendung als Teil zusätzlicher Sicherheitsmaßnahmen geändert. Das bedeutet, dass auch wenn der cassandra-Standardnutzer noch aktiviert ist, das neue Passwort den cassandra-Standardnutzer verwenden muss. Der cassandra-Standardnutzer wird von keinen anderen Komponenten als dem apigee-cassandra-user-setup-Job im Rahmen der neuen Installation und Regionserweiterung verwendet.

Standardpasswörter in der Überschreibungsdatei ändern

Als Best Practice in Sachen Sicherheit empfehlen wir, die Standardpasswörter für Cassandra zu ändern. Dies ist in der Datei overrides.yaml möglich. Fügen Sie die folgende Konfiguration hinzu, ändern Sie die Standardpasswörter nach Bedarf und wenden Sie die Änderung auf Ihren Cluster an. Siehe cassandra. Sie können die Standardpasswörter in Ihrer values.yaml-Datei ansehen. 

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

Wichtige Hinweise:

  • Rotation der Zertifizierungsstelle (Certificate Authority, CA) wird nicht unterstützt.
  • Ein Serverzertifikat, das mit Passphrase generiert wird, wird nicht unterstützt.

Nutzernamen und Passwörter in einem Kubernetes Secret festlegen

Dieser Abschnitt erläutert die Konfiguration von Cassandra für die Verwendung von Kubernetes-Secrets zur Authentifizierung.

Erstellen Sie das Secret

Verwenden Sie die folgende Vorlage, um das Kubernetes Secret zu konfigurieren. Speichern Sie die Vorlage in einer YAML-Datei und bearbeiten Sie die erforderlichen Attribute, z. B. my-secret.yaml. Beachten Sie, dass Sie bei Verwendung dieser Option die Nutzernamen mit jedem Passwort angeben müssen. 

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

Dabei ist SECRET_NAME der Name, den Sie für das Secret auswählen, APIGEE_NAMESPACE der Namespace, in dem die Apigee-Pods bereitgestellt werden (Standard ist apigee), und jeder _USERNAME und _PASSWORD sind die Nutzernamen und Passwörter für jeden Nutzer. Beachten Sie, dass Nutzername und Passwort Base64-codiert sein müssen.

Wenden Sie das Secret auf den Cluster an. Beispiel: 

kubectl apply -f SECRET_FILE

Fügen Sie das Secret Ihrer Überschreibungendatei hinzu: 

cassandra:
  auth:
    secret: SECRET_NAME

Wenden Sie die aktualisierte Cassandra-Überschreibung auf den Cluster an:

Helm

helm upgrade datastore apigee-datastore/ \
--namespace apigee \
--atomic \
-f OVERRIDES_FILE.yaml

apigeectl

$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE.yaml --datastore

Cassandra-Logs ansehen

Prüfen Sie die Logs, sobald das Cassandra gestartet wird. Das folgende Log zeigt, dass die Cassandra-Clientverbindungen verschlüsselt sind. 

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...