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:
- DML-Nutzer: Wird vom Client zum Lesen und Schreiben von Daten in Cassandra (KMS, KVM, Cache 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
cassandraist - JMX-Nutzer: Wird zur Authentifizierung und Kommunikation mit der Cassandra JMX-Benutzeroberfläche verwendet.
- 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...