Cette page a été traduite par l'API Cloud Translation.

Rotation des identifiants Cassandra dans Hashicorp Vault

Aperçu

Cette procédure décrit la rotation des identifiants Cassandra dans Hashicorp Vault. Pour faire tourner les identifiants dans les secrets Kubernetes de votre cluster, consultez Faire tourner les identifiants Cassandra dans les secrets Kubernetes.

Cette fonctionnalité permet aux administrateurs de plate-forme d'effectuer les opérations suivantes :

Effectuer une rotation des identifiants Cassandra dans Hashicorp Vault
Revenir aux anciens identifiants Cassandra dans Vault en cas de problème lors de la rotation des mots de passe
Effectuer une rotation du mot de passe Cassandra pour une région à la fois afin de limiter l'impact sur la disponibilité du service et de garder le contrôle sur le processus de rotation
Suivre le démarrage, la progression et l'achèvement de la rotation pour une région unique

Cette fonctionnalité est disponible dans Apigee Hybrid 1.13.1 et versions ultérieures.

Avant de commencer

Avant de configurer la rotation des identifiants :

Sauvegardez votre base de données Cassandra. Cette sauvegarde permet de s'assurer que la récupération est possible avec des identifiants qui ont été soumis à une pré-rotation.
Assurez-vous que le cluster est opérationnel (toutes les ressources Apigee sont en cours d'exécution et aucun changement d'état n'est en attente).

Remarque : Vous devez disposer de l'autorisation d'exécuter kubectl apply -f dans le cluster pour configurer la rotation des identifiants.

Configuration dans une seule région

Créez une ressource Kubernetes SecretProviderClass dans votre espace de noms Apigee pour les nouveaux identifiants Cassandra. Pour obtenir un modèle à utiliser, consultez Stocker des secrets Cassandra dans Hashicorp Vault. Cela permet à un rôle Vault d'accéder aux secrets dans les espaces de noms Kubernetes.
Créez une ressource personnalisée SecretRotation à l'aide du modèle suivant :
```
# 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 : nom unique du job de rotation. Vous devrez définir metadata.name sur une valeur unique pour le job de prévérification de la rotation, puis à nouveau pour le job de rotation. Par exemple, sr-1-precheck suivi de sr-1.
- ROTATION_ID : définissez spec.rotationId sur un identifiant personnalisé, par exemple rotation-1-precheck.
- NEW_SPC_NAME : définissez spec.cassandra.newSecretProviderClass sur le nouveau nom de classe de fournisseur de secrets que vous avez créé à l'étape précédente.
- OLD_SPC_NAME : définissez spec.cassandra.oldSecretProviderClass sur le nom de SPC actuellement utilisé par ApigeeDatastore.
Déclenchez le job de prévérification de la rotation en appliquant le fichier rotation.yaml.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```

Vérifiez l'état du job pour surveiller l'achèvement du job de prévérification.

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

Une fois le job de prévérification de la rotation terminé, modifiez la valeur de metadata.name et définissez spec.precheck sur false. Appliquez de nouveau le fichier pour effectuer la rotation.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
Une fois le job de rotation terminé et après avoir vérifié que le trafic continue de circuler correctement, nettoyez le processus en suivant ces deux étapes :
1. Remplacez la valeur de metadata.name et définissez spec.cassandra.jobType sur CLEANUP.
2. Déclenchez le job de nettoyage en appliquant le fichier.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
  Remarque : Jusqu'à cette étape, vous pouvez déclencher un job de rollback pour annuler le processus de rotation et laisser le cluster dans son état d'origine.
Une fois le job de nettoyage terminé, le processus de rotation est terminé.
Mettez à jour votre fichier de remplacement et définissez cassandra.auth.secretProviderClass sur la nouvelle classe de fournisseur de secrets (newSecretProviderClass).
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sauvegardez votre base de données Cassandra. Cette sauvegarde permet de s'assurer que la récupération est possible avec des identifiants qui ont été soumis à une post-rotation.
Supprimez les anciens identifiants, le rôle et la règle Cassandra de Vault.

Configuration multirégionale

Les procédures de configuration multirégionale sont divisées en deux sections : la configuration de la première région et la configuration des autres régions.

Effectuez les étapes qui suivent dans la première région avant de passer aux régions suivantes.
1. Créez une ressource Kubernetes SecretProviderClass dans l'espace de noms APIGEE_NAMESPACE pour les nouveaux identifiants Cassandra. Pour obtenir un modèle à utiliser, consultez Stocker des secrets Cassandra dans Hashicorp Vault. Cela permet à un rôle Vault d'accéder aux secrets dans les espaces de noms Kubernetes.
2. Créez une ressource personnalisée SecretRotation à l'aide du modèle suivant :
```
# 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 : nom unique du job de rotation. Vous devrez définir metadata.name sur une valeur unique pour le job de prévérification de la rotation, puis à nouveau pour le job de rotation. Par exemple, sr-1-precheck suivi de sr-1.
  - ROTATION_ID : définissez spec.rotationId sur un identifiant personnalisé, par exemple rotation-1-precheck.
  - NEW_SPC_NAME : définissez spec.cassandra.newSecretProviderClass sur le nouveau nom de classe de fournisseur de secrets que vous avez créé à l'étape précédente.
  - OLD_SPC_NAME : définissez spec.cassandra.oldSecretProviderClass sur le nom de SPC actuellement utilisé par ApigeeDatastore.
3. Déclenchez le job de prévérification de la rotation en appliquant le fichier rotation.yaml.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
4. Vérifiez l'état du job pour surveiller l'achèvement du job de prévérification.
```
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
```
  Conseil : Vous pouvez également afficher les journaux pendant l'exécution du job.
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
5. Une fois le job de prévérification de la rotation terminé, procédez comme suit :
  - Modifiez la valeur de metadata.name, par exemple en remplaçant sr-1-precheck par sr-1.
  - Définissez spec.precheck sur false pour désactiver la prévérification et effectuer la rotation.
  - Définissez spec.rotationId sur un nouvel identifiant, par exemple rotation-1.
6. Appliquez de nouveau le fichier pour effectuer la rotation.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
7. Vérifiez l'état de SecretRotation et attendez qu'il passe à complete.
```
kubectl -n APIGEE_NAMESPACE get sr SR_NAME
```

Dans chaque région suivante, procédez comme suit :

Créez une ressource Kubernetes SecretProviderClass dans votre espace de noms Apigee pour les nouveaux identifiants Cassandra. Pour obtenir un modèle à utiliser, consultez Stocker des secrets Cassandra dans Hashicorp Vault. Cette définition doit être identique à celle de l'étape 1a.
Mettez à jour votre fichier overrides.yaml et définissez cassandra.auth.secretProviderClass sur la valeur de spec.cassandra.newSecretProviderClass dans le fichier rotation.yaml.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```

Appliquez le graphique de l'opérateur :

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

Un ReplicaSet sera créé. Vérifiez que les nouveaux pods de gestionnaire de contrôleurs utilisent la nouvelle SPC :

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}'

