Sincronizzare i secret con i secret di Kubernetes

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questo documento descrive come sincronizzare i secret archiviati in Secret Manager con i secret Kubernetes all'interno dei tuoi cluster Google Kubernetes Engine (GKE).

Il processo di sincronizzazione consente alle applicazioni in esecuzione su GKE di accedere ai secret da Secret Manager utilizzando metodi Kubernetes standard, come variabili di ambiente o montaggi di volumi. Ciò è utile per le applicazioni già progettate per leggere i secret dall'oggetto Secret di Kubernetes, anziché dover essere aggiornate per accedere direttamente a Secret Manager.

Consiglio: la funzionalità di sincronizzazione dei secret è un'alternativa al componente aggiuntivo Secret Manager, che monta i secret come file in memoria direttamente nei pod. Utilizza il componente aggiuntivo Secret Manager ogni volta che la tua applicazione lo supporta, perché è un metodo più sicuro per accedere ai secret da Secret Manager in GKE.

Prima di iniziare

Completa i seguenti prerequisiti prima di sincronizzare i secret:

• 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

• Installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update.

• Assicurati di avere un cluster GKE in esecuzione. Questa funzionalità richiede GKE versione 1.34 e successive.

• Assicurati che Workload Identity Federation for GKE sia abilitato sul tuo cluster GKE. Questo è necessario per l'autenticazione. Workload Identity Federation for GKE è abilitata per impostazione predefinita su un cluster Autopilot.

• Assicurati di disporre delle autorizzazioni Identity and Access Management necessarie per gestire i cluster GKE e Secret Manager.

Abilita la sincronizzazione dei secret su un cluster GKE

Attiva la funzionalità di sincronizzazione dei secret quando crei un nuovo cluster o aggiorni un cluster esistente. Questa funzionalità è disponibile sia sui cluster Standard che su quelli Autopilot.

Abilitare la sincronizzazione dei secret in un nuovo cluster

Per creare un nuovo cluster con la sincronizzazione dei secret, utilizza uno di questi comandi gcloud CLI:

Cluster Standard

Per utilizzare Secret Manager dalla riga di comando, devi prima installare o eseguire l'upgrade alla versione 378.0.0 o successive di Google Cloud CLI. Su Compute Engine o GKE, devi autenticarti con l'ambito cloud-platform.

Attiva la sincronizzazione dei secret senza rotazione automatica.

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

Attiva la sincronizzazione dei secret con rotazione automatica. L'intervallo predefinito è 2 minuti.

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

Attiva la sincronizzazione dei secret con un intervallo di rotazione personalizzato. L'intervallo minimo è 1 minuto.

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

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster GKE
• CONTROL_PLANE_LOCATION: la regione o la zona del piano di controllo del cluster, ad esempio us-central1 o us-east1-a
• PROJECT_ID: il tuo ID progetto Google Cloud

Cluster Autopilot

Per utilizzare Secret Manager dalla riga di comando, devi prima installare o eseguire l'upgrade alla versione 378.0.0 o successive di Google Cloud CLI. Su Compute Engine o GKE, devi autenticarti con l'ambito cloud-platform.

Attiva la sincronizzazione dei secret senza rotazione automatica.

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

Attiva la sincronizzazione dei secret con rotazione automatica. L'intervallo predefinito è 2 minuti.

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

Attiva la sincronizzazione dei secret con un intervallo di rotazione personalizzato. L'intervallo minimo è 1 minuto.

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

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster GKE
• CONTROL_PLANE_LOCATION: la regione o la zona del piano di controllo del cluster, ad esempio us-central1 o us-east1-a

Abilitare la sincronizzazione dei secret su un cluster esistente

Per aggiornare i cluster esistenti con la sincronizzazione dei secret, utilizza uno dei seguenti comandi gcloud CLI:

gcloud

Per utilizzare Secret Manager dalla riga di comando, devi prima installare o eseguire l'upgrade alla versione 378.0.0 o successive di Google Cloud CLI. Su Compute Engine o GKE, devi autenticarti con l'ambito cloud-platform.

Abilitare la sincronizzazione dei secret su un cluster esistente

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

Attivare la rotazione con un intervallo personalizzato

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

Disattivare la rotazione

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

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster GKE
• CONTROL_PLANE_LOCATION: la regione o la zona del piano di controllo del cluster, ad esempio us-central1 o us-east1-a

Configurare la sincronizzazione dei secret

Per sincronizzare i secret, completa i seguenti passaggi:

1. Crea un Kubernetes ServiceAccount utilizzando il seguente comando:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Sostituisci quanto segue:

   • KSA_NAME: il nome del tuo service account Kubernetes
   • NAMESPACE: lo spazio dei nomi Kubernetes in cui vuoi creare ServiceAccount

