Accedere agli oggetti Secret memorizzati al di fuori dei cluster GKE utilizzando le librerie client


Questo tutorial mostra come archiviare i dati sensibili utilizzati dal tuo Cluster Google Kubernetes Engine (GKE) in Secret Manager e altro ancora accedere in modo sicuro ai dati dai pod utilizzando la federazione delle identità per i carichi di lavoro per GKE librerie client di Google Cloud. Questo tutorial è rivolto agli amministratori della sicurezza che vogliono spostare i dati sensibili dall'archiviazione all'interno del cluster.

L'archiviazione dei dati sensibili al di fuori dello spazio di archiviazione del cluster riduce il rischio di accesso non autorizzato ai dati in caso di attacco. Utilizzo della federazione delle identità per i carichi di lavoro per GKE di accedere ai dati consente di evitare i rischi associati alla gestione le chiavi degli account di servizio e consente di controllare l'accesso ai secret Identity and Access Management (IAM) anziché regole RBAC nel cluster. Puoi utilizzare qualsiasi un provider di archivi segreti esterni, come Secret Manager o Volta di HashiCorp.

Questo tutorial utilizza un cluster GKE Autopilot. Per eseguire i passaggi utilizzando GKE Standard, devi abilitare manualmente la federazione delle identità per i carichi di lavoro per GKE.

Puoi utilizzare la federazione delle identità per i carichi di lavoro per GKE per accedere a qualsiasi API Google Cloud da per i carichi di lavoro GKE senza dover usare approcci meno sicuri e i file statici di chiavi degli account di servizio. Questo tutorial utilizza Secret Manager come esempio, ma puoi usare gli stessi passaggi per accedere ad altri Google Cloud su quelle di livello inferiore. Per saperne di più, consulta Workload Identity Federation for GKE.

Obiettivi

  • Crea un secret in Secret Manager di Google Cloud.
  • Crea un cluster GKE Autopilot, gli spazi dei nomi Kubernetes e gli account di servizio Kubernetes.
  • Crea criteri di autorizzazione IAM per concedere l'accesso ai tuoi account di servizio Kubernetes sul secret.
  • Utilizzare le applicazioni di test per verificare l'accesso agli account di servizio.
  • Esegui un'app di esempio che accede al secret utilizzando l'API Secret Manager.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. Install the Google Cloud CLI.
  3. To initialize the gcloud CLI, run the following command:

    gcloud init
  4. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Enable the Kubernetes Engine and Secret Manager APIs:

    gcloud services enable container.googleapis.com secretmanager.googleapis.com
  7. Install the Google Cloud CLI.
  8. To initialize the gcloud CLI, run the following command:

    gcloud init
  9. Create or select a Google Cloud project.

    • Create a Google Cloud project:

      gcloud projects create PROJECT_ID

      Replace PROJECT_ID with a name for the Google Cloud project you are creating.

    • Select the Google Cloud project that you created:

      gcloud config set project PROJECT_ID

      Replace PROJECT_ID with your Google Cloud project name.

  10. Make sure that billing is enabled for your Google Cloud project.

  11. Enable the Kubernetes Engine and Secret Manager APIs:

    gcloud services enable container.googleapis.com secretmanager.googleapis.com
  12. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/secretmanager.admin, roles/container.clusterAdmin

    gcloud projects add-iam-policy-binding PROJECT_ID --member="USER_IDENTIFIER" --role=ROLE
    • Replace PROJECT_ID with your project ID.
    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

    • Replace ROLE with each individual role.

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

Creare un secret in Secret Manager

  1. Il seguente esempio mostra i dati che utilizzerai per creare un segreto:

    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 Secret Manager con la chiave di esempio nella regione Google Cloud us-central1.
    • Imposta la scadenza del segreto un'ora dopo l'esecuzione del comando.

Crea il cluster e le risorse Kubernetes

