Diese Seite wurde von der Cloud Translation API übersetzt.

Cassandra-Anmeldedaten in Hashicorp Vault rotieren

Übersicht

In diesem Verfahren wird beschrieben, wie Cassandra-Anmeldedaten in Hashicorp Vault rotiert werden. Informationen zum Rotieren von Anmeldedaten in Kubernetes-Secrets in Ihrem Cluster finden Sie unter Cassandra-Anmeldedaten in Kubernetes-Secrets rotieren.

Mit dieser Funktion können Plattformadministratoren Folgendes tun:

Cassandra-Anmeldedaten in Hashicorp Vault rotieren
Führen Sie bei Problemen während der Passwortrotation ein Rollback auf die vorherigen Cassandra-Anmeldedaten in Vault aus.
Wechseln Sie das Cassandra-Passwort jeweils für eine Region, um die Auswirkungen auf die Dienstverfügbarkeit zu minimieren und die Kontrolle über den Rotationsprozess zu behalten.
Start, Fortschritt und Abschluss der Rotation für eine einzelne Region verfolgen

Diese Funktion ist in Apigee Hybrid 1.13.1 und höher verfügbar.

Hinweise

Bevor Sie die Rotation von Anmeldedaten einrichten:

Sichern Sie Ihre Cassandra-Datenbank. Diese Sicherung soll dafür sorgen, dass eine Wiederherstellung der zuvor rotierten Anmeldedaten möglich ist.
Der Cluster muss fehlerfrei sein, d.h. alle Apigee-Ressourcen müssen ausgeführt werden und es dürfen keine ausstehenden Statusänderungen vorhanden sein.

Hinweis:Sie benötigen die Berechtigung zum Ausführen von kubectl apply -f innerhalb des Clusters, um die Anmeldedatenrotation einzurichten.

Einrichtung für eine Region

Erstellen Sie eine neue SecretProviderClass-Kubernetes-Ressource in Ihrem Apigee-Namespace für die neuen Cassandra-Anmeldedaten. Eine Vorlage finden Sie unter Cassandra-Secrets in Hashicorp Vault speichern. So kann eine Vault-Rolle auf Secrets in den Kubernetes-Namespaces zugreifen.
Erstellen Sie mit der folgenden Vorlage eine neue benutzerdefinierte SecretRotation-Ressource:
```
# rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROTATION_PROCESS_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: ORG_NAME
  rotationId: ROTATION_ID
  timeoutMinutes: 480 # optional. overrides the default (480m == 8hr).
                      # less than or equal to 0 means infinite timeout.
  precheck: true
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME
    newSecretProviderClass: NEW_SPC_NAME
    jobType: ROTATE
```
- ROTATION_PROCESS_NAME: Ein eindeutiger Name für den Job für die Rotation. Sie müssen metadata.name für den Job zur Vorprüfung der Rotation und noch einmal für den Job zur Rotation auf einen eindeutigen Wert festlegen. Beispiel: sr-1-precheck gefolgt von sr-1.
- ROTATION_ID: Legen Sie spec.rotationId auf eine benutzerdefinierte Kennung fest, z. B. rotation-1-precheck.
- NEW_SPC_NAME: Legen Sie spec.cassandra.newSecretProviderClass auf den Namen der neuen Secret-Provider-Klasse fest, die Sie im vorherigen Schritt erstellt haben.
- OLD_SPC_NAME: Legen Sie spec.cassandra.oldSecretProviderClass auf den Namen des SPC fest, der derzeit von der ApigeeDatastore verwendet wird.
Lösen Sie den Job für die Vorprüfung der Rotation aus, indem Sie die Datei rotation.yaml anwenden.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```

Prüfen Sie den Jobstatus, um festzustellen, wann der Vorabcheck abgeschlossen ist.

kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job

Sobald der Job für die Vorprüfung der Rotation abgeschlossen ist, ändern Sie den Wert von metadata.name und legen Sie spec.precheck auf false fest. Wenden Sie die Datei noch einmal an, um die Drehung auszuführen.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
Nachdem der Rotationsjob abgeschlossen ist und Sie überprüft haben, ob der Traffic weiterhin korrekt fließt, können Sie den Vorgang mit den folgenden zwei Schritten bereinigen:
1. Aktualisieren Sie den Wert von metadata.name und legen Sie spec.cassandra.jobType auf CLEANUP fest.
2. Lösen Sie den Bereinigungsjob aus, indem Sie die Datei anwenden.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
  Hinweis:Bis zu diesem Schritt können Sie einen Rollback-Job auslösen, um den Rotationsprozess rückgängig zu machen und den Cluster in seinem ursprünglichen Zustand zu belassen.
Wenn der Bereinigungsjob abgeschlossen ist, ist der Rotationsprozess abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die neue Secret-Anbieterklasse (newSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sichern Sie Ihre Cassandra-Datenbank. Diese Sicherung soll dafür sorgen, dass nach der Rotation der Anmeldedaten eine Wiederherstellung möglich ist.
Löschen Sie die alten Cassandra-Anmeldedaten, die Rolle und die Richtlinie aus Vault.

Multiregionale Einrichtung

Die Einrichtung für mehrere Regionen ist in zwei Abschnitte unterteilt: Einrichtung für die erste Region und Einrichtung für die verbleibenden Regionen.

Führen Sie die folgenden Schritte in der ersten Region aus, bevor Sie mit den nachfolgenden Regionen beginnen.
1. Erstellen Sie eine neue SecretProviderClass-Kubernetes-Ressource im Namespace APIGEE_NAMESPACE für die neuen Cassandra-Anmeldedaten. Eine Vorlage finden Sie unter Cassandra-Secrets in Hashicorp Vault speichern. So kann eine Vault-Rolle auf Secrets in den Kubernetes-Namespaces zugreifen.
2. Erstellen Sie mit der folgenden Vorlage eine neue benutzerdefinierte SecretRotation-Ressource:
```
# rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROTATION_PROCESS_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: ORG_NAME
  rotationId: ROTATION_ID
  timeoutMinutes: -1 # this value is required and should not be changed.
  precheck: true
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME
    newSecretProviderClass: NEW_SPC_NAME
    jobType: ROTATE