2. Crea un criterio di autorizzazione IAM che faccia riferimento al nuovo service account Kubernetes e concedi al service account l'autorizzazione per accedere al secret:

   gcloud

   Per utilizzare Secret Manager dalla riga di comando, devi prima installare o eseguire l'upgrade alla versione 378.0.0 o successive di Google Cloud CLI. Su Compute Engine o GKE, devi autenticarti con l'ambito 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
   

   Sostituisci quanto segue:

   • SECRET_PROJECT_ID: l'ID del progetto in cui è archiviato il secret. Può essere uguale a PROJECT_ID se il secret è archiviato nello stesso progetto del cluster GKE.
   • PROJECT_NUMBER: il tuo Google Cloud numero di progetto
   • PROJECT_ID: il tuo ID progetto Google Cloud
   • NAMESPACE: lo spazio dei nomi Kubernetes
   • KSA_NAME: il nome del tuo service account Kubernetes

3. Crea una risorsa personalizzata SecretProviderClass utilizzando un manifest YAML. La risorsa SecretProviderClass definisce i secret specifici da recuperare da Secret Manager, inclusi i relativi nomi e percorsi delle risorse. Il componente aggiuntivo Secret Manager utilizza anche la risorsa SecretProviderClass per elencare i secret da montare e il nome del file in cui montarli.

   Crea un file spc.yaml con i seguenti contenuti:

   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"
   

   Sostituisci quanto segue:

   • SECRET_PROVIDER_CLASS_NAME: il nome dell'oggetto SecretProviderClass.
   • NAMESPACE: lo spazio dei nomi Kubernetes in cui stai creando questa risorsa.
   • resourceName: l'identificatore di risorsa completo per il secret in Secret Manager. Deve includere l'ID progetto, il nome del secret e la versione nel formato: projects/SECRET_PROJECT_ID/secrets/SECRET_NAME/versions/SECRET_VERSION.
     • SECRET_PROJECT_ID: l'ID del Google Cloud progetto in cui è archiviato il secret. Può essere uguale a PROJECT_ID se il secret è archiviato nello stesso progetto del cluster GKE.
     • SECRET_NAME: il nome del secret.
     • SECRET_VERSION: la versione secret. La versione del secret deve trovarsi nella stessa regione del cluster.
   • path: il nome file locale o l'alias con cui il valore del secret verrà esposto nell'ambiente Kubernetes. È l'identificatore univoco che collega una versione specifica di Secret Manager alla rappresentazione locale utilizzata dal cluster. Quando il secret viene sincronizzato con un secret Kubernetes utilizzando la risorsa SecretSync, questo percorso viene fatto riferimento dal campo sourcePath per individuare il valore del secret per la sincronizzazione. Puoi mappare più secret (definiti da resourceName) a nomi di percorsi diversi all'interno della stessa SecretProviderClass.

4. Per applicare il manifest, esegui questo comando:

   kubectl apply -f spc.yaml
   

5. Crea una risorsa personalizzata SecretSync utilizzando un manifest YAML. Questa risorsa indica al controller di sincronizzazione di creare o aggiornare un secret Kubernetes in base ai contenuti definiti in SecretProviderClass.

   Crea un file secret-sync.yaml con i seguenti contenuti:

   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"
   

   Sostituisci quanto segue:

   • KUBERNETES_SECRET_NAME: il nome che vuoi assegnare al nuovo secret Kubernetes che verrà creato dalla risorsa SecretSync.
   • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene creata la nuova risorsa. Deve essere lo stesso spazio dei nomi di SecretProviderClass.
   • KSA_NAME: il nome del ServiceAccount Kubernetes utilizzato dal controller SecretSync per creare e aggiornare il secret Kubernetes di destinazione. Questo service account deve disporre delle autorizzazioni necessarie per accedere ai secret esterni da Secret Manager.
   • SECRET_PROVIDER_CLASS_NAME: il nome dell'oggetto SecretProviderClass creato nel passaggio precedente. La risorsa SecretSync utilizza questo valore per trovare la configurazione corretta per i secret.
   • KUBERNETES_SECRET_TYPE: il tipo di secret Kubernetes da creare, ad esempio Opaque, tls o docker-registry. Determina il modo in cui Kubernetes gestisce i dati del secret.
   • sourcePath: il nome file o l'alias locale (il valore del campo path in SecretProviderClass) che identifica i dati del secret da recuperare. Il controller SecretSync utilizza questo sourcePath per richiedere il contenuto del secret specifico e convertirlo in un nuovo secret Kubernetes.
   • targetKey: la chiave che verrà utilizzata nella sezione data del nuovo Secret Kubernetes in fase di creazione. Definisce il nome e la modalità di archiviazione dei contenuti del secret recuperati utilizzando sourcePath nell'oggetto Kubernetes Secret finale. L'utilizzo di più voci nell'array di dati ti consente di definire più coppie chiave-valore all'interno dello stesso secret di destinazione.

6. Per applicare il manifest, esegui questo comando:

   kubectl apply -f secret-sync.yaml
   

   Il controller di sincronizzazione crea un secret Kubernetes nello spazio dei nomi specificato. Questo secret contiene i dati mappati da Secret Manager.