Le résultat doit correspondre à la valeur que vous avez définie pour spec.cassandra.newSecretProviderClass dans rotation.yaml, par exemple :

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

my-new-spc

Appliquez le graphique de datastore :
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
Remarque : L'application du graphique de datastore déclenche également des versions pour l'organisation et les environnements.
Le datastore passe à l'état de publication. Attendez que le datastore ait terminé sa publication et qu'il soit en cours d'exécution.
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
Le DATASTORE_NAME est default dans la plupart des installations.

Vérifiez que les nouveaux pods de datastore utilisent la nouvelle SPC :

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

Le résultat doit correspondre à la valeur que vous avez définie pour spec.cassandra.newSecretProviderClass dans rotation.yaml, par exemple :

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

my-new-spc

Attendez que l'organisation et les environnements aient terminé la publication et qu'ils soient revenus à l'état "En cours d'exécution".
```
kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME
```

Vérifiez que les nouveaux pods MART, d'exécution et de synchronisation utilisent la nouvelle SPC :

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}'

Le résultat doit correspondre à la valeur que vous avez définie pour spec.cassandra.newSecretProviderClass dans rotation.yaml, par exemple :

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

my-new-spc

Une fois que vous avez effectué les étapes dans chaque région et vérifié que le trafic continue de circuler correctement, nettoyez le processus dans la première région en procédant comme suit :
1. Dans la première région, mettez à jour la valeur de metadata.name et définissez spec.cassandra.jobType sur CLEANUP.
2. Déclenchez le job de nettoyage en appliquant le fichier.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
3. Vérifiez l'état du job et consultez les journaux de job pour savoir quand le job de nettoyage est terminé.
Une fois le job de nettoyage terminé, le processus de rotation est terminé.
Mettez à jour votre fichier de remplacement et définissez cassandra.auth.secretProviderClass sur la nouvelle classe de fournisseur de secrets (newSecretProviderClass).
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Sauvegardez votre base de données Cassandra. Cette sauvegarde permet de s'assurer que la récupération est possible avec des identifiants qui ont été soumis à une post-rotation.
Supprimez les anciens identifiants, le rôle et la règle Cassandra de Vault.

