Utiliser le module complémentaire Secret Manager avec Google Kubernetes Engine

L'intégration entre Secret Manager et Google Kubernetes Engine (GKE) vous permet de stocker des données sensibles telles que les mots de passe et les certificats utilisés par les clusters GKE en tant que secrets dans Secret Manager.

Cette page explique comment utiliser le module complémentaire Secret Manager pour accéder aux secrets stockés dans Secret Manager en tant que volumes installés dans des pods Kubernetes.

Ce processus comprend les étapes suivantes :

1. Activez le module complémentaire Secret Manager sur un cluster GKE nouveau ou existant.
2. Configurez les applications pour qu'elles s'authentifient auprès de l'API Secret Manager.
3. Définissez les secrets à monter sur les pods Kubernetes à l'aide d'un fichier YAML SecretProviderClass. Le module complémentaire Secret Manager est compatible avec les secrets globaux et régionaux.
4. Créez un volume dans lequel les secrets seront installés. Une fois le volume associé, les applications du conteneur peuvent accéder aux données dans le système de fichiers du conteneur.

Le module complémentaire Secret Manager est dérivé du pilote CSI Kubernetes Secret Store Open Source et du fournisseur Google Secret Manager. Si vous utilisez le pilote CSI Secrets Store Open Source pour accéder aux secrets, vous pouvez migrer vers le module complémentaire Secret Manager. Pour en savoir plus, consultez Migrer depuis le pilote CSI Secrets Store existant.

Avantages

Le module complémentaire Secret Manager offre les avantages suivants :

• Vous pouvez utiliser une solution entièrement gérée et compatible pour accéder aux secrets Secret Manager depuis GKE, sans frais opérationnels.
• Vous n'avez pas besoin d'écrire de code personnalisé pour accéder aux secrets stockés dans Secret Manager.
• Vous pouvez stocker et gérer tous vos secrets de manière centralisée dans Secret Manager, et y accéder de manière sélective à partir des pods GKE à l'aide du module complémentaire Secret Manager. Vous pouvez ainsi utiliser les fonctionnalités proposées par Secret Manager, telles que le chiffrement CMEK, le contrôle des accès précis, la rotation gérée, la gestion du cycle de vie et les journaux d'audit, ainsi que les fonctionnalités Kubernetes, telles que la transmission de secrets aux conteneurs sous forme de volumes montés.
• Le module complémentaire Secret Manager est compatible avec les clusters Standard et Autopilot.
• Le module complémentaire Secret Manager est compatible avec les nœuds qui utilisent des images de nœuds Container-Optimized OS ou Ubuntu.

Limites

Le module complémentaire Secret Manager présente les limites suivantes :

• Le module complémentaire Secret Manager n'est pas compatible avec la fonctionnalité suivante disponible dans le pilote CSI Secrets Store Open Source :

  • Synchroniser en tant que secret Kubernetes

• Le module complémentaire Secret Manager n'est pas compatible avec les nœuds Windows Server.

Avant de commencer

• Enable the Secret Manager and Google Kubernetes Engine APIs.

  Enable the APIs

• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

  Vous ne pouvez pas configurer manuellement le module complémentaire Secret Manager à l'aide de Google Cloud SDK ou de la console Google Cloud .

• Assurez-vous que votre cluster exécute GKE version 1.27.14-gke.1042001 ou ultérieure avec une image de nœud Linux.

• Si vous utilisez un cluster GKE Standard, assurez-vous que la fédération d'identité de charge de travail pour GKE est activée sur votre cluster. La fédération d'identité de charge de travail pour GKE est activée par défaut sur un cluster Autopilot. Les pods Kubernetes utilisent la fédération d'identité de charge de travail pour GKE afin de s'authentifier auprès de l'API Secret Manager.

Activer le module complémentaire Secret Manager

Vous pouvez activer le module complémentaire Secret Manager sur les clusters Standard et Autopilot.

Activer le module complémentaire Secret Manager sur un nouveau cluster GKE

Pour activer le module complémentaire Secret Manager lors de la création du cluster, procédez comme suit :

gcloud container clusters create CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \
    --cluster-version=VERSION \
    --workload-pool=PROJECT_ID.svc.id.goog

gcloud container clusters create CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `
    --cluster-version=VERSION `
    --workload-pool=PROJECT_ID.svc.id.goog

gcloud container clusters create CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^
    --cluster-version=VERSION ^
    --workload-pool=PROJECT_ID.svc.id.goog

gcloud container clusters create-auto CLUSTER_NAME \
    --enable-secret-manager \
    --cluster-version=VERSION \
    --location=LOCATION

