Diese Seite wurde von der Cloud Translation API übersetzt.

Cassandra-Anmeldedaten in Hashicorp Vault rotieren

Übersicht

In dieser Anleitung wird beschrieben, wie Sie Cassandra-Anmeldedaten in Hashicorp Vault rotieren. 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:

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

Dieses Feature 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 sicherstellen, dass eine Wiederherstellung auf Anmeldedaten vor der Rotation möglich ist.
Prüfen Sie, ob der Cluster fehlerfrei ist, d.h. alle Apigee-Ressourcen werden ausgeführt und es stehen keine Statusänderungen an.

Hinweis:Sie benötigen die Berechtigung zum Ausführen von kubectl apply -f im Cluster, 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. Dadurch 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 Rotationsjob. Sie müssen metadata.name für den Vorabcheck-Job und für den Rotationsjob 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: Setzen Sie spec.cassandra.newSecretProviderClass auf den Namen der neuen Secret-Provider-Klasse, die Sie im vorherigen Schritt erstellt haben.
- OLD_SPC_NAME: Setzen Sie spec.cassandra.oldSecretProviderClass auf den SPC-Namen, der derzeit von der ApigeeDatastore verwendet wird.
Lösen Sie den Vorabprüfjob für die 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 Vorabprüfungsjob abgeschlossen ist.

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

Sobald der Vorabprüfungsvorgang für die 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 bestätigt haben, dass der Traffic weiterhin korrekt fließt, bereinigen Sie den Prozess mit den folgenden zwei Schritten:
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 Rotationsvorgang rückgängig zu machen und den Cluster im ursprünglichen Zustand zu belassen.
Wenn der Bereinigungsjob abgeschlossen ist, ist auch die Rotation abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die neue Secret-Provider-Klasse (newSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sichern Sie Ihre Cassandra-Datenbank. Diese Sicherung soll sicherstellen, dass eine Wiederherstellung nach der Rotation der Anmeldedaten möglich ist.
Löschen Sie die alten Cassandra-Anmeldedaten, die alte Rolle und die alte Richtlinie aus Vault.

Multiregionale Einrichtung

Die Einrichtungsprozeduren für mehrere Regionen sind 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. Dadurch 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 Rotationsjob. Sie müssen metadata.name für den Vorabcheck-Job und für den Rotationsjob 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: Setzen Sie spec.cassandra.newSecretProviderClass auf den Namen der neuen Secret-Provider-Klasse, die Sie im vorherigen Schritt erstellt haben.
  - OLD_SPC_NAME: Setzen Sie spec.cassandra.oldSecretProviderClass auf den SPC-Namen, der derzeit von der ApigeeDatastore verwendet wird.
3. Lösen Sie den Vorabprüfjob für die 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 Vorabprüfungsjob abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
```
  Tipp:Sie können die Logs auch während der Ausführung des Jobs ansehen.
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
5. Nach Abschluss des Vorabprüfungsjobs für die Rotation:
  - Ä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 spec.rotationId auf 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 von 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. Dies sollte dieselbe Definition wie in Schritt 1a sein.
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-Chart an:

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

Ein neues ReplicaSet wird 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 für spec.cassandra.newSecretProviderClass in rotation.yaml festgelegt haben, z. B.:

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

my-new-spc

Datenspeicherdiagramm anwenden:
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
Hinweis:Wenn Sie das Datenspeicherdiagramm anwenden, werden auch Releases für die Organisation und die Umgebungen ausgelöst.
Der Datenspeicher wird in den Status „Wird freigegeben“ versetzt. Warten Sie, bis der Datenspeicher freigegeben wurde und ausgeführt wird.
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
DATASTORE_NAME ist in den meisten Installationen default.

Prüfen Sie, ob die neuen Datenspeicher-Pods den neuen 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 für spec.cassandra.newSecretProviderClass in rotation.yaml 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 Organisation und die Umgebungen freigegeben wurden und wieder den Status „Wird ausgeführt“ 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 Synchronizer-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 für spec.cassandra.newSecretProviderClass in rotation.yaml 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 geprüft haben, ob der Traffic weiterhin korrekt fließt, bereinigen Sie den Prozess in der ersten Region mit den folgenden zwei Schritten:
1. Aktualisieren Sie in der ersten Region 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
```
3. Prüfen Sie den Jobstatus und die Joblogs, um festzustellen, wann der Bereinigungsjob abgeschlossen ist.
Wenn der Bereinigungsjob abgeschlossen ist, ist auch die Rotation abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die neue Secret-Provider-Klasse (newSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sichern Sie Ihre Cassandra-Datenbank. Diese Sicherung soll sicherstellen, dass eine Wiederherstellung nach der Rotation der Anmeldedaten möglich ist.
Löschen Sie die alten Cassandra-Anmeldedaten, die alte Rolle und die alte Richtlinie aus Vault.

Rotation rückgängig machen

Führen Sie für multiregionale Bereitstellungen 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, z. B. rot-1.
- TIMEOUT_MINUTES: Optional. Überschreibt den Standardwert (480 m == 8 Stunden). <=0 bedeutet ein unendliches Zeitlimit.
- OLD_SPC_NAME: Dieser Wert muss mit dem Namen des Secrets für oldSecretProviderClass: in der Rotations-YAML-Datei übereinstimmen, die Sie im Verfahren Einrichtung in einer einzelnen Region oder Einrichtung in mehreren Regionen verwendet haben.
- NEW_SPC_NAME: Dieser Wert muss mit dem Namen des Secrets für newSecretProviderClass: in der Rotations-YAML-Datei übereinstimmen, die Sie im Verfahren Einrichtung in einer einzelnen Region oder Einrichtung in mehreren Regionen verwendet haben.

Rollback anwenden:

kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE

Prüfen Sie den Jobstatus und warten Sie, bis der Job abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
Prüfen Sie nach Abschluss der Rollbacks, ob der Traffic weiterhin korrekt fließt.
Wiederholen Sie bei Installationen mit mehreren Regionen den Rollback-Vorgang in jeder Region, wenn der Traffic korrekt fließt.
Nachdem Sie das Rollback abgeschlossen und geprüft haben, ob der Traffic in allen Regionen weiterhin korrekt fließt, können Sie mit der Bereinigung beginnen.
Nehmen Sie die folgenden Änderungen in 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 der Job abgeschlossen ist.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
Wenn der Bereinigungsjob abgeschlossen ist, ist auch der Rollback abgeschlossen.
Aktualisieren Sie die Überschreibungsdatei und legen Sie cassandra.auth.secretProviderClass auf die alte Secret-Provider-Klasse (oldSecretProviderClass) fest.
```
cassandra:
  auth:
    secretProviderClass: OLD_SPC_NAME
```