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

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Intégration entre Secret Manager et Google Kubernetes Engine (GKE) permet de stocker des données sensibles telles que des mots de passe et des certificats utilisés par GKE vos clusters 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. Installer le module complémentaire Secret Manager sur une instance nouvelle ou existante cluster GKE.
2. Configurez des applications pour s'authentifier auprès de l'API Secret Manager.
3. Définissez les secrets à installer sur les pods Kubernetes à l'aide d'un fichier YAML SecretProviderClass.
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 du système de fichiers du conteneur.

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

Important :Ce document utilise le terme secret pour désigner les données sensibles. stocké dans Secret Manager, et non à l'objet Secret l'API GKE.

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 à Secret Manager des secrets depuis GKE sans entraîner de coûts 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 accéder de manière sélective aux secrets des pods GKE à l'aide du le module complémentaire Secret Manager. Ce faisant, vous pouvez utiliser les fonctionnalités proposées par comme le chiffrement CMEK, le contrôle ultraprécis des accès la rotation gérée, la gestion du cycle de vie et les journaux d'audit, ainsi que l'utilisation les fonctionnalités de Kubernetes, comme la transmission de secrets aux conteneurs sous la forme les volumes installés.
• Le module complémentaire Secret Manager est compatible avec les clusters standards et Autopilot.
• Le module complémentaire Secret Manager accepte les déploiements linux/arm64 et linux/amd64.

Limites

Cette version Preview de Secret Manager ne prend pas en charge les fonctionnalités suivantes, qui sont disponibles dans l'Open Source Pilote CSI du magasin de secrets:

• Rotation automatique des secrets
• Synchroniser en tant que secret Kubernetes

Avant de commencer

• Activer les API Secret Manager and Google Kubernetes Engine.

  Activer les API

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

  Remarque :Pour les installations de gcloud CLI existantes, veillez à définir le paramètre Propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs dans la gcloud CLI : les suivants: One of [--zone, --region, --location] must be supplied: Please specify location.

• Assurez-vous que votre cluster exécute GKE version 1.29 ou ultérieure avec une image de nœud Linux. Le module complémentaire Secret Manager n'est pas compatible avec Windows Nœuds de serveur.

Installer le module complémentaire Secret Manager

Vous pouvez installer le module complémentaire Secret Manager sur les deux clusters standards ainsi que des clusters Autopilot. Assurez-vous que la fédération d'identité de charge de travail pour GKE est activée sur le cluster standard. 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 Workload Identity pour s'authentifier auprès de l'API Secret Manager.

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

Pour installer le module complémentaire Secret Manager lors de la création d'un cluster, procédez comme suit : procédez comme suit:

Cluster standard

• Pour activer le module complémentaire Secret Manager sur une nouvelle Pour un cluster standard, exécutez la commande suivante:

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

  Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • LOCATION: région ou zone Compute Engine du cluster.
  • VERSION: version de GKE spécifique que vous souhaitez utiliser. Vérifier que votre cluster exécute la version de GKE 1.29 ou version ultérieure. Si la valeur par défaut version disponible n'inclut pas cette version, utilisez l'indicateur --release-channel pour choisir version disponible qui le fait.
  • PROJECT_ID : ID de votre projet Google Cloud

Cluster Autopilot

• Pour activer le module complémentaire Secret Manager sur un Autopilot, exécutez la commande suivante:

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

  Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • VERSION: version de GKE spécifique que vous souhaitez utiliser. Vérifier que votre cluster exécute la version de GKE 1.29 ou version ultérieure. Si la version disponible par défaut n'inclut pas cette version, utilisez l'indicateur --release-channel pour choisir version disponible qui le fait.
  • LOCATION : région souhaitée pour votre cluster, par exemple us-central1.

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

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

Pour activer le module complémentaire Secret Manager sur un cluster existant, exécutez la commande suivante:

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

Remplacez les éléments suivants :

• CLUSTER_NAME: nom de votre cluster existant
• LOCATION: région de votre cluster, par exemple us-central1.

Configurer des applications pour s'authentifier 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 installé lors de l'authentification API Secret Manager. Pour permettre à vos applications de s'authentifier auprès 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 utiliser un compte de service Kubernetes existant dans n'importe quel espace de noms, y compris le compte de service Kubernetes par défaut.

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

Les pods qui utilisent le compte de service Kubernetes configuré s'authentifient automatiquement comme identifiant principal IAM qui correspond ServiceAccount Kubernetes lors de l'accès à 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 pour le ServiceAccount

2. Appliquez le fichier manifeste :

   kubectl apply -f service-account.yaml
   

3. Créer une stratégie d'autorisation IAM qui référence la nouvelle instance Kubernetes ServiceAccount 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 de votre projet Google Cloud numérique
   • PROJECT_ID: ID du projet Google Cloud contenant votre cluster GKE.
   • NAMESPACE: nom de l'espace de noms Kubernetes pour le ServiceAccount
   • 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 référence les ressources ServiceAccount 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 de votre projet Google Cloud numérique
• PROJECT_ID: ID du projet Google Cloud contenant votre cluster GKE.
• NAMESPACE: nom de l'espace de noms Kubernetes pour le ServiceAccount
• 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 lister les secrets à installer et le nom de fichier pour 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 où sera la valeur du secret installé. Vous pouvez créer plusieurs fichiers à l'aide des outils resourceName et path. variables.

2. Appliquez le fichier manifeste :

   kubectl apply -f app-secrets.yaml
   

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

   kubectl get SecretProviderClasses
   

Configurer un volume sur lequel les secrets seront installés

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: POD_NAME
     namespace: default
   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é
   • KSA_NAME: compte de service Kubernetes que vous avez configuré à l'étape Configurer le compte de service Workload Identity
   • IMAGE_NAME : nom de l'image de conteneur
   • SECRET_PROVIDER_CLASS_NAME: nom de votre objet SecretProviderClass.

2. Appliquez la configuration à votre cluster.

   kubectl apply -f my-pod.yaml
   

Cette étape permet d'installer un volume mysecret dans /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 existant du magasin de secrets

Si vous migrez vers le module complémentaire Secret Manager depuis votre l'installation existante du pilote CSI Secret Store ; modifiez le fichier manifeste de votre pod comme suit:

1. Modifiez le nom de votre SecretProviderClass et de votre provider comme indiqué. 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 cluster 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 Sur un cluster standard ou Autopilot, exécutez la commande suivante : :

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

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster
• REGION: région de votre cluster, par exemple us-central1