Utilizzare External Secrets Operator

Questa pagina descrive come utilizzare External Secrets Operator (ESO) per sincronizzare i secret da Secret Manager ai tuoi cluster Google Distributed Cloud connessi.

External Secrets Operator è un operatore Kubernetes open source che integra sistemi di gestione dei secret esterni. L'operatore legge le informazioni dalle API esterne e inserisce automaticamente i valori in un secret Kubernetes.

Prerequisiti

Prima di poter utilizzare External Secrets Operator, devi:

  • Crea un cluster Distributed Cloud connesso funzionale.
  • Verifica che le seguenti API siano abilitate nel tuo progetto Google Cloud . Per informazioni sull'abilitazione delle API, consulta Abilitazione dei servizi:
    • secretmanager.googleapis.com
    • iamcredentials.googleapis.com

  • Assicurati di aver installato i seguenti strumenti a riga di comando:

    • L'ultima versione di Google Cloud CLI, che include gcloud, lo strumento a riga di comando per interagire con Google Cloud.
    • kubectl

    Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati automaticamente.

  • Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

  • Abilita la federazione delle identità per i workload sul cluster. Il pool di identità del workload è disponibile automaticamente e segue il formato PROJECT_ID.svc.id.goog.

  • Installa l'operatore External Secrets sul tuo cluster. Per le istruzioni di installazione, consulta la documentazione di External Secrets Operator. Ti consigliamo di installare l'operatore in uno spazio dei nomi dedicato, ad esempio external-secrets. Non installarlo in spazi dei nomi gestiti dal sistema, ad esempio kube-system o gke-system.

I cluster connessi a Distributed Cloud vengono registrati automaticamente in un parco risorse nel progetto in cui vengono creati.

Autenticazione

External Secrets Operator richiede l'autenticazione per accedere a Secret Manager. Distributed Cloud connesso utilizza la federazione delle identità per i workload del parco risorse per consentire ai workload di autenticarsi alle APIGoogle Cloud .

Per configurare l'autenticazione per External Secrets Operator:

  1. Configura la relazione di attendibilità tra il cluster e Google Cloud seguendo le istruzioni riportate in Autenticazione del cluster Workload Identity.

  2. Concedi il ruolo Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) per il secret al service account Kubernetes utilizzato da 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

    Sostituisci i seguenti valori:

    • SECRET_NAME: il nome del secret in Secret Manager
    • PROJECT_ID: il tuo Google Cloud ID progetto
    • PROJECT_NUMBER: il tuo numero di progetto Google Cloud numerico
    • OPERATOR_NAMESPACE: lo spazio dei nomi in cui hai installato l'operatore
    • KUBERNETES_SERVICEACCOUNT: il nome di Kubernetes ServiceAccount utilizzato dall'operatore

  3. Configura il pod dell'operatore External Secrets in modo che utilizzi la federazione delle identità per i workload e fornisci il file di configurazione delle credenziali al pod dell'operatore seguendo le istruzioni riportate in Configura il workload.

Crea risorse ESO per sincronizzare i secret

Dopo aver configurato l'autenticazione, puoi creare risorse External Secrets Operator per sincronizzare i secret.

Crea un SecretStore

Un SecretStore specifica come accedere al sistema di gestione dei secret esterno. Puoi creare risorse SecretStore nello stesso spazio dei nomi di External Secrets Operator o negli spazi dei nomi delle applicazioni. Per saperne di più, consulta SecretStore nella documentazione di Kubernetes.

  1. Crea un file denominato secret-store.yaml con i seguenti contenuti:

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

    Sostituisci i seguenti valori:

    • NAMESPACE: lo spazio dei nomi in cui vuoi creare SecretStore
    • PROJECT_ID: l'ID del tuo progetto Google Cloud in cui sono archiviati i secret

  2. Usa il comando kubectl apply per applicare il manifest:

    kubectl apply -f secret-store.yaml

Crea un ClusterSecretStore

Un ClusterSecretStore è una risorsa con ambito cluster che le risorse ExternalSecret possono utilizzare in qualsiasi spazio dei nomi. Per saperne di più, consulta ClusterSecretStore nella documentazione di Kubernetes.

  1. Crea un file denominato cluster-secret-store.yaml con i seguenti contenuti:

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

    Sostituisci PROJECT_ID con l'ID progetto Google Cloud in cui sono archiviati i secret.

  2. Applica il manifest:

    kubectl apply -f cluster-secret-store.yaml

Crea un ExternalSecret

Un ExternalSecret dichiara quali dati recuperare e dove archiviarli nel cluster. Crea risorse ExternalSecret nello spazio dei nomi in cui i pod dell'applicazione utilizzano il secret Kubernetes risultante. Per saperne di più, consulta ExternalSecret nella documentazione di Kubernetes.

  1. Crea un file denominato external-secret.yaml con i seguenti contenuti:

    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

    Sostituisci i seguenti valori:

    • EXTERNAL_SECRET: il nome della risorsa ExternalSecret.
    • NAMESPACE: lo spazio dei nomi in cui hai creato SecretStore.
    • K8S_SECRET_NAME: il nome del secret Kubernetes da creare con ESO.
    • K8S_SECRET_KEY: la chiave nei dati del secret Kubernetes.
    • SECRET_NAME: il nome del secret in Google Cloud Secret Manager.

    Se utilizzi un ClusterSecretStore, imposta kind: ClusterSecretStore e aggiorna name in secretStoreRef.

  2. Applica il manifest:

    kubectl apply -f external-secret.yaml

Sincronizzare più chiavi da un secret JSON

Se il secret in Secret Manager contiene una stringa JSON, puoi estrarre tutte le chiavi come singole voci nel secret Kubernetes.

  1. Crea un file denominato external-secret-json.yaml con i seguenti contenuti:

    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. Applica il manifest:

    kubectl apply -f external-secret-json.yaml

Ogni coppia chiave-valore nel secret JSON viene mappata a una coppia chiave-valore nel secret Kubernetes risultante.

Risoluzione dei problemi

Se i tuoi segreti non vengono sincronizzati, segui questi passaggi per risolvere il problema:

  1. Utilizza il comando kubectl get per controllare lo stato della risorsa ExternalSecret:

    kubectl get externalsecret EXTERNAL_SECRET -n NAMESPACE -o yaml

    Esamina la sezione status per verificare la presenza di messaggi di errore o condizioni non soddisfatte.

  2. Usa il comando kubectl logs per controllare i log del pod controller dell'operatore External Secrets:

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

  3. Verifica che l'account di servizio Kubernetes utilizzato dall'operatore disponga del ruolo Accessore secret Secret Manager (roles/secretmanager.secretAccessor) e che la federazione delle identità per i carichi di lavoro sia configurata correttamente nel pod dell'operatore. Per ulteriori informazioni, consulta federazione delle identità per i workload sul cluster.

Passaggi successivi