Cassandra-Anmeldedaten in Hashicorp Vault rotieren

Übersicht

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 Passwortrotation 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 entsprechende 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 Vorabprü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 Vorabprüfung der Rotation abgeschlossen ist, ändern Sie den Wert von metadata.name und setzen Sie spec.precheck auf false. 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 beiden 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.
Sobald der Bereinigungsjob abgeschlossen ist, ist der Rotationsprozess abgeschlossen.
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 fortfahren.
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 Vorabprü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 entsprechende Vorlage finden Sie unter Cassandra-Secrets in Hashicorp Vault speichern. Diese Definition sollte mit der Definition in 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 Datastore-Diagramm an:
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
Hinweis:Wenn Sie das Datastore-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 für die Organisation und die Umgebungen abgeschlossen ist und sie wieder den Status „Aktiv“ 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.
Sobald der Bereinigungsjob abgeschlossen ist, ist der Rotationsprozess abgeschlossen.
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.