Accedi ai secret archiviati all'esterno dei cluster GKE utilizzando le librerie client

Autopilot Standard

---

Questo tutorial mostra come archiviare i dati sensibili utilizzati dai cluster Google Kubernetes Engine (GKE) in Secret Manager e accedere in modo più sicuro ai dati dei pod utilizzando la federazione di Workload Identity per GKE e le librerie client di Google Cloud. Questo tutorial è destinato agli amministratori della sicurezza che vogliono spostare dati sensibili fuori dallo spazio di archiviazione nel cluster.

L'archiviazione dei dati sensibili all'esterno dello spazio di archiviazione del cluster riduce il rischio di accesso non autorizzato ai dati in caso di attacco. L'utilizzo della federazione di Workload Identity per GKE per accedere ai dati ti consente di evitare i rischi associati alla gestione di chiavi degli account di servizio di lunga durata e di controllare l'accesso ai tuoi secret mediante Identity and Access Management (IAM) anziché le regole RBAC nel cluster. Puoi utilizzare qualsiasi provider di archivi secret esterno, ad esempio Secret Manager o hashiCorp Vault.

Questo tutorial utilizza un cluster GKE Autopilot. Per eseguire la procedura utilizzando GKE Standard, devi abilitare manualmente la federazione di Workload Identity per GKE.

Puoi utilizzare la federazione di Workload Identity per GKE per accedere a qualsiasi API Google Cloud dai carichi di lavoro GKE senza dover utilizzare approcci meno sicuri come i file delle chiavi degli account di servizio statici. Questo tutorial utilizza Secret Manager come esempio, ma puoi seguire gli stessi passaggi per accedere ad altre API Google Cloud. Per saperne di più, consulta Federazione delle identità per i carichi di lavoro per GKE.

Obiettivi

• Crea un secret in Google Cloud Secret Manager.
• Crea e configura gli account di servizio IAM per accedere al secret.
• Creare un cluster GKE Autopilot, spazi dei nomi Kubernetes e account di servizio Kubernetes.
• Utilizza applicazioni di test per verificare l'accesso agli account di servizio.
• Esegui un'app di esempio che acceda al secret utilizzando l'API Secret Manager.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• GKE Autopilot
• Secret Manager

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

1. Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
2. Installa Google Cloud CLI.

3. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

4. Crea o seleziona un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   • Crea un progetto Google Cloud:

     gcloud projects create PROJECT_ID

     Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.

   • Seleziona il progetto Google Cloud che hai creato:

     gcloud config set project PROJECT_ID

     Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

5. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

6. Abilita le API Kubernetes Engine and Secret Manager.

   gcloud services enable container.googleapis.com secretmanager.googleapis.com

7. Installa Google Cloud CLI.

8. Per initialize gcloud CLI, esegui questo comando:

   gcloud init

9. Crea o seleziona un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse create in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

   • Crea un progetto Google Cloud:

     gcloud projects create PROJECT_ID

     Sostituisci PROJECT_ID con un nome per il progetto Google Cloud che stai creando.

   • Seleziona il progetto Google Cloud che hai creato:

     gcloud config set project PROJECT_ID

     Sostituisci PROJECT_ID con il nome del tuo progetto Google Cloud.

10. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

11. Abilita le API Kubernetes Engine and Secret Manager.

    gcloud services enable container.googleapis.com secretmanager.googleapis.com

12. Concedi i ruoli al tuo Account Google. Esegui questo comando una volta per ciascuno dei seguenti ruoli IAM: roles/secretmanager.admin, roles/container.clusterAdmin, roles/iam.serviceAccountAdmin

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS" --role=ROLE

    • Sostituisci PROJECT_ID con l'ID progetto.
    • Sostituisci EMAIL_ADDRESS con il tuo indirizzo email.
    • Sostituisci ROLE con ogni singolo ruolo.

prepara l'ambiente

Clona il repository GitHub che contiene i file di esempio per questo tutorial:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd ~/kubernetes-engine-samples/security/wi-secrets

Crea un secret in Secret Manager

1. L'esempio seguente mostra i dati che utilizzerai per creare un secret:

   key=my-api-key

