Migration des clés secrètes Kubernetes vers KMS v2

Découvrez comment recrypter les objets de clé secrète Kubernetes existants à l'aide du fournisseur KMS (Key Management Service) version 2 dans un cluster créé à l'aide de OKE (Kubernetes Engine).

Le plan de contrôle de cluster Kubernetes stocke les données de configuration confidentielles (comme les jetons d'authentification, les certificats et les informations d'identification) en tant qu'objets de clé secrète Kubernetes dans etcd. Lorsque vous créez un cluster à l'aide de Kubernetes Engine, vous pouvez indiquer une clé de cryptage maître dans le service Oracle Cloud Infrastructure Vault afin de crypter les clés de cryptage de données qui protègent les clés secrètes Kubernetes au repos. Pour plus d'informations, reportez-vous à Cryptage de clés secrètes Kubernetes inactives dans etcd.

Kubernetes utilise un fournisseur KMS pour communiquer entre le serveur d'API Kubernetes et le module d'extension KMS Kubernetes Engine. La version du fournisseur KMS est distincte de la version de la clé de cryptage maître dans Vault. La migration du fournisseur KMS version 1 vers le fournisseur KMS version 2 ne nécessite pas la création d'une nouvelle clé de cryptage maître ni la modification de la clé associée au cluster. Pour plus d'informations sur les fournisseurs KMS Kubernetes, reportez-vous à Utilisation d'un fournisseur KMS pour le cryptage des données dans la documentation Kubernetes.

La version du fournisseur KMS utilisée pour crypter les objets de clé secrète Kubernetes dépend de la version de Kubernetes exécutée sur le plan de contrôle de cluster :

Les clusters qui utilisent une clé de cryptage maître que vous gérez et exécutez des versions de Kubernetes antérieures à la version 1.36.1 utilisent le fournisseur KMS version 1 pour crypter les objets de clé secrète Kubernetes.
Les clusters créés avec Kubernetes version 1.36.1 ou ultérieure et une clé de cryptage maître que vous gérez utilisent le fournisseur KMS version 2 à partir de la création du cluster.
Lorsque vous mettez à niveau un cluster existant vers Kubernetes version 1.36.1 ou ultérieure, Kubernetes Engine commence à utiliser le fournisseur KMS version 2. Les nouveaux objets de clé secrète Kubernetes utilisent la version 2 du fournisseur KMS, tout comme les objets de clé secrète existants qui sont ensuite mis à jour.

La mise à niveau du plan de contrôle de cluster ne réécrit pas automatiquement tous les objets de clé secrète Kubernetes existants. Les objets secrets cryptés à l'aide du fournisseur KMS version 1 avant la mise à niveau peuvent rester cryptés à l'aide du fournisseur KMS version 1 jusqu'à ce que Kubernetes les écrive à nouveau.

Kubernetes Engine conserve le fournisseur KMS version 1 en tant que restauration en lecture, de sorte que les objets secrets existants restent lisibles après la mise à niveau du plan de contrôle et pendant la migration. Vous n'avez pas besoin de migrer immédiatement les objets secrets existants pour que les applications restent en cours d'exécution.

Utilisez la procédure de cette rubrique pour réécrire tous les objets de clé secrète Kubernetes existants en une seule opération. Lorsque Kubernetes réécrit chaque objet secret, le serveur d'API Kubernetes le crypte à l'aide du fournisseur KMS version 2. Une fois la migration effectuée, les objets secrets précédemment cryptés à l'aide du fournisseur KMS version 1 ont été recryptés à l'aide du fournisseur KMS version 2.

Tenez compte des éléments suivants :

Normalement, vous n'avez pas besoin d'effectuer cette migration pour un cluster créé avec Kubernetes version 1.36.1 ou ultérieure, car le cluster utilise le fournisseur KMS version 2 à partir de la création du cluster.
Vous ne pouvez pas effectuer la migration lorsque le plan de contrôle de cluster exécute une version de Kubernetes antérieure à la version 1.36.1.
Le moteur Kubernetes ne démarre pas automatiquement une migration en masse lorsque vous mettez à niveau le plan de contrôle de cluster. Vous décidez quand démarrer la migration.
Une migration manuelle n'est requise que lorsque vous voulez recrypter tous les objets secrets Kubernetes existants et inchangés en une seule opération.

Remarque

Cette procédure s'applique uniquement aux clusters qui utilisent une clé de cryptage maître que vous gérez pour crypter les objets secrets Kubernetes au repos dans etcd. Elle ne s'applique pas aux clusters qui utilisent uniquement le cryptage par défaut des volumes de stockage de blocs contenant etcd.