Effectuer un rollback d'une rotation

Pour les déploiements multirégionaux, effectuez le rollback dans chaque région.

Créez une ressource personnalisée SecretRotation à l'aide du modèle suivant :
```
# 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
```
Où :
- ROLLBACK_NAME : nom du job de restauration, par exemple sr-1-rollback.
- APIGEE_NAMESPACE : votre espace de noms Apigee.
- APIGEE_ORG : ID de votre organisation Apigee.
- ROTATION_ID : ID de la rotation actuelle que vous restaurez, par exemple rot-1.
- TIMEOUT_MINUTES : facultatif. Remplace la valeur par défaut (480 mètres = 8 heures). <=0 signifie un délai d'expiration infini.
- OLD_SPC_NAME : cette valeur doit correspondre au nom secret de oldSecretProviderClass: dans le fichier YAML de rotation que vous avez utilisé dans la procédure de configuration à une seule région ou de configuration multirégion.
- NEW_SPC_NAME : cette valeur doit correspondre au nom secret de newSecretProviderClass: dans le fichier YAML de rotation que vous avez utilisé dans la procédure de configuration à une seule région ou de configuration multirégion.

Appliquez le rollback :

kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE

Vérifiez l'état du job et attendez qu'il soit terminé.

kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME

Une fois la ou les restaurations terminées, vérifiez que le trafic continue de circuler correctement.
Pour les installations multirégionales, lorsque le trafic circule correctement, répétez la procédure de rollback dans chaque région.
Une fois le rollback terminé et après avoir vérifié que le trafic continue de circuler correctement dans toutes les régions, lancez le processus de nettoyage.
Apportez les modifications suivantes au fichier YAML de rotation :
- Remplacez metadata.name par un nom indiquant qu'il s'agit d'un job de nettoyage, par exemple sr-1-cleanup-rollback.
- Remplacez spec.cassandra.jobType par CLEANUP_ROLLBACK.

Appliquez le fichier pour déclencher le job de nettoyage :

kubectl -n APIGEE_NAMESPACE apply -f ROTATION_YAML_FILE

Vérifiez l'état du job et attendez qu'il soit terminé.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
Une fois le job de nettoyage terminé, le processus de rollback est terminé.
Mettez à jour votre fichier de remplacement et définissez cassandra.auth.secretProviderClass sur l'ancienne classe de fournisseur de secrets (oldSecretProviderClass).
```
cassandra:
  auth:
    secretProviderClass: OLD_SPC_NAME
```

Rotation des identifiants Cassandra dans Hashicorp Vault Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Aperçu

Avant de commencer

Configuration dans une seule région

Configuration multirégionale

Effectuer un rollback d'une rotation

Rotation des identifiants Cassandra dans Hashicorp Vault