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 :

Installez le module complémentaire Secret Manager sur un cluster GKE nouveau ou existant.
Configurez les applications pour qu'elles s'authentifient auprès de l'API Secret Manager.
Définissez les secrets à installer sur les pods Kubernetes à l'aide d'un fichier YAML SecretProviderClass.
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 dérivé du pilote CSI du magasin de secrets Kubernetes Open Source et du fournisseur Google Secret Manager. Si vous utilisez le pilote CSI Open Source du magasin de secrets pour accéder aux secrets, vous pouvez migrer vers le module complémentaire Secret Manager. Pour en savoir plus, consultez la section Migrer depuis le pilote CSI du magasin de secrets 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 coûts opérationnels supplémentaires.
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 module complémentaire Secret Manager. Ainsi, vous pouvez utiliser les fonctionnalités offertes par Secret Manager, telles que 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 les fonctionnalités de Kubernetes telles que la transmission de secrets aux conteneurs sous la forme de volumes installés.
Le module complémentaire Secret Manager est compatible avec les clusters standards et les clusters Autopilot.
Le module complémentaire Secret Manager est compatible avec les déploiements linux/arm64 et linux/amd64.

Limites

Cette version Preview du module complémentaire Secret Manager n'est pas compatible avec les fonctionnalités suivantes, disponibles dans le pilote CSI Open Source du Secret Store:

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 initialize la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version à l'aide de la commande gcloud components update.

Remarque :Pour les installations existantes de gcloud CLI, veillez à définir les 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 comme suit: 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 les nœuds Windows Server.

Installer le module complémentaire Secret Manager

Vous pouvez installer le module complémentaire Secret Manager sur les clusters standards ainsi que sur les 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:

Cluster standard

Pour activer le module complémentaire Secret Manager sur un nouveau 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. Assurez-vous que votre cluster exécute GKE version 1.29 ou ultérieure. Si la version disponible par défaut n'inclut pas cette version, utilisez l'option --release-channel pour choisir une version qui comporte cette version.
- PROJECT_ID : ID de votre projet Google Cloud

Cluster Autopilot

Pour activer le module complémentaire Secret Manager sur un nouveau cluster 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. Assurez-vous que votre cluster exécute GKE version 1.29 ou ultérieure. Si la version disponible par défaut n'inclut pas cette version, utilisez l'option --release-channel pour en choisir une.
- LOCATION : région souhaitée pour votre cluster, par exemple us-central1.

Après avoir activé le module complémentaire Secret Manager, vous pouvez utiliser le pilote CSI Secret Store dans les volumes Kubernetes en utilisant le nom du pilote et 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 les applications pour qu'elles s'authentifient auprès de l'API Secret Manager

Le fournisseur Secret Manager de Google utilise l'identité de charge de travail du pod sur lequel un secret est installé lors de l'authentification auprès de l'API Secret Manager. Pour autoriser vos applications à 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:

Utilisez une stratégie Identity and Access Management (IAM) pour lier un compte de service IAM à un ServiceAccount Kubernetes. Vous pouvez créer un ServiceAccount Kubernetes ou utiliser un ServiceAccount Kubernetes existant dans n'importe quel espace de noms, y compris le ServiceAccount Kubernetes par défaut.
Utilisez des liaisons IAM pour accorder au compte de service IAM l'accès aux secrets dans Secret Manager.

Les pods qui utilisent le ServiceAccount Kubernetes configuré s'authentifient automatiquement en tant que compte de service IAM lors de l'accès à l'API Secret Manager.

Lier le ServiceAccount Kubernetes au compte de service IAM

Autorisez le ServiceAccount Kubernetes à emprunter l'identité du compte de service IAM en ajoutant une liaison de stratégie IAM entre les deux comptes de service.

Utiliser un nouveau ServiceAccount Kubernetes

Enregistrez le manifeste suivant sous le nom service-account.yaml :
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: KSA_NAME
  namespace: NAMESPACE
  annotations:
    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
Remplacez les éléments suivants :
- KSA_NAME: nom de votre nouveau ServiceAccount Kubernetes.
- NAMESPACE: nom de l'espace de noms Kubernetes pour le ServiceAccount
- GSA_NAME: nom du compte de service IAM
- PROJECT_ID: ID du projet Google Cloud pour votre compte de service IAM
Appliquez le fichier manifeste :
```
kubectl apply -f service-account.yaml
```

Pour lier le compte de service IAM à un nouveau ServiceAccount Kubernetes, exécutez la commande suivante:

gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Utiliser un ServiceAccount Kubernetes existant

Pour lier le compte de service IAM à un compte de service Kubernetes existant, exécutez la commande suivante:

gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Remplacez les éléments suivants :

KSA_NAME: nom de votre ServiceAccount Kubernetes existant
NAMESPACE: nom de l'espace de noms Kubernetes pour le ServiceAccount
GSA_NAME: nom du compte de service IAM
PROJECT_ID: ID du projet Google Cloud pour votre compte de service IAM

Accorder au compte de service IAM l'autorisation d'accéder au secret

Pour autoriser le compte de service à accéder au secret, exécutez la commande suivante:

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member=serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/secretmanager.secretAccessor

Remplacez les éléments suivants :

SECRET_NAME: nom du secret dans Secret Manager
GSA_NAME: nom du compte de service IAM
PROJECT_ID: ID du projet Google Cloud pour votre compte de service IAM

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 répertoriez les secrets à installer, ainsi que le nom de fichier sous lequel les installer. Procédez comme suit :

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.
Appliquez le fichier manifeste :
```
kubectl apply -f app-secrets.yaml
```
Vérifiez que l'objet SecretProviderClass est créé:
```
kubectl get SecretProviderClasses
```

Configurer un volume dans lequel les secrets seront installés

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: le ServiceAccount 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

Appliquez la configuration à votre cluster.
```
kubectl apply -f my-pod.yaml
```

Cette étape installe un volume mysecret à l'emplacement /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 à partir du pilote CSI du magasin de secrets existant

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

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"

Mettez à jour les valeurs driver et secretProviderClass de 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 existant ou sur un cluster 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