Avant de commencer

Avant de migrer des objets de clé secrète Kubernetes vers le fournisseur KMS version 2 :

Vérifiez que le cluster utilise une clé de cryptage maître dans le service Oracle Cloud Infrastructure Vault que vous gérez pour crypter les clés secrètes Kubernetes au repos. Reportez-vous à Cryptage des clés secrètes Kubernetes inactives dans Etcd.
Mettez à niveau le plan de contrôle de cluster vers la version 1.36.1 ou ultérieure de Kubernetes. Reportez-vous à Mise à niveau de la version de la plate-forme de contrôle dans un cluster sur Kubernetes.
Configurez kubectl pour accéder au cluster. Reportez-vous à Configuration de l'accès à un cluster.
Assurez-vous que votre identité Kubernetes dispose des droits d'accès permettant de créer, d'obtenir, de surveiller et de supprimer la ressource storageversionmigrations.storagemigration.k8s.io de niveau cluster. Un administrateur de cluster dispose généralement de ces autorisations.
Si vous utilisez une solution de sauvegarde telle que Velero, effectuez une sauvegarde en cours qui inclut tous les objets de clé secrète Kubernetes et vérifiez que la sauvegarde s'est terminée correctement. Protégez la sauvegarde en fonction des exigences de sécurité de votre organisation car elle contient des données sensibles.
Prévoyez de surveiller la migration jusqu'à ce qu'elle réussisse. La migration lit et réécrit tous les objets de clé secrète Kubernetes du cluster et peut générer une activité d'API Kubernetes supplémentaire. La migration des clusters plus grands peut prendre plus de temps.

Vérification de la disponibilité du cluster

Vous ne pouvez pas afficher la configuration du fournisseur KMS du moteur Kubernetes interne. Utilisez plutôt la version du plan de contrôle Kubernetes et le repérage d'API Kubernetes pour vérifier que le cluster est prêt pour la migration :

Vérifiez les versions du client et du serveur Kubernetes en saisissant ce qui suit :
```
kubectl version
```
Vérifiez que Server Version est v1.36.1 ou une version ultérieure.

La version du serveur est la version de Kubernetes exécutée sur le plan de contrôle de cluster. Les versions de Kubernetes exécutées sur les noeuds de processus actif ne déterminent pas si la migration de la version 2 du fournisseur KMS est disponible.

Vérifiez que l'API de migration des versions de stockage est disponible en saisissant ce qui suit :

kubectl api-resources --api-group=storagemigration.k8s.io

Vérifiez que la sortie inclut la ressource storageversionmigrations, comme suit :


NAME                         SHORTNAMES   APIVERSION                         NAMESPACED   KIND
storageversionmigrations                  storagemigration.k8s.io/v1beta1    false        StorageVersionMigration

Vérifiez que votre identité Kubernetes peut créer, surveiller et supprimer une migration en saisissant la commande suivante :
```
kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i get storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i watch storageversionmigrations.storagemigration.k8s.io
```
```
kubectl auth can-i delete storageversionmigrations.storagemigration.k8s.io
```
Chaque commande doit renvoyer yes.

Si une commande renvoie no, demandez à un administrateur de cluster d'effectuer la migration ou d'accorder les droits d'accès RBAC Kubernetes requis.

Vous pouvez démarrer la migration lorsque tous les éléments suivants sont vrais :

Le cluster utilise une clé de cryptage maître que vous gérez pour crypter les objets de clé secrète Kubernetes.
Le plan de contrôle de cluster exécute Kubernetes version 1.36.1 ou ultérieure.
L'API de migration de version de stockage est disponible.
Votre identité Kubernetes dispose des droits d'accès requis.

Si l'API de migration de la version de stockage n'est pas disponible, n'essayez pas d'utiliser une procédure de réécriture en masse différente. Vérifiez que kubectl est connecté au cluster prévu et que la mise à niveau du plan de contrôle est terminée. Si l'API reste indisponible, contactez le support technique Oracle.

Migration des objets secrets Kubernetes existants

Pour plus d'informations sur l'utilisation de l'API de migration des versions de stockage Kubernetes pour migrer des objets stockés, reportez-vous à Migration d'objets Kubernetes à l'aide de la migration des versions de stockage dans la documentation Kubernetes.

Pour recrypter tous les objets de clé secrète Kubernetes existants à l'aide du fournisseur KMS version 2 :

