Synchroniser les secrets avec les secrets Kubernetes

Preview

Ce produit ou cette fonctionnalité sont soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits et fonctionnalités de pré-DG sont proposés "en l'état" et peuvent avoir une compatibilité limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce document explique comment synchroniser les secrets stockés dans Secret Manager avec les secrets Kubernetes dans vos clusters Google Kubernetes Engine (GKE).

Le processus de synchronisation permet aux applications exécutées sur GKE d'accéder aux secrets de Secret Manager à l'aide de méthodes Kubernetes standards, telles que les variables d'environnement ou les installations de volumes. Cela est utile pour les applications qui sont déjà conçues pour lire les secrets à partir de l'objet Secret Kubernetes, plutôt que d'avoir à être mises à jour pour accéder directement à Secret Manager.

Recommandation : La fonctionnalité de synchronisation des secrets est une alternative au module complémentaire Secret Manager, qui installe les secrets en tant que fichiers en mémoire directement dans vos pods. Utilisez le module complémentaire Secret Manager chaque fois que votre application le prend en charge, car il s'agit d'une méthode plus sécurisée pour accéder aux secrets de Secret Manager dans GKE.

Avant de commencer

Avant de synchroniser les secrets, remplissez les conditions préalables suivantes :

• Enable the Secret Manager and Google Kubernetes Engine APIs.

  Roles required to enable APIs

  To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

  Enable the APIs

• 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.

• Assurez-vous qu'un cluster GKE est en cours d'exécution. Cette fonctionnalité nécessite GKE version 1.34 ou ultérieure.

• Assurez-vous que Workload Identity Federation for GKE est activée sur votre cluster GKE. Il est obligatoire pour l'authentification. La fédération d'identité de charge de travail pour GKE est activée par défaut sur un cluster Autopilot.

• Assurez-vous de disposer des autorisations IAM (Identity and Access Management) nécessaires pour gérer les clusters GKE et Secret Manager.

Activer la synchronisation des secrets sur un cluster GKE

Activez la fonctionnalité de synchronisation des secrets lorsque vous créez un cluster ou mettez à jour un cluster existant. Cette fonctionnalité est disponible sur les clusters Standard et Autopilot.

Activer la synchronisation des secrets sur un nouveau cluster

Pour créer un cluster avec synchronisation des secrets, utilisez l'une des commandes gcloud CLI suivantes :

Cluster standard

Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

Activez la synchronisation des secrets sans rotation automatique.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync

Activez la synchronisation des secrets avec rotation automatique. L'intervalle par défaut est de deux minutes.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync \
    --enable-secret-sync-rotation

Activez la synchronisation des secrets avec un intervalle de rotation personnalisé. L'intervalle minimal est de 1 minute.

gcloud beta container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-secret-sync \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=1m

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre cluster GKE
• CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle de votre cluster, par exemple us-central1 ou us-east1-a.
• PROJECT_ID : ID de votre projet Google Cloud

Cluster Autopilot

Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

Activez la synchronisation des secrets sans rotation automatique.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync

Activez la synchronisation des secrets avec rotation automatique. L'intervalle par défaut est de deux minutes.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync \
    --enable-secret-sync-rotation

Activez la synchronisation des secrets avec un intervalle de rotation personnalisé. L'intervalle minimal est de 1 minute.

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=1m

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre cluster GKE
• CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle de votre cluster, par exemple us-central1 ou us-east1-a.

Activer la synchronisation des secrets sur un cluster existant

Pour mettre à jour les clusters existants avec la synchronisation des secrets, utilisez l'une des commandes gcloud CLI suivantes :

gcloud

Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

Activer la synchronisation des secrets sur un cluster existant

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync

Activer la rotation avec un intervalle personnalisé

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-secret-sync-rotation \
    --secret-sync-rotation-interval=5m

Désactiver la rotation

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-secret-sync-rotation

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre cluster GKE
• CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle de votre cluster, par exemple us-central1 ou us-east1-a.

Configurer la synchronisation des secrets

Pour synchroniser les secrets, procédez comme suit :

1. Créez un Kubernetes ServiceAccount à l'aide de la commande suivante :

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Remplacez les éléments suivants :

   • KSA_NAME : nom de votre compte de service Kubernetes
   • NAMESPACE : espace de noms Kubernetes dans lequel vous souhaitez créer le compte de service.

2. 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

   Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

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

   Remplacez les éléments suivants :

   • SECRET_PROJECT_ID : ID du projet dans lequel le secret est stocké. Il peut s'agir du même PROJECT_ID si le secret est stocké dans le même projet que le cluster GKE.
   • PROJECT_NUMBER : numéro de votre projet Google Cloud
   • PROJECT_ID : ID de votre projet Google Cloud
   • NAMESPACE : espace de noms Kubernetes
   • KSA_NAME : nom de votre compte de service Kubernetes

