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 TLS 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 drei Nutzer, die von Clients verwendet werden, die mit Cassandra kommunizieren. Für diese Nutzer werden Standardpasswörter bereitgestellt. Sie müssen diese nicht ändern.
Diese Nutzer, einschließlich eines Standardnutzers, werden im Folgenden beschrieben:
- DML-Nutzer: Wird von der Clientkommunikation zum Lesen und Schreiben von Daten in Cassandra (KMS, KVM, Cahce und Quota) verwendet.
- DDL-Nutzer: Wird von MART für beliebige Datendefinitionsaufgaben wie das Erstellen, Aktualisieren und Löschen von Schlüsselbereichen verwendet.
- Administratornutzer: Wird für alle administrativen Aktivitäten verwendet, die im Cassandra-Cluster ausgeführt werden.
- Standard-Cassandra-Nutzer: Cassandra erstellt einen Standardnutzer, wenn die Authentifizierung aktiviert ist und der Nutzername
cassandra
ist
Standardpasswörter in der Überschreibungsdatei ändern
Apigee hybrid stellt Standardpasswörter für die Cassandra-Nutzer bereit. Wenn Sie die Standardpasswörter für Nutzer ändern möchten, können Sie dies in der Datei overrides.yaml
tun. Fügen Sie die folgende Konfiguration hinzu, ändern Sie die Standardpasswörter ("iloveapis123") und wenden Sie die Änderung auf den Cluster an.
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"
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 Datei und bearbeiten Sie die erforderlichen Attribute. 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: $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
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 $USERNAME und $PASSWORD sind Nutzername und Passwort pro 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:
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml -c cassandra
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...