gcloud container clusters create-auto CLUSTER_NAME `
    --enable-secret-manager `
    --cluster-version=VERSION `
    --location=LOCATION

gcloud container clusters create-auto CLUSTER_NAME ^
    --enable-secret-manager ^
    --cluster-version=VERSION ^
    --location=LOCATION

Après avoir activé le module complémentaire Secret Manager, vous pouvez utiliser le pilote CSI Secrets Store dans les volumes Kubernetes à l'aide du nom du pilote et de l'approvisionneur : secrets-store-gke.csi.k8s.io.

Activer le module complémentaire Secret Manager sur un cluster GKE existant

Pour activer le module complémentaire Secret Manager sur un cluster existant, procédez comme suit :

gcloud container clusters update CLUSTER_NAME \
    --enable-secret-manager \
    --location=LOCATION \

gcloud container clusters update CLUSTER_NAME `
    --enable-secret-manager `
    --location=LOCATION `

gcloud container clusters update CLUSTER_NAME ^
    --enable-secret-manager ^
    --location=LOCATION ^

Configurer la rotation automatique des secrets

Vous pouvez configurer le module complémentaire Secret Manager pour qu'il effectue automatiquement la rotation des secrets. Ainsi, les secrets mis à jour dans Secret Manager après le déploiement initial du pod sont automatiquement et régulièrement transférés vers le pod. La rotation automatique des secrets montés permet aux applications de recevoir automatiquement les secrets mis à jour sans nécessiter de redémarrage ni d'intervention manuelle. Cette fonctionnalité permet de s'assurer que les applications utilisent toujours les secrets les plus récents.

Notez les points suivants concernant la configuration de la rotation automatique des secrets :

• La rotation automatique des secrets est une configuration facultative.
• Vous pouvez configurer cette fonctionnalité lorsque vous créez un cluster ou que vous mettez à jour un cluster existant.
• La rotation automatique des secrets est compatible avec GKE version 1.32.2-gke.1059000 ou ultérieure.

Pour configurer la rotation automatique des secrets, vous devez activer la fonctionnalité enable-secret-manager-rotation et configurer l'intervalle de rotation en définissant secret-manager-rotation-interval.

Par exemple, pour configurer la rotation automatique sur un cluster GKE existant, utilisez la commande suivante :

  gcloud beta container clusters update CLUSTER_NAME \
      --enable-secret-manager \
      --location=LOCATION \
      --enable-secret-manager-rotation \
      --secret-manager-rotation-interval=ROTATION_INTERVAL

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• LOCATION : emplacement de votre cluster, par exemple us-central1
• ROTATION_INTERVAL : intervalle de rotation en secondes. L'intervalle de rotation par défaut est de 120 secondes.

Vérifier l'installation du module complémentaire Secret Manager

Pour vérifier que le module complémentaire Secret Manager est installé sur le cluster Kubernetes, exécutez la commande suivante :

  gcloud container clusters describe CLUSTER_NAME --location LOCATION | grep secretManagerConfig -A 4

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• LOCATION : emplacement de votre cluster, par exemple us-central1

Configurer les applications pour qu'elles s'authentifient auprès de l'API Secret Manager

Le fournisseur Google Secret Manager utilise l'identité de charge de travail du pod sur lequel un secret est monté lors de l'authentification auprès de l'API Secret Manager. Pour permettre à vos applications de s'authentifier auprès de l'API Secret Manager à l'aide de la fédération d'identité de charge de travail pour GKE, procédez comme suit :

• Créez un compte de service Kubernetes ou utilisez-en un existant dans le même espace de noms que le pod sur lequel vous souhaitez installer le secret.

• Créez une stratégie d'autorisation Identity and Access Management (IAM) pour le secret dans Secret Manager.

Les pods qui utilisent le compte de service Kubernetes configuré s'authentifient automatiquement en tant qu'identifiant principal IAM correspondant au compte de service Kubernetes lorsqu'ils accèdent à l'API Secret Manager.

Créer un compte de service Kubernetes

1. Enregistrez le manifeste suivant sous le nom service-account.yaml :

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: KSA_NAME
     namespace: NAMESPACE
   

   Remplacez les éléments suivants :

   • KSA_NAME : nom de votre nouveau compte de service Kubernetes
   • NAMESPACE : nom de l'espace de noms Kubernetes du compte de service.

2. Appliquez le fichier manifeste :

   kubectl apply -f service-account.yaml
   

3. Créez une stratégie d'autorisation IAM qui fait référence au nouveau compte de service Kubernetes et accordez-lui l'autorisation d'accéder au secret :

   gcloud secrets add-iam-policy-binding SECRET_NAME \
       --role=roles/secretmanager.secretAccessor \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
   

   Remplacez les éléments suivants :

   • SECRET_NAME : nom du secret dans Secret Manager.
   • PROJECT_NUMBER : numéro numérique de votre projet Google Cloud
   • PROJECT_ID : ID de projet du projet Google Cloud contenant votre cluster GKE
   • NAMESPACE : nom de l'espace de noms Kubernetes du compte de service.
   • KSA_NAME : nom de votre compte de service Kubernetes existant

Utiliser un compte de service Kubernetes existant