7. Verifica che il secret di Kubernetes sia stato creato:

   kubectl get secret KUBERNETES_SECRET_NAME -n NAMESPACE -o yaml
   

   Sostituisci quanto segue:

   • KUBERNETES_SECRET_NAME: il nome del nuovo secret Kubernetes
   • NAMESPACE: lo spazio dei nomi Kubernetes in cui viene creato il nuovo secret

8. Per risolvere un problema di sincronizzazione, utilizza il seguente comando:

   kubectl describe secretSync KUBERNETES_SECRET_NAME -n NAMESPACE
   

   Sostituisci quanto segue:

   • KUBERNETES_SECRET_NAME: il nome del nuovo secret Kubernetes
   • NAMESPACE: lo spazio dei nomi Kubernetes in cui deve esistere il nuovo secret

Gestire la rotazione dei secret

Se attivi il flag --enable-secret-sync-rotation, sul tuo cluster, il controller di sincronizzazione controlla periodicamente Secret Manager per le nuove versioni dei secret specificati nella risorsa SecretProviderClass. Il flag --secret-sync-rotation-interval determina la frequenza con cui il controller controlla la disponibilità di aggiornamenti.

Se il controller rileva una nuova versione del secret in Secret Manager, aggiorna il secret Kubernetes corrispondente. Il controller confronta gli hash dei contenuti dei secret per aggiornarli solo quando si verificano modifiche.

Le applicazioni che utilizzano questi secret devono rilevare e ricaricare i valori dei secret aggiornati dal secret Kubernetes. Il design dell'applicazione determina come viene gestito.

Disattivare la sincronizzazione dei secret

Per disattivare la sincronizzazione dei secret, esegui questo comando gcloud CLI:

gcloud

Per utilizzare Secret Manager dalla riga di comando, devi prima installare o eseguire l'upgrade alla versione 378.0.0 o successive di Google Cloud CLI. Su Compute Engine o GKE, devi autenticarti con l'ambito cloud-platform.

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

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del tuo cluster GKE
• CONTROL_PLANE_LOCATION: la regione o la zona del piano di controllo del cluster, ad esempio us-central1 o us-east1-a

Questo comando arresta il controller di sincronizzazione. Non elimina i secret Kubernetes già creati. Devi eliminare manualmente tutti i segreti Kubernetes sincronizzati se non ti servono più.

Elimina i secret sincronizzati

Per eliminare un secret di Kubernetes sincronizzato, elimina la risorsa SecretSync utilizzando questo comando:

    kubectl delete secretsync KUBERNETES_SECRET_NAME --namespace NAMESPACE

Sostituisci quanto segue:

• KUBERNETES_SECRET_NAME: il nome del secret Kubernetes
• NAMESPACE: lo spazio dei nomi Kubernetes in cui esiste il secret

Eseguire la migrazione dal driver CSI Secrets Store esistente

Se esegui la migrazione dall'installazione esistente del driver CSI Secrets Store, segui questi passaggi:

1. Aggiorna il campo provider in SecretProviderClass da gcp a gke. Il seguente esempio mostra come aggiornare il campo 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. Crea una risorsa SecretSync. Utilizza la seguente configurazione di esempio:

   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"
   

Considerazioni sulla sicurezza

Secret Manager offre funzionalità di sicurezza come controllo dell'accesso con IAM, chiavi di crittografia gestite dal cliente (CMEK) e audit logging. I secret sono criptati at-rest e in transito all'interno di Secret Manager. Quando sincronizzi i secret con i secret di Kubernetes, la loro sicurezza all'interno del cluster dipende dalla configurazione del cluster GKE. Considera quanto segue:

• Archiviazione: i secret di Kubernetes sono archiviati in etcd, che è il datastore principale di GKE. Per impostazione predefinita, GKE cripta i dati at-rest. Per una maggiore sicurezza, cripta i secret di Kubernetes a livello di applicazione utilizzando una chiave che gestisci in Cloud Key Management Service(Cloud KMS). La crittografia dei secret fornisce un ulteriore livello di sicurezza per i carichi di lavoro sensibili.

• Controllo dell'accesso: GKE supporta più opzioni per gestire l'accesso alle risorse all'interno dei progetti e dei relativi cluster utilizzandocontrollo dell'accessosi basato sui ruoli (RBAC). Autorizzazioni RBAC eccessivamente ampie possono esporre segreti a carichi di lavoro o utenti non previsti. Concedi l'accesso seguendo il principio del privilegio minimo e controlla regolarmente l'accesso sia a Secret Manager sia ai secret Kubernetes.

• Variabili di ambiente: per migliorare la sicurezza, monta i secret di Kubernetes come volumi anziché utilizzarli come variabili di ambiente. In questo modo si riduce il rischio di registrazione accidentale o esposizione ad altri processi.

Passaggi successivi

• Esplora i secret Kubernetes.
• Informazioni su Workload Identity.