```
  - ROTATION_PROCESS_NAME: Ein eindeutiger Name für den Job für die Rotation. Sie müssen metadata.name für den Job zur Vorprüfung der Rotation und noch einmal für den Job zur Rotation auf einen eindeutigen Wert festlegen. Beispiel: sr-1-precheck gefolgt von sr-1.
  - ROTATION_ID: Legen Sie spec.rotationId auf eine benutzerdefinierte Kennung fest, z. B. rotation-1-precheck.
  - NEW_SPC_NAME: Legen Sie spec.cassandra.newSecretProviderClass auf den Namen der neuen Secret-Provider-Klasse fest, die Sie im vorherigen Schritt erstellt haben.
  - OLD_SPC_NAME: Legen Sie spec.cassandra.oldSecretProviderClass auf den Namen des SPC fest, der derzeit von der ApigeeDatastore verwendet wird.
3. Lösen Sie den Job für die Vorprüfung der Rotation aus, indem Sie die Datei rotation.yaml anwenden.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
4. Prüfen Sie den Jobstatus, um festzustellen, wann der Vorabcheck abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
```
  Tipp:Sie können sich die Protokolle auch ansehen, während der Job ausgeführt wird.
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
5. Sobald der Job für die Vorabprüfung der Rotation abgeschlossen ist:
  - Ändern Sie den Wert von metadata.name, z. B. von sr-1-precheck in sr-1.
  - Legen Sie spec.precheck auf false fest, um die Vorabprüfung zu deaktivieren und die Rotation durchzuführen.
  - Legen Sie für spec.rotationId eine neue Kennung fest, z. B. rotation-1.
6. Wenden Sie die Datei noch einmal an, um die Drehung auszuführen.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
7. Prüfen Sie den Status des SecretRotation und warten Sie, bis er complete lautet.
```
kubectl -n APIGEE_NAMESPACE get sr SR_NAME
```

Führen Sie in jeder nachfolgenden Region die folgenden Schritte aus:

