Utiliser External Secrets Operator

Cette page explique comment utiliser l'opérateur External Secrets (ESO) pour synchroniser les secrets de Secret Manager avec vos clusters Google Distributed Cloud (connecté).

External Secrets Operator est un opérateur Kubernetes Open Source qui intègre des systèmes externes de gestion des secrets. L'opérateur lit les informations des API externes et injecte automatiquement les valeurs dans un secret Kubernetes.

Prérequis

Avant de pouvoir utiliser External Secrets Operator, vous devez effectuer les opérations suivantes :

  • Créez un cluster connecté Distributed Cloud fonctionnel.
  • Vérifiez que les API suivantes sont activées dans votre projet Google Cloud . Pour savoir comment activer les API, consultez Activer des services :
    • secretmanager.googleapis.com
    • iamcredentials.googleapis.com

  • Assurez-vous que les outils de ligne de commande suivants sont installés :

    • La dernière version de la Google Cloud CLI, qui inclut gcloud, l'outil de ligne de commande permettant d'interagir avec Google Cloud.
    • kubectl

    Si vous utilisez Cloud Shell comme environnement shell pour interagir avecGoogle Cloud, ces outils sont installés pour vous.

  • Assurez-vous d'avoir initialisé gcloud CLI à utiliser avec votre projet.

  • Activez la fédération d'identité de charge de travail sur le cluster. Le pool d'identités de charge de travail est automatiquement disponible et suit le format PROJECT_ID.svc.id.goog.

  • Installez l'opérateur External Secrets sur votre cluster. Pour obtenir des instructions d'installation, consultez la documentation de l'opérateur External Secrets. Nous vous recommandons d'installer l'opérateur dans un espace de noms dédié, tel que external-secrets. Ne l'installez pas dans des espaces de noms gérés par le système, tels que kube-system ou gke-system.

Les clusters connectés Distributed Cloud sont automatiquement enregistrés dans un parc du projet dans lequel ils sont créés.

Authentification

External Secrets Operator nécessite une authentification pour accéder à Secret Manager. Distributed Cloud Connected utilise la fédération d'identité de charge de travail pour parc afin de permettre aux charges de travail de s'authentifier auprès des APIGoogle Cloud .

Pour configurer l'authentification pour External Secrets Operator :

  1. Configurez la relation d'approbation entre votre cluster et Google Cloud en suivant les instructions de la section Authentification du cluster Workload Identity.

  2. Attribuez le rôle Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) sur le secret au compte de service Kubernetes utilisé par External Secrets Operator :

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

    Remplacez les valeurs suivantes :

    • SECRET_NAME : nom du secret dans Secret Manager
    • PROJECT_ID : ID de votre projet Google Cloud
    • PROJECT_NUMBER : numéro numérique de votre projet Google Cloud
    • OPERATOR_NAMESPACE : espace de noms dans lequel vous avez installé l'opérateur
    • KUBERNETES_SERVICEACCOUNT : nom du compte de service Kubernetes utilisé par l'opérateur

  3. Configurez le pod External Secrets Operator pour qu'il utilise la fédération d'identité de charge de travail et fournissez le fichier de configuration des identifiants au pod de l'opérateur en suivant les instructions de la section Configurer la charge de travail.

Créer des ressources ESO pour synchroniser les secrets

Une fois l'authentification configurée, vous pouvez créer des ressources External Secrets Operator pour synchroniser les secrets.

Créer un objet SecretStore

Un SecretStore spécifie comment accéder au système externe de gestion des secrets. Vous pouvez créer des ressources SecretStore dans le même espace de noms que l'opérateur External Secrets ou dans les espaces de noms des applications. Pour en savoir plus, consultez SecretStore dans la documentation Kubernetes.

  1. Créez un fichier nommé secret-store.yaml avec le contenu suivant :

    apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: gcp-store
  namespace: NAMESPACE
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Remplacez les valeurs suivantes :

    • NAMESPACE : espace de noms dans lequel vous souhaitez créer SecretStore
    • PROJECT_ID : ID du projet Google Cloud dans lequel les secrets sont stockés

  2. Utilisez la commande kubectl apply pour appliquer le fichier manifeste :

    kubectl apply -f secret-store.yaml