2. Crea un secret per archiviare i dati di esempio:

   gcloud secrets create bq-readonly-key \
       --data-file=manifests/bq-readonly-key \
       --ttl=3600s
   

   Questo comando esegue le seguenti operazioni:

   • Crea un nuovo secret di Secret Manager con la chiave di esempio nella regione di Google Cloud us-central1.
   • Imposta il secret in modo che scada un'ora dopo l'esecuzione del comando.

Configura gli account di servizio IAM

1. Crea due nuovi account di servizio IAM per l'accesso di sola lettura e l'accesso in lettura/scrittura:

   gcloud iam service-accounts create readonly-secrets --display-name="Read secrets"
   gcloud iam service-accounts create readwrite-secrets --display-name="Read write secrets"
   

2. Concedi all'account di servizio IAM readonly-secrets l'accesso di sola lettura al secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=serviceAccount:readonly-secrets@PROJECT_ID.iam.gserviceaccount.com \
       --role='roles/secretmanager.secretAccessor'
   

3. Concedi agli account di servizio IAM readwrite-secrets l'accesso in lettura e scrittura al secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=serviceAccount:readwrite-secrets@PROJECT_ID.iam.gserviceaccount.com \
       --role='roles/secretmanager.secretAccessor'
   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=serviceAccount:readwrite-secrets@PROJECT_ID.iam.gserviceaccount.com \
       --role='roles/secretmanager.secretVersionAdder'
   

crea il cluster e le risorse Kubernetes

Creare un cluster GKE, spazi dei nomi Kubernetes e account di servizio Kubernetes. Creerai due spazi dei nomi, uno per l'accesso di sola lettura e uno per l'accesso in lettura e scrittura al secret. In ogni spazio dei nomi creerai anche un account di servizio Kubernetes da utilizzare con la federazione di Workload Identity per GKE.

1. Crea un cluster GKE Autopilot:

   gcloud container clusters create-auto secret-cluster \
       --region=us-central1
   

   Il deployment del cluster potrebbe richiedere circa cinque minuti. Nei cluster Autopilot è sempre abilitata la federazione di Workload Identity per GKE. Se vuoi utilizzare invece un cluster GKE Standard, devi abilitare manualmente la federazione di Workload Identity per GKE prima di continuare.

2. Crea uno spazio dei nomi readonly-ns e uno admin-ns:

   kubectl create namespace readonly-ns
   kubectl create namespace admin-ns
   

3. Crea un account di servizio Kubernetes readonly-sa e un admin-sa account di servizio Kubernetes:

   kubectl create serviceaccount readonly-sa --namespace=readonly-ns
   kubectl create serviceaccount admin-sa --namespace=admin-ns
   

4. Associa gli account di servizio IAM agli account di servizio Kubernetes:

   gcloud iam service-accounts add-iam-policy-binding readonly-secrets@PROJECT_ID.iam.gserviceaccount.com \
       --member=serviceAccount:PROJECT_ID.svc.id.goog[readonly-ns/readonly-sa] \
       --role='roles/iam.workloadIdentityUser'
   gcloud iam service-accounts add-iam-policy-binding readwrite-secrets@PROJECT_ID.iam.gserviceaccount.com \
       --member=serviceAccount:PROJECT_ID.svc.id.goog[admin-ns/admin-sa] \
       --role='roles/iam.workloadIdentityUser'
   

5. Annota gli account di servizio Kubernetes con i nomi degli account di servizio IAM associati:

   kubectl annotate serviceaccount readonly-sa \
       --namespace=readonly-ns \
       iam.gke.io/gcp-service-account=readonly-secrets@PROJECT_ID.iam.gserviceaccount.com
   kubectl annotate serviceaccount admin-sa \
       --namespace=admin-ns \
       iam.gke.io/gcp-service-account=readwrite-secrets@PROJECT_ID.iam.gserviceaccount.com
   

Ora hai un cluster configurato per accedere al secret dai pod utilizzando la federazione delle identità di Workload per GKE.

Verifica l'accesso ai secret

Esegui il deployment di pod di test in ogni spazio dei nomi per verificare l'accesso di sola lettura e scrittura.

1. Esamina il manifest del pod di sola lettura:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-test
     namespace: readonly-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: readonly-sa

   Questo pod utilizza l'account di servizio readonly-sa nello spazio dei nomi readonly-ns.