Crea un cluster GKE, gli spazi dei nomi Kubernetes e gli account di servizio Kubernetes. Puoi creare due spazi dei nomi, uno per l'accesso di sola lettura e uno per l'accesso in lettura/scrittura al secret. Inoltre, crea un service account Kubernetes in ogni spazio dei nomi da utilizzare con Workload Identity Federation for 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. I cluster Autopilot hanno sempre abilitato Workload Identity Federation for GKE. Se vuoi utilizzare un cluster GKE Standard, devi attivare manualmente la federazione delle identità per i carichi di lavoro per GKE prima di continuare.

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

    kubectl create namespace readonly-ns
    kubectl create namespace admin-ns
    
  3. Crea un account di servizio readonly-sa Kubernetes e un account di servizio admin-sa Kubernetes:

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

Crea criteri di autorizzazione IAM

  1. Concedi all'account di servizio readonly-sa l'accesso in sola lettura al secret:

    gcloud secrets add-iam-policy-binding bq-readonly-key \
        --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/readonly-ns/sa/readonly-sa \
        --role='roles/secretmanager.secretAccessor' \
        --condition=None
    

    Sostituisci quanto segue:

    • PROJECT_NUMBER: il valore numerico di Google Cloud del progetto.
    • PROJECT_ID: l'ID del tuo progetto Google Cloud.
  2. Concedi all'account di servizio admin-sa l'accesso in lettura e scrittura al secret:

    gcloud secrets add-iam-policy-binding bq-readonly-key \
        --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
        --role='roles/secretmanager.secretAccessor' \
        --condition=None
    gcloud secrets add-iam-policy-binding bq-readonly-key \
        --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
        --role='roles/secretmanager.secretVersionAdder' \
        --condition=None
    

Verifica l'accesso alla chiave segreta

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

  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 in admin-ns nello spazio dei nomi.

  3. Esegui il deployment dei pod di test:

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

    L'avvio dei pod potrebbe richiedere alcuni minuti. Per monitorare l'avanzamento, esegui il seguente 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 secret:

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

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

  3. Prova a scrivere nuovi dati nel segreto:

    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 non può scrivere nuovi dati.

  4. Esci dal pod:

    exit
    

Testare l'accesso in lettura e scrittura

  1. Apri una shell nel pod admin-test:

    kubectl exec -it admin-test --namespace=admin-ns -- /bin/bash
    
  2. Prova a leggere il secret:

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

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

  3. Prova a scrivere nuovi dati nel segreto:

    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 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 segreto, ma tutti i pod nello spazio dei nomi readonly-ns che utilizzano l'account di servizio Kubernetes readonly-sa possono solo leggere il segreto.

Accedere ai secret dal codice

In questa sezione:

  1. Esegui il deployment di un'applicazione di esempio che legga il segreto in Secret Manager utilizzando le librerie client.

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

Se possibile, devi accedere ai secret di Secret Manager dal codice dell'applicazione 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 segreto.

  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 esegue 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 registry di immagini di 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
    

    Il pod potrebbe richiedere alcuni minuti per iniziare a funzionare. Se il pod ha bisogno di un nuovo nodo nel tuo cluster, potresti notare eventi di tipo CrashLoopBackOff mentre GKE esegue il provisioning del nodo. Gli arresti anomali si interrompono quando il nodo con esito positivo.

  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 tuoi dati sensibili sui pod, utilizza il componente aggiuntivo Secret Manager per GKE (anteprima). Questo componente aggiuntivo consente di eseguire il deployment e la gestione del provider Google Cloud Secret Manager per il driver CSI Secret Store di Kubernetes nei cluster GKE. Per istruzioni, vedi Utilizza il componente aggiuntivo Secret Manager con GKE.

La fornitura di secret come volumi montati comporta i seguenti rischi:

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

Se possibile, ti consigliamo di accedere ai secret tramite programmazione tramite l'API Secret Manager. Per le istruzioni, utilizza l'applicazione di esempio questo tutorial o consulta le 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. (Facoltativo) Elimina il secret in Secret Manager:

    gcloud secrets delete bq-readonly-key
    

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

Elimina il progetto

    Delete a Google Cloud project:

    gcloud projects delete PROJECT_ID

Passaggi successivi