3. Créez une ressource personnalisée SecretProviderClass à l'aide d'un fichier manifeste YAML. La ressource SecretProviderClass définit les secrets spécifiques à récupérer dans Secret Manager, y compris leurs noms et chemins de ressources. Le module complémentaire Secret Manager utilise également la ressource SecretProviderClass pour lister les secrets à monter et le nom de fichier sous lequel les monter.

   Créez un fichier spc.yaml avec le contenu suivant :

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

   Remplacez les éléments suivants :

   • SECRET_PROVIDER_CLASS_NAME : nom de votre objet SecretProviderClass.
   • NAMESPACE : espace de noms Kubernetes dans lequel vous créez cette ressource.
   • resourceName : identifiant de ressource complet du secret dans Secret Manager. Il doit inclure l'ID du projet, le nom du secret et la version au format suivant : projects/SECRET_PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION.
     • SECRET_PROJECT_ID : ID du Google Cloud projet dans lequel le secret est stocké. Il peut être identique à PROJECT_ID si le secret est stocké dans le même projet que le cluster GKE.
     • SECRET_NAME : nom du secret.
     • SECRET_VERSION : version du secret. La version du secret doit se trouver dans la même région que le cluster.
   • path : nom de fichier local ou alias sous lequel la valeur secrète sera exposée dans l'environnement Kubernetes. Il s'agit de l'identifiant unique qui associe une version spécifique de Secret Manager à la représentation locale utilisée par le cluster. Lorsque le secret est synchronisé avec un secret Kubernetes à l'aide de la ressource SecretSync, ce chemin d'accès est référencé par le champ sourcePath pour localiser la valeur du secret à synchroniser. Vous pouvez mapper plusieurs secrets (définis par resourceName) à différents noms de chemin d'accès au sein de la même SecretProviderClass.

4. Pour appliquer le fichier manifeste, exécutez la commande suivante :

   kubectl apply -f spc.yaml
   

5. Créez une ressource personnalisée SecretSync à l'aide d'un fichier manifeste YAML. Cette ressource indique au contrôleur de synchronisation de créer ou de mettre à jour un secret Kubernetes en fonction du contenu défini dans SecretProviderClass.

   Créez un fichier secret-sync.yaml avec le contenu suivant :

   apiVersion: secret-sync.gke.io/v1
   kind: SecretSync
   metadata:
     name: KUBERNETES_SECRET_NAME
     namespace: NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     secretProviderClassName: SECRET_PROVIDER_CLASS_NAME
     secretObject:
       type: KUBERNETES_SECRET_TYPE
       data:
         -   sourcePath: "FILENAME.txt"
             targetKey: "TARGET_KEY1"
         -   sourcePath: "FILENAME1.txt"
             targetKey: "TARGET_KEY2"
   

   Remplacez les éléments suivants :

   • KUBERNETES_SECRET_NAME : nom que vous souhaitez attribuer au nouveau secret Kubernetes qui sera créé par la ressource SecretSync.
   • NAMESPACE : espace de noms Kubernetes dans lequel la nouvelle ressource est créée. Il doit s'agir du même espace de noms que SecretProviderClass.
   • KSA_NAME : nom du compte de service Kubernetes que le contrôleur SecretSync utilise pour créer et mettre à jour le secret Kubernetes cible. Ce compte de service doit disposer des autorisations nécessaires pour accéder aux secrets externes de Secret Manager.
   • SECRET_PROVIDER_CLASS_NAME : nom de l'objet SecretProviderClass que vous avez créé à l'étape précédente. La ressource SecretSync l'utilise pour trouver la configuration appropriée pour les secrets.
   • KUBERNETES_SECRET_TYPE : type de secret Kubernetes à créer (Opaque, tls ou docker-registry, par exemple). Cela détermine la façon dont Kubernetes gère les données du secret.
   • sourcePath : nom de fichier local ou alias (valeur du champ path dans SecretProviderClass) qui identifie les données secrètes à récupérer. Le contrôleur SecretSync utilise ce sourcePath pour demander le contenu secret spécifique et le convertir en un nouveau secret Kubernetes.
   • targetKey : clé qui sera utilisée dans la section data du nouveau secret Kubernetes en cours de création. Cela définit la façon dont le contenu secret récupéré à l'aide de sourcePath est nommé et stocké dans l'objet Secret Kubernetes final. L'utilisation de plusieurs entrées dans le tableau de données vous permet de définir plusieurs paires clé/valeur dans le même secret cible.

6. Pour appliquer le fichier manifeste, exécutez la commande suivante :

   kubectl apply -f secret-sync.yaml
   

   Le contrôleur de synchronisation crée un secret Kubernetes dans l'espace de noms spécifié. Ce secret contient les données mappées à partir de Secret Manager.

7. Vérifiez que le secret Kubernetes a été créé :

   kubectl get secret KUBERNETES_SECRET_NAME -n NAMESPACE -o yaml
   

   Remplacez les éléments suivants :

   • KUBERNETES_SECRET_NAME : nom du nouveau secret Kubernetes
   • NAMESPACE : espace de noms Kubernetes dans lequel le nouveau secret est créé

8. Pour résoudre un problème de synchronisation, utilisez la commande suivante :

   kubectl describe secretSync KUBERNETES_SECRET_NAME -n NAMESPACE
   

   Remplacez les éléments suivants :

   • KUBERNETES_SECRET_NAME : nom du nouveau secret Kubernetes
   • NAMESPACE : espace de noms Kubernetes dans lequel le nouveau secret doit exister