2. Esamina il manifest del pod di lettura-scrittura:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: admin-test
     namespace: admin-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: admin-sa

   Questo pod utilizza l'account di servizio admin-sa nello spazio dei nomi admin-ns.

3. Esegui il deployment dei pod di test:

   kubectl apply -f manifests/admin-pod.yaml
   kubectl apply -f manifests/readonly-pod.yaml
   

   L'esecuzione dei pod potrebbe richiedere alcuni minuti. Per monitorare l'avanzamento, esegui questo comando:

   watch kubectl get pods -n readonly-ns
   

   Quando lo stato del pod diventa RUNNING, premi Ctrl+C per tornare alla riga di comando.

Testa l'accesso di sola lettura

1. Apri una shell nel pod readonly-test:

   kubectl exec -it readonly-test --namespace=readonly-ns -- /bin/bash
   

2. Prova a leggere il segreto:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   L'output è key=my-api-key.

3. Prova a scrivere nuovi dati nel secret:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   L'output è simile al seguente:

   ERROR: (gcloud.secrets.versions.add) PERMISSION_DENIED: Permission 'secretmanager.versions.add' denied for resource 'projects/PROJECT_ID/secrets/bq-readonly-key' (or it may not exist).
   

   Il pod che utilizza l'account di servizio di sola lettura può solo leggere il secret e scrivere nuovi dati.

4. Esci dal pod:

   exit
   

Testa l'accesso in lettura/scrittura

1. Apri una shell nel pod admin-test:

   kubectl exec -it admin-test --namespace=admin-ns -- /bin/bash
   

2. Prova a leggere il segreto:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   L'output è key=my-api-key.

3. Prova a scrivere nuovi dati nel secret:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   L'output è simile al seguente:

   Created version [2] of the secret [bq-readonly-key].
   

4. Leggi la nuova versione del secret:

   gcloud secrets versions access 2 --secret=bq-readonly-key
   

   L'output è my-second-api-key.

5. Esci dal pod:

   exit
   

I pod ricevono solo il livello di accesso che hai concesso all'account di servizio IAM associato all'account di servizio Kubernetes utilizzato nel manifest del pod. Tutti i pod che utilizzano l'account Kubernetes admin-sa nello spazio dei nomi admin-ns possono scrivere nuove versioni del secret, ma tutti i pod nello spazio dei nomi readonly-ns che utilizzano l'account di servizio Kubernetes readonly-sa possono solo leggere il secret.

Accedi ai secret dal tuo codice

In questa sezione:

1. Esegui il deployment di un'applicazione di esempio che legge il tuo secret in Secret Manager utilizzando le librerie client.

2. Verifica che l'applicazione possa accedere al secret.

Devi accedere ai secret di Secret Manager dal codice dell'applicazione quando possibile, utilizzando l'API Secret Manager.

1. Esamina il codice sorgente dell'applicazione di esempio:

   // Copyright 2022 Google LLC
   //
   // Licensed under the Apache License, Version 2.0 (the "License");
   // you may not use this file except in compliance with the License.
   // You may obtain a copy of the License at
   //
   //     http://www.apache.org/licenses/LICENSE-2.0
   //
   // Unless required by applicable law or agreed to in writing, software
   // distributed under the License is distributed on an "AS IS" BASIS,
   // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   // See the License for the specific language governing permissions and
   // limitations under the License.
   
   package main
   
   import (
   	"context"
   	"fmt"
   	"log"
   	"os"
   
   	secretmanager "cloud.google.com/go/secretmanager/apiv1"
   	secretmanagerpb "google.golang.org/genproto/googleapis/cloud/secretmanager/v1"
   )
   
   func main() {
   
           // Get environment variables from Pod spec.
           projectID := os.Getenv("PROJECT_ID")
           secretId := os.Getenv("SECRET_ID")
           secretVersion := os.Getenv("SECRET_VERSION")
   
           // Create the Secret Manager client.
           ctx := context.Background()
           client, err := secretmanager.NewClient(ctx)
           if err != nil {
                   log.Fatalf("failed to setup client: %v", err)
           }
           defer client.Close()
   
           // Create the request to access the secret.
           accessSecretReq := &secretmanagerpb.AccessSecretVersionRequest{
                   Name: fmt.Sprintf("projects/%s/secrets/%s/versions/%s", projectID, secretId, secretVersion),
           }
   
           secret, err := client.AccessSecretVersion(ctx, accessSecretReq)
           if err != nil {
                   log.Fatalf("failed to access secret: %v", err)
           }
   
           // Print the secret payload.
           //
           // WARNING: Do not print the secret in a production environment - this
           // snippet is showing how to access the secret material.
           log.Printf("Welcome to the key store, here's your key:\nKey: %s", secret.Payload.Data)
   }
   

   Questa applicazione chiama l'API Secret Manager per provare a leggere il secret.

