TLS für Cassandra konfigurieren

Aktuell lesen Sie die Version 1.3 der Apigee Hybrid-Dokumentation. Diese Version ist nicht mehr gültig. Führen Sie ein Upgrade auf eine neuere Version durch. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.3 (unsupported)

   Supported versions:

• v1.12 (latest)                        
• v1.11                         
• v1.10                                        
• List of supported versions

   Unsupported versions:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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.

Alle Nutzernamen müssen kleingeschrieben sein; Sonderzeichen sind nicht zulässig.

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