Créez un fichier nommé migrate-secrets-to-kms-v2.yaml avec le contenu suivant :
```
apiVersion: storagemigration.k8s.io/v1beta1
kind: StorageVersionMigration
metadata:
  name: migrate-secrets-to-kms-v2
spec:
  resource:
    group: ""
    resource: secrets
```
La valeur group vide identifie le groupe d'API de coeur Kubernetes. La valeur resource: secrets limite la migration vers les objets secrets Kubernetes.

Une ressource StorageVersionMigration est de portée cluster. La migration inclut donc des objets de clé secrète Kubernetes dans tous les espaces de noms.
Créez la migration :
```
kubectl create -f migrate-secrets-to-kms-v2.yaml
```
La création de la ressource demande au migrateur de version de stockage Kubernetes de lire et de réécrire les objets de clé secrète Kubernetes. L'opération ne modifie pas intentionnellement les valeurs de clé secrète. Lorsque chaque objet est écrit, le serveur d'API Kubernetes le crypte à l'aide de la configuration active du fournisseur KMS version 2.
Surveillez la migration et attendez qu'elle aboutisse :
```
kubectl wait \
  --for=condition=Succeeded \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  --timeout=24h
```
Une commande réussie renvoie une sortie similaire à la suivante :
```
storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 condition met
```
Le délai d'expiration contrôle la durée pendant laquelle kubectl attend la condition. L'atteinte du délai d'expiration n'annule pas une migration en cours d'exécution.

Vérification de la migration

Pour confirmer la réussite de la migration, procédez comme suit :

Obtenir le statut de migration :

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

Dans la liste status.conditions, vérifiez que la condition Succeeded a la valeur True, comme suit :

status:
  conditions:
  - type: Succeeded
    status: "True"
    reason: StorageVersionMigrationSucceeded

Le statut Succès confirme que Kubernetes a réécrit les objets secrets. Pour un cluster qui utilise une clé de cryptage maître que vous gérez et qui exécute Kubernetes version 1.36.1 ou ultérieure, les objets réécrits sont cryptés à l'aide du fournisseur KMS version 2.

Une fois la migration effectuée, vous pouvez supprimer la ressource de migration terminée :

kubectl delete \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

Vous pouvez également supprimer le fichier migrate-secrets-to-kms-v2.yaml local.

La suppression de la ressource StorageVersionMigration n'annule pas la migration et ne supprime aucun objet de clé secrète Kubernetes.

Dépannage de la migration KMS v2

L'API de migration de version de stockage n'est pas répertoriée

Si la commande kubectl api-resources ne répertorie pas la ressource storageversionmigrations, vérifiez que :

kubectl utilise le contexte pour le cluster prévu.
La valeur Server Version signalée par kubectl version est v1.36.1 ou ultérieure.
La mise à niveau du plan de contrôle a réussi.

Les versions de Kubernetes exécutées sur les noeuds de processus actif ne déterminent pas si l'API de migration est disponible.

Si toutes ces conditions sont remplies et que l'API reste indisponible, contactez le support technique Oracle. N'essayez pas d'utiliser une autre procédure de réécriture en masse.

La migration ne peut pas être créée

Si la commande kubectl create renvoie une erreur Forbidden, vérifiez que votre identité Kubernetes peut créer la ressource de migration :

kubectl auth can-i create storageversionmigrations.storagemigration.k8s.io

Si la commande renvoie no, demandez à un administrateur de cluster d'effectuer la migration ou d'accorder les droits d'accès RBAC Kubernetes requis.

Si la commande kubectl create renvoie une erreur AlreadyExists, examinez la migration existante :

kubectl get \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2 \
  -o yaml

Si la migration existante s'est terminée avec succès et que vous voulez exécuter une nouvelle migration, supprimez la ressource StorageVersionMigration terminée avant de la créer à nouveau.

La migration ne réussit pas

Examinez le statut de migration et les événements associés :

kubectl describe \
  storageversionmigration.storagemigration.k8s.io/migrate-secrets-to-kms-v2

Si la condition Failed est True ou si la migration reste incomplète, conservez la sortie de la commande et contactez le support technique Oracle.

Les objets de clé secrète Kubernetes qui n'ont pas été réécrits restent lisibles à l'aide de la restauration du fournisseur KMS version 1. Les nouveaux objets secrets et les objets secrets existants mis à jour via des opérations Kubernetes normales continuent d'être cryptés à l'aide du fournisseur KMS version 2.

Documentation Oracle Cloud Infrastructure