L'intégration entre Secret Manager et Google Kubernetes Engine (GKE) vous permet de stocker des données sensibles telles que des mots de passe et des 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 des applications pour s'authentifier 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 Kubernetes Secret Store et du 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 Migrer depuis le pilote CSI existant du magasin de secrets.
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 de Secret Manager depuis GKE sans 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 module complémentaire Secret Manager. Ainsi, vous pouvez utiliser les fonctionnalités proposées par Secret Manager, telles que le chiffrement CMEK, le contrôle pré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 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 Autopilot.
- Le module complémentaire Secret Manager accepte les déploiements
linux/arm64
etlinux/amd64
.
Limites
Cette version Preview du module complémentaire Secret Manager n'est pas compatible avec les fonctionnalités suivantes, qui sont disponibles dans le pilote CSI Open Source Secret Store:
Avant de commencer
-
Activer les API Secret Manager and Google Kubernetes Engine.
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 en exécutant la commande
gcloud components update
.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 à la fois sur les clusters standards et 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 clusterLOCATION
: 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 en choisir une.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 clusterVERSION
: 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 disponible.LOCATION
: région souhaitée pour votre cluster, par exempleus-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 existantLOCATION
: région de votre cluster, telle queus-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 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:
Créez un compte de service Kubernetes ou utilisez 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.
Lors de l'accès à l'API 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.
Créer un compte de service Kubernetes
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 KubernetesNAMESPACE
: nom de l'espace de noms Kubernetes pour le ServiceAccount
Appliquez le fichier manifeste :
kubectl apply -f service-account.yaml
Créez une stratégie d'autorisation IAM qui référence le 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 ManagerPROJECT_NUMBER
: numéro de votre projet Google Cloud numériquePROJECT_ID
: ID du projet Google Cloud contenant votre cluster GKE.NAMESPACE
: nom de l'espace de noms Kubernetes pour le ServiceAccountKSA_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 le 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 ManagerPROJECT_NUMBER
: numéro de votre projet Google Cloud numériquePROJECT_ID
: ID du projet Google Cloud contenant votre cluster GKE.NAMESPACE
: nom de l'espace de noms Kubernetes pour le ServiceAccountKSA_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 répertoriez les secrets à installer et 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 objetSecretProviderClass
.PROJECT_ID
: ID de votre projet.SECRET_NAME
: nom du secretSECRET_VERSION
: version du secretFILENAME.txt
: nom du fichier où la valeur du secret sera installée. Vous pouvez créer plusieurs fichiers à l'aide des variablesresourceName
etpath
.
Appliquez le fichier manifeste :
kubectl apply -f app-secrets.yaml
Vérifiez que l'objet
SecretProviderClass
a bien été créé:kubectl get SecretProviderClasses
Configurer un volume sur 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 sur lequel le secret est installéKSA_NAME
: le compte de service Kubernetes que vous avez configuré à l'étape Configurer le compte de service Workload IdentityIMAGE_NAME
: nom de l'image de conteneurSECRET_PROVIDER_CLASS_NAME
: nom de votre objetSecretProviderClass
.
Appliquez la configuration à votre cluster.
kubectl apply -f my-pod.yaml
Cette étape installe 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 effectuez une migration vers le module complémentaire Secret Manager depuis votre installation existante du pilote CSI Secret Store, mettez à jour le fichier manifeste de votre pod comme suit:
Mettez à jour le nom de votre
SecretProviderClass
et de votreprovider
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
driver
etsecretProviderClass
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 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 clusterREGION
: région de votre cluster, par exempleus-central1