Créer un objet ClusterSecretStore

Un ClusterSecretStore est une ressource à l'échelle du cluster que les ressources ExternalSecret peuvent utiliser dans n'importe quel espace de noms. Pour en savoir plus, consultez ClusterSecretStore dans la documentation Kubernetes.

  1. Créez un fichier nommé cluster-secret-store.yaml avec le contenu suivant :

    apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
metadata:
  name: gcp-cluster-store
spec:
  provider:
    gcpsm:
      projectID: PROJECT_ID

    Remplacez PROJECT_ID par l'ID du projet Google Cloud dans lequel les secrets sont stockés.

  2. Appliquez le fichier manifeste :

    kubectl apply -f cluster-secret-store.yaml

Créer un ExternalSecret

Un ExternalSecret déclare les données à extraire et l'emplacement où les stocker dans le cluster. Créez des ressources ExternalSecret dans l'espace de noms où les pods d'application consomment le secret Kubernetes résultant. Pour en savoir plus, consultez ExternalSecret dans la documentation Kubernetes.

  1. Créez un fichier nommé external-secret.yaml avec le contenu suivant :

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  data:
  - secretKey: K8S_SECRET_KEY
    remoteRef:
      key: SECRET_NAME

    Remplacez les valeurs suivantes :

    • EXTERNAL_SECRET : le nom de la ressource ExternalSecret.
    • NAMESPACE : espace de noms dans lequel vous avez créé SecretStore.
    • K8S_SECRET_NAME : nom du secret Kubernetes à créer par ESO.
    • K8S_SECRET_KEY : clé dans les données du secret Kubernetes.
    • SECRET_NAME : nom du secret dansGoogle Cloud Secret Manager.

    Si vous utilisez un ClusterSecretStore, définissez kind: ClusterSecretStore et mettez à jour le name dans secretStoreRef.

  2. Appliquez le fichier manifeste :

    kubectl apply -f external-secret.yaml

Synchroniser plusieurs clés à partir d'un secret JSON

Si votre secret dans Secret Manager contient une chaîne JSON, vous pouvez extraire toutes les clés en tant qu'entrées individuelles dans le secret Kubernetes.

  1. Créez un fichier nommé external-secret-json.yaml avec le contenu suivant :

    apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: EXTERNAL_SECRET
  namespace: NAMESPACE
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: gcp-store
  target:
    name: K8S_SECRET_NAME
    creationPolicy: Owner
  dataFrom:
  - extract:
      key: SECRET_NAME

  2. Appliquez le fichier manifeste :

    kubectl apply -f external-secret-json.yaml

Chaque paire clé/valeur du secret JSON est mappée à une paire clé/valeur du secret Kubernetes obtenu.

Dépannage

Si vos secrets ne se synchronisent pas, suivez les étapes ci-dessous pour résoudre le problème :

  1. Utilisez la commande kubectl get pour vérifier l'état de la ressource ExternalSecret :

    kubectl get externalsecret EXTERNAL_SECRET -n NAMESPACE -o yaml

    Examinez la section status pour détecter les éventuels messages d'erreur ou conditions non remplies.

  2. Utilisez la commande kubectl logs pour vérifier les journaux du pod de contrôleur External Secrets Operator :

    kubectl logs -l app.kubernetes.io/name=external-secrets -n OPERATOR_NAMESPACE

  3. Vérifiez que le compte de service Kubernetes utilisé par l'opérateur dispose du rôle Accesseur de secrets Secret Manager (roles/secretmanager.secretAccessor) et que la fédération d'identité de charge de travail est correctement configurée sur le pod de l'opérateur. Pour en savoir plus, consultez Fédération d'identité de charge de travail sur le cluster.

Étapes suivantes