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

Rotation des identifiants Cassandra dans Hashicorp Vault

Aperçu

Cette fonctionnalité permet aux administrateurs de plate-forme :

d'effectuer une rotation des identifiants Cassandra dans Hashicorp Vault
de revenir aux anciens identifiants Cassandra dans Vault en cas de problème lors de la rotation des mots de passe.
d'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.
de suivre le début, la progression et la fin de la rotation pour une seule région.

Cette fonctionnalité est disponible dans Apigee Hybrid 1.13.1 et les 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 ayant bénéficié d'une pré-rotation.
Assurez-vous que le cluster est opérationnel (c'est-à-dire que toutes les ressources Apigee sont en cours d'exécution et qu'aucune modification 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 la section 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 de la tâche de rotation. Vous devez définir metadata.name sur une valeur unique pour la tâche de prévérification de la rotation et à nouveau pour la tâche 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 la SPC actuellement utilisé par ApigeeDatastore.
Déclenchez la tâche 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 de la tâche pour savoir quand elle est terminée.

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

Une fois la tâche de prévérification de la rotation terminée, modifiez la valeur de metadata.name et définissez spec.precheck sur false. Appliquez à nouveau le fichier pour effectuer la rotation.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
Une fois la tâche de rotation terminée et que vous avez vérifié que le trafic continue de circuler correctement, nettoyez le processus en procédant comme suit :
1. Remplacez la valeur de metadata.name et définissez spec.cassandra.jobType sur CLEANUP.
2. Déclenchez la tâche de nettoyage en appliquant le fichier.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
  Remarque : Jusqu'à cette étape, vous pouvez déclencher une tâche de rollback pour annuler le processus de rotation et laisser le cluster dans son état d'origine.
Une fois la tâche de nettoyage terminée, le processus de rotation est terminé.
Sauvegardez votre base de données Cassandra. Cette sauvegarde permet de s'assurer que la récupération est possible avec des identifiants ayant bénéficié d'une post-rotation.
Supprimez les anciens identifiants, rôles et stratégies 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 suivantes dans la première région avant de commencer les 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 la section 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 de la tâche de rotation. Vous devez définir metadata.name sur une valeur unique pour la tâche de prévérification de la rotation et à nouveau pour la tâche 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 la SPC actuellement utilisé par ApigeeDatastore.
3. Déclenchez la tâche 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 de la tâche pour savoir quand elle est terminée.
```
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
```
  Conseil : Vous pouvez également afficher les journaux pendant l'exécution de la tâche.
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
5. Une fois la tâche de prévérification de la rotation terminée :
  - Remplacez la valeur de metadata.name, par exemple de sr-1-precheck à 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 à 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 soit 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 la section Stocker des secrets Cassandra dans Hashicorp Vault. Il doit s'agir de la même définition que celle de l'étape 1a.
Mettez à jour votre 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ôleur utilisent le nouveau 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 en état de libération. Attendez que le datastore ait été publié et qu'il soit en cours d'exécution.
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
DATASTORE_NAME est default dans la plupart des installations.

Vérifiez que les nouveaux pods de datastore utilisent le nouveau 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 soient publiés et qu'ils soient de nouveau 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 le nouveau 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 suivi les étapes dans chaque région et que vous avez vérifié que le trafic continue de s'écouler correctement, nettoyez le processus dans la première région en procédant comme suit :
1. Dans la première région, modifiez la valeur de metadata.name et définissez spec.cassandra.jobType sur CLEANUP.
2. Déclenchez la tâche de nettoyage en appliquant le fichier.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
3. Vérifiez l'état de la tâche et consultez les journaux de la tâche pour vérifier quand la tâche de nettoyage est terminée.
Une fois la tâche de nettoyage terminée, le processus de rotation est terminé.
Sauvegardez votre base de données Cassandra. Cette sauvegarde permet de s'assurer que la récupération est possible avec des identifiants ayant bénéficié d'une post-rotation.
Supprimez les anciens identifiants, rôles et stratégies Cassandra de Vault.