Gérer la rotation des secrets

Si vous activez l'indicateur --enable-secret-sync-rotation sur votre cluster, le contrôleur de synchronisation vérifie régulièrement Secret Manager pour détecter de nouvelles versions des secrets spécifiés dans la ressource SecretProviderClass. L'indicateur --secret-sync-rotation-interval détermine la fréquence à laquelle le contrôleur recherche les mises à jour.

Si le contrôleur détecte une nouvelle version de secret dans Secret Manager, il met à jour le secret Kubernetes correspondant. Le contrôleur compare les hachages du contenu secret pour ne mettre à jour les secrets qu'en cas de modification.

Les applications qui utilisent ces secrets doivent détecter et recharger les valeurs secrètes mises à jour à partir du secret Kubernetes. La conception de l'application détermine la façon dont cela est géré.

Désactiver la synchronisation des secrets

Pour désactiver la synchronisation des secrets, exécutez la commande gcloud CLI suivante :

gcloud

Pour utiliser Secret Manager avec la ligne de commande, commencez par installer ou mettre à niveau Google Cloud CLI vers la version 378.0.0 ou une version ultérieure. Sur Compute Engine ou GKE, vous devez vous authentifier avec le champ d'application cloud-platform.

gcloud beta container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-secret-sync

Remplacez les éléments suivants :

• CLUSTER_NAME : nom de votre cluster GKE
• CONTROL_PLANE_LOCATION : région ou zone du plan de contrôle de votre cluster, par exemple us-central1 ou us-east1-a.

Cette commande arrête le contrôleur de synchronisation. Les secrets Kubernetes déjà créés ne sont pas supprimés. Vous devez supprimer manuellement les secrets Kubernetes synchronisés dont vous n'avez plus besoin.

Supprimer les secrets synchronisés

Pour supprimer un secret Kubernetes synchronisé, supprimez la ressource SecretSync à l'aide de la commande suivante :

    kubectl delete secretsync KUBERNETES_SECRET_NAME --namespace NAMESPACE

Remplacez les éléments suivants :

• KUBERNETES_SECRET_NAME : nom du secret Kubernetes
• NAMESPACE : espace de noms Kubernetes dans lequel le secret existe

Migrer depuis le pilote CSI Secrets Store existant

Si vous migrez depuis votre installation existante du pilote CSI Secrets Store, procédez comme suit :

1. Remplacez la valeur gcp du champ provider dans votre SecretProviderClass par gke. L'exemple suivant montre comment mettre à jour le champ provider :

   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: app-secrets-gke
   spec:
     provider: gke
     parameters:
       secrets: |
         -   resourceName: "projects/87654321/secrets/api-key-secret/versions/2"
             path: "good1.txt"
   

2. Créez une ressource SecretSync. Utilisez l'exemple de configuration suivant :

   apiVersion: secret-sync.gke.io/v1
   kind: SecretSync
   metadata:
     name: my-kube-secret
     namespace: NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     secretProviderClassName: my-app-secrets
     secretObject:
       type: Opaque # Or other Kubernetes Secret types
       data:
         -   sourcePath: "my-secret.txt"
             targetKey: "USERNAME"
         -   sourcePath: "another-secret.txt"
             targetKey: "PASSWORD"
   

Points à noter concernant la sécurité

Secret Manager propose des fonctionnalités de sécurité telles que le contrôle des accès avec IAM, les clés de chiffrement gérées par le client (CMEK) et les journaux d'audit. Les secrets sont chiffrés au repos et en transit dans Secret Manager. Lorsque vous synchronisez des secrets avec des secrets Kubernetes, leur sécurité au sein du cluster dépend de la configuration de votre cluster GKE. Réfléchissez aux éléments suivants :

• Stockage : les secrets Kubernetes sont stockés dans etcd, qui est le principal magasin de données de GKE. Par défaut, GKE chiffre les données au repos. Pour renforcer la sécurité, chiffrez les secrets Kubernetes au niveau de la couche d'application à l'aide d'une clé que vous gérez dans Cloud Key Management Service(Cloud KMS). Le chiffrement des secrets fournit une couche de sécurité supplémentaire pour les charges de travail sensibles.

• Contrôle des accès : GKE accepte plusieurs options de gestion de l'accès aux ressources dans les projets et leurs clusters à l'aide du contrôle des accès basé sur les rôles (RBAC). Des autorisations RBAC trop larges peuvent exposer des secrets à des charges de travail ou des utilisateurs non prévus. Accordez l'accès en suivant le principe du moindre privilège et vérifiez régulièrement l'accès à Secret Manager et aux secrets Kubernetes.

• Variables d'environnement : pour améliorer la sécurité, installez les secrets Kubernetes en tant que volumes au lieu de les utiliser comme variables d'environnement. Cela réduit le risque de journalisation accidentelle ou d'exposition à d'autres processus.

Étapes suivantes

• Explorez les secrets Kubernetes.
• Comprendre Workload Identity