Erstellen Sie eine neue SecretProviderClass-Kubernetes-Ressource in Ihrem Apigee-Namespace für die neuen Cassandra-Anmeldedaten. Eine Vorlage finden Sie unter Cassandra-Secrets in Hashicorp Vault speichern. Diese Definition sollte mit der aus Schritt 1a übereinstimmen.
Aktualisieren Sie overrides.yaml und legen Sie cassandra.auth.secretProviderClass so fest, dass es mit dem Wert von spec.cassandra.newSecretProviderClass in der Datei rotation.yaml übereinstimmt.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```

Wenden Sie das Operator-Diagramm an:

helm upgrade operator apigee-operator/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE

Es wird eine neue ReplicaSet erstellt. Prüfen Sie, ob die neuen Controller-Manager-Pods die neue SPC verwenden:

export POD=NEW_CONTROLLER_MANAGER_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

Das Ergebnis sollte mit dem Wert übereinstimmen, den Sie in rotation.yaml für spec.cassandra.newSecretProviderClass festgelegt haben, z. B.:

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

Wenden Sie das Datenspeicherdiagramm an:
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
Hinweis:Wenn Sie das Datenspeicher-Diagramm anwenden, werden auch Releases für die Organisation und die Umgebungen ausgelöst.
Der Datenspeicher wird in den Status „Freigabe“ versetzt. Warten Sie, bis die Freigabe des Datenspeichers abgeschlossen ist und er den Status „Ausgeführt“ hat.
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
DATASTORE_NAME ist in den meisten Installationen default.

Prüfen Sie, ob die neuen Datenspeicher-Pods die neue SPC verwenden:

export POD=NEW_DATASTORE_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

Das Ergebnis sollte mit dem Wert übereinstimmen, den Sie in rotation.yaml für spec.cassandra.newSecretProviderClass festgelegt haben, z. B.:

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

Warten Sie, bis die Freigabe der Organisation und der Umgebungen abgeschlossen ist und sie wieder den Status „Laufend“ haben.
```
kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME
```

Prüfen Sie, ob die neuen MART-, Laufzeit- und Synchronisierer-Pods die neue SPC verwenden:

export POD=NEW_MART_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
export POD=NEW_RUNTIME_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
export POD=NEW_SYNCHRONIZER_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

Das Ergebnis sollte mit dem Wert übereinstimmen, den Sie in rotation.yaml für spec.cassandra.newSecretProviderClass festgelegt haben, z. B.:

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

Nachdem Sie die Schritte in jeder Region ausgeführt und überprüft haben, ob der Traffic weiterhin korrekt fließt, bereinigen Sie den Vorgang in der ersten Region mit den folgenden beiden Schritten:
1. Aktualisieren Sie in der ersten Region den Wert von metadata.name und setzen Sie spec.cassandra.jobType auf CLEANUP.
2. Lösen Sie den Bereinigungsjob aus, indem Sie die Datei anwenden.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
3. Prüfen Sie den Jobstatus und sehen Sie in den Jobprotokollen nach, wann der Bereinigungsjob abgeschlossen ist.
Wenn der Bereinigungsjob abgeschlossen ist, ist der Rotationsprozess abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die neue Secret-Anbieterklasse (newSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sichern Sie Ihre Cassandra-Datenbank. Diese Sicherung soll dafür sorgen, dass nach der Rotation der Anmeldedaten eine Wiederherstellung möglich ist.
Löschen Sie die alten Cassandra-Anmeldedaten, die Rolle und die Richtlinie aus Vault.

Rotation rückgängig machen

Führen Sie bei einer mehrregionalen Bereitstellung das Rollback in jeder Region durch.

Erstellen Sie mit der folgenden Vorlage eine neue benutzerdefinierte SecretRotation-Ressource:
```
# rollback-rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROLLBACK_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: APIGEE_ORG
  rotationId: ROTATION_ID # match the current rotation.
  timeoutMinutes: TIMEOUT_MINUTES # optional.
  precheck: false
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME # Must match the previous oldSecretProviderClass.
    newSecretProviderClass: NEW_SPC_NAME # Must match the previous newSecretProviderClass.
    jobType: ROLLBACK
```
Wobei:
- ROLLBACK_NAME: Ein Name für den Rollback-Job, z. B. sr-1-rollback.
- APIGEE_NAMESPACE: Ihr Apigee-Namespace.
- APIGEE_ORG: Ihre Apigee-Organisations-ID.
- ROTATION_ID: Die ID der aktuellen Rotation, die Sie rückgängig machen möchten, z. B. rot-1.
- TIMEOUT_MINUTES: Optional. Überschreibt den Standardwert (480 Minuten = 8 Stunden). „<=0“ bedeutet ein unbegrenztes Zeitlimit.
- OLD_SPC_NAME: Dieser muss mit dem geheimen Namen für oldSecretProviderClass: in der Rotations-YAML-Datei übereinstimmen, die Sie bei der Einrichtung einer einzelnen Region oder der Einrichtung mehrerer Regionen verwendet haben.
- NEW_SPC_NAME: Dieser muss mit dem geheimen Namen für newSecretProviderClass: in der Rotations-YAML-Datei übereinstimmen, die Sie bei der Einrichtung einer einzelnen Region oder der Einrichtung mehrerer Regionen verwendet haben.

Führen Sie das Rollback aus:

kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE

Prüfen Sie den Jobstatus und warten Sie, bis er abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
Prüfen Sie nach Abschluss der Rollbacks, ob der Traffic weiterhin korrekt fließt.
Bei Installationen mit mehreren Regionen wiederholen Sie den Rollback-Vorgang in jeder Region, wenn der Traffic richtig fließt.
Sobald Sie das Rollback abgeschlossen und überprüft haben, dass der Traffic weiterhin in allen Regionen korrekt fließt, beginnen Sie mit der Bereinigung.
Nehmen Sie die folgenden Änderungen an der YAML-Datei für die Rotation vor:
- Ändern Sie metadata.name in einen Namen, der angibt, dass es sich um einen Bereinigungsjob handelt, z. B. sr-1-cleanup-rollback.
- Ändern Sie spec.cassandra.jobType zu CLEANUP_ROLLBACK.

Wenden Sie die Datei an, um den Bereinigungsjob auszulösen:

kubectl -n APIGEE_NAMESPACE apply -f ROTATION_YAML_FILE

Prüfen Sie den Jobstatus und warten Sie, bis er abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
Sobald der Bereinigungsjob abgeschlossen ist, ist der Rollback-Vorgang abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die alte Secret-Anbieterklasse (oldSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: OLD_SPC_NAME
```

Cassandra-Anmeldedaten in Hashicorp Vault rotieren Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht

Hinweise

Einrichtung für eine Region

Multiregionale Einrichtung

Rotation rückgängig machen

Cassandra-Anmeldedaten in Hashicorp Vault rotieren