Créez une stratégie d'autorisation IAM qui fait référence au compte de service Kubernetes existant et accordez-lui l'autorisation d'accéder au secret :

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --role=roles/secretmanager.secretAccessor \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME

Remplacez les éléments suivants :

• SECRET_NAME : nom du secret dans Secret Manager.
• PROJECT_NUMBER : numéro numérique de votre projet Google Cloud
• PROJECT_ID : ID de projet du projet Google Cloud contenant votre cluster GKE
• NAMESPACE : nom de l'espace de noms Kubernetes du compte de service.
• KSA_NAME : nom de votre compte de service Kubernetes existant

Définir les secrets à installer

Pour spécifier les secrets à installer en tant que fichiers dans le pod Kubernetes, créez un fichier manifeste YAML SecretProviderClass et listez les secrets à installer ainsi que le nom de fichier sous lequel les installer. Procédez comme suit :

1. Enregistrez le manifeste suivant sous le nom app-secrets.yaml :

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: SECRET_PROVIDER_CLASS_NAME
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION"
           path: "FILENAME.txt"
   

   Remplacez les éléments suivants :

   • SECRET_PROVIDER_CLASS_NAME : nom de votre objet SecretProviderClass.
   • PROJECT_ID : ID de votre projet.
   • SECRET_NAME : nom du secret.
   • SECRET_VERSION : version du secret.
   • FILENAME.txt : nom du fichier dans lequel la valeur du secret sera installée. Vous pouvez créer plusieurs fichiers à l'aide des variables resourceName et path.

   Pour un secret régional, resourceName correspond au chemin d'accès complet à la ressource secrète, y compris l'emplacement du secret régional. Par exemple, "projects/PROJECT_ID/locations/LOCATION/secrets/SECRET_NAME/versions/SECRET_VERSION"

2. Appliquez le fichier manifeste :

   kubectl apply -f app-secrets.yaml
   

3. Vérifiez que l'objet SecretProviderClass a été créé :

   kubectl get SecretProviderClasses
   

Configurer un volume dans lequel les secrets seront installés

1. Enregistrez la configuration suivante sous my-pod.yaml :

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     containers:
     - image: IMAGE_NAME
       imagePullPolicy: IfNotPresent
       name: POD_NAME
       resources:
         requests:
           cpu: 100m
       stdin: true
       stdinOnce: true
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       tty: true
       volumeMounts:
         - mountPath: "/var/secrets"
           name: mysecret
     volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: SECRET_PROVIDER_CLASS_NAME
   

   Remplacez les éléments suivants :

   • POD_NAME : nom du pod Kubernetes dans lequel le secret est installé
   • NAMESPACE : nom de l'espace de noms Kubernetes du compte de service.
   • KSA_NAME : compte de service Kubernetes que vous avez configuré à l'étape Configurer les applications pour qu'elles s'authentifient auprès de l'API Secret Manager
   • IMAGE_NAME : nom de l'image de conteneur
   • SECRET_PROVIDER_CLASS_NAME : nom de votre objet SecretProviderClass

2. Dans les clusters standards uniquement, ajoutez les éléments suivants au champ template.spec pour placer les pods sur des pools de nœuds qui utilisent la fédération d'identité de charge de travail pour GKE.

   Ignorez cette étape dans les clusters Autopilot, qui rejettent ce nodeSelector, car chaque nœud utilise la fédération d'identité de charge de travail pour GKE.

   spec:
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
   

3. Appliquez la configuration à votre cluster.

   kubectl apply -f my-pod.yaml
   

Cette étape permet de monter un volume mysecret à /var/secrets à l'aide du pilote CSI (secrets-store-gke.csi.k8s.io). Ce volume fait référence à l'objet SecretProviderClass qui sert de fournisseur.

Migrer depuis le pilote CSI Secrets Store existant

Si vous migrez vers le module complémentaire Secret Manager à partir de votre installation existante du pilote CSI Secrets Store, mettez à jour le fichier manifeste de votre pod comme suit :

1. Mettez à jour le nom de votre SecretProviderClass et de votre provider comme décrit dans le fichier manifeste suivant :

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: app-secrets-gke
   spec:
     provider: gke
     parameters:
       secrets: |
         - resourceName: "projects/<project_id>/secrets/<secret_name>/versions/<secret_version>"
           path: "good1.txt"
   

2. Mettez à jour driver et secretProviderClass pour votre volume Kubernetes, comme décrit dans le fichier manifeste suivant :

   volumes:
     - name: mysecret
       csi:
         driver: secrets-store-gke.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "app-secrets-gke"
   

Désactiver le module complémentaire Secret Manager

Pour désactiver le module complémentaire Secret Manager sur un cluster Standard ou Autopilot existant, exécutez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --no-enable-secret-manager \
    --region=REGION \

gcloud container clusters update CLUSTER_NAME `
    --no-enable-secret-manager `
    --region=REGION `

gcloud container clusters update CLUSTER_NAME ^
    --no-enable-secret-manager ^
    --region=REGION ^