2. Esamina il manifest del pod dell'applicazione di esempio:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-secret-test
     namespace: readonly-ns
   spec:
     containers:
     - image: us-docker.pkg.dev/google-samples/containers/gke/wi-secret-store:latest
       name: secret-app
       env:
         - name: PROJECT_ID
           value: "YOUR_PROJECT_ID"
         - name: SECRET_ID
           value: "bq-readonly-key"
         - name: SECRET_VERSION
           value: "latest"
       resources:
         requests:
           cpu: "125m"
           memory: "64Mi"
     serviceAccountName: readonly-sa

   Il file manifest svolge le seguenti operazioni:

   • Crea un pod nello spazio dei nomi readonly-ns che utilizza l'account di servizio readonly-sa.
   • Estrae un'applicazione di esempio da un registro di immagini Google. Questa applicazione chiama l'API Secret Manager utilizzando le librerie client di Google Cloud. Puoi visualizzare il codice dell'applicazione in /main.go nel repository.
   • Imposta le variabili di ambiente da utilizzare per l'applicazione di esempio.

3. Sostituisci le variabili di ambiente nell'applicazione di esempio:

   sed -i "s/YOUR_PROJECT_ID/PROJECT_ID/g" "manifests/secret-app.yaml"
   

4. Distribuisci l'applicazione di esempio:

   kubectl apply -f manifests/secret-app.yaml
   

   Potrebbero essere necessari alcuni minuti prima che il pod inizi a funzionare. Se il pod ha bisogno di un nuovo nodo nel cluster, potresti notare eventi di tipo CrashLoopBackOff mentre GKE esegue il provisioning del nodo. Gli arresti anomali si interrompono quando il nodo esegue correttamente il provisioning.

5. Verifica l'accesso al secret:

   kubectl logs readonly-secret-test -n readonly-ns
   

   L'output è my-second-api-key. Se l'output è vuoto, il pod potrebbe non essere ancora in esecuzione. Attendi qualche minuto e riprova.

Approcci alternativi

Se devi montare i dati sensibili nei pod, utilizza il componente aggiuntivo Secret Manager per GKE (anteprima). Questo componente aggiuntivo esegue il deployment e gestisce il provider Google Cloud Secret Manager per il driver CSI di Kubernetes Secret Store nei tuoi cluster GKE. Per le istruzioni, consulta Utilizzare il componente aggiuntivo Secret Manager con GKE.

Fornire i secret come volumi montati presenta i seguenti rischi:

1. I volumi montati sono soggetti ad attacchi di attraversamento directory.
2. Le variabili di ambiente possono essere compromesse a causa di configurazioni errate come l'apertura di un endpoint di debug.

Quando possibile, ti consigliamo di accedere ai secret in modo programmatico tramite l'API Secret Manager. Per le istruzioni, utilizza l'applicazione di esempio in questo tutorial o consulta Librerie client di Secret Manager.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina singole risorse

1. Elimina il cluster:

   gcloud container clusters delete secret-cluster \
       --region=us-central1
   

2. Elimina gli account di servizio IAM:

   gcloud iam service-accounts delete readonly-secrets@PROJECT_ID.iam.gserviceaccount.com
   gcloud iam service-accounts delete readwrite-secrets@PROJECT_ID.iam.gserviceaccount.com
   

3. (Facoltativo) Elimina il secret in Secret Manager:

   gcloud secrets delete bq-readonly-key
   

   Se non esegui questo passaggio, il secret scade automaticamente perché hai impostato il flag --ttl durante la creazione.

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Elimina un progetto Google Cloud:

gcloud projects delete PROJECT_ID

Passaggi successivi

• Scopri di più su come funziona la federazione delle identità per i carichi di lavoro per GKE.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.