Configurare l'autenticazione delle identità per i carichi di lavoro gestiti per GKE

Questo documento descrive come configurare le identità dei workload gestite per Google Kubernetes Engine (GKE) nei cluster gestiti dal parco GKE. Descrive inoltre come eseguire il deployment di un workload e verificare l'identità e il certificato del workload.

Per configurare e utilizzare le identità dei carichi di lavoro gestite per GKE, completa i seguenti passaggi:

  1. Scegli un'opzione per l'autorità di certificazione (CA)

  2. Configurare l'autorità di certificazione

  3. Esegui il deployment dei carichi di lavoro con identità di workload gestite

  4. (Facoltativo) Abilita la federazione di attendibilità tra i pool di identità dei workload

Pool di identità del workload gestito da Google

Quando aggiungi cluster ai fleet GKE, GKE crea automaticamente un pool di identità del workload gestito da Google, che funge da radice di attendibilità, noto anche come dominio di attendibilità SPIFFE per i tuoi workload. Tutti i workload all'interno del dominio di trust ricevono certificati e trust anchor che abilitano l'autenticazione per impostazione predefinita all'interno del dominio di trust. Se hai più domini di attendibilità, puoi attivare la federazione di attendibilità tra loro per consentire la comunicazione tra i domini di attendibilità.

Il pool di identità del workload gestito da Google ha le seguenti caratteristiche:

  • Gestione delle identità:Google gestisce completamente il pool. Non puoi creare nessuna risorsa secondaria, come spazi dei nomi, identità o provider di identità.

  • Supporto dei carichi di lavoro:puoi utilizzare il pool solo per i carichi di lavoro GKE. Non puoi aggiungere altri tipi di carichi di lavoro, come le VM di Compute Engine, al pool.

  • Integrazione del parco risorse:tutti i cluster nel pool sono soggetti al modello standard di identità dello spazio dei nomi Kubernetes. Ciò significa che tutti i cluster nel pool hanno privilegi equivalenti e i workload su qualsiasi cluster nel pool possono utilizzare qualsiasi identità all'interno del pool.

Pool di identità del workload autogestito

In ambienti con attendibilità mista, come i fleet multitenant, puoi configurare un pool di identità del workload autogestito separato per un sottoinsieme di workload e cluster. Un pool di identità del workload autogestito ha le seguenti caratteristiche:

  • Gestione delle identità:definendo il tuo pool di identità del workload, ottieni il controllo completo della gestione delle identità nel pool. Nel pool puoi definire la tua gerarchia di identità, ad esempio spazi dei nomi e identità. Puoi definire policy di attestazione per specificare quali workload possono attestare le identità nel pool o negli spazi dei nomi.

  • Supporto dei carichi di lavoro: qualsiasi carico di lavoro (ad esempio VM, container e carichi di lavoro serverless) può essere inserito nel pool.

  • Integrazione del parco risorse: per i workload gestiti dai parchi risorse GKE, i parchi risorse forniscono un'interfaccia integrata per gestire le identità. Puoi configurare il pool di identità del workload come pool di tenancy con ambito del parco risorse. I parchi risorse creano automaticamente spazi dei nomi del pool di identità del workload corrispondenti agli spazi dei nomi del parco risorse e assegnano identità ai workload.

Per utilizzare un pool di identità dei workload autogestito, devi configurare le funzionalità di gestione del team del parco risorse, come gli ambiti del team e gli spazi dei nomi del parco risorse, e configurare il pool autogestito come pool di tenancy dell'ambito. Per istruzioni sulla creazione e configurazione di un pool autogestito, vedi Autenticarsi alle API Google Cloud dai workload del parco risorse con attendibilità mista.

Configurazione per più progetti

Le risorseGoogle Cloud che utilizzi in questo documento, come i cluster GKE, la CA radice e le CA subordinate, possono esistere in progetti separati. Quando fai riferimento a queste risorse, utilizza il flag --project per specificare il progetto corretto per ogni risorsa.

Prima di iniziare

  1. Crea o seleziona un Google Cloud progetto.

    Ruoli richiesti per selezionare o creare un progetto

    • Seleziona un progetto: la selezione di un progetto non richiede un ruolo IAM specifico. Puoi selezionare qualsiasi progetto per il quale ti è stato concesso un ruolo.
    • Crea un progetto: per creare un progetto, devi disporre del ruolo Autore progetto (roles/resourcemanager.projectCreator), che contiene l'autorizzazione resourcemanager.projects.create. Scopri come concedere i ruoli.

    • Creare 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 progetto Google Cloud .

  2. Scopri di più sulle identità di workload gestite.

  3. Assicurati che i cluster eseguano la versione 1.33.0-gke.2248000 o successive.

  4. Aggiungi i tuoi cluster ai parchi risorse GKE. Se il cluster è un cluster Autopilot, ometti il flag --enable-workload-identity. I parchi risorse creano automaticamente un pool di identità del workload gestito da Google, che funge da dominio attendibile.

    Abilita i parchi risorse GKE eseguendo il seguente comando:

    gcloud container clusters update CLUSTER_NAME \
--workload-pool=PROJECT_ID.svc.id.goog \
--enable-fleet \
--fleet-project=PROJECT_ID

    Sostituisci questi valori:

    • CLUSTER_NAME: il nome del cluster GKE da registrare nel parco risorse GKE
    • PROJECT_ID: l'ID progetto host del parco risorse GKE

  5. Abilita le API IAM e Certificate Authority Service.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin), che include l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

    Abilita le API

  6. Configura Google Cloud CLI in modo da utilizzare il progetto di fatturazione e quota.

    gcloud config set billing/quota_project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto del parco risorse.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare identità del workload gestite e eseguire il provisioning dei certificati di identità del workload gestite, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Scegli un'opzione CA

Per firmare i certificati dei workload, scegli l'opzione dell'autorità di certificazione (CA) più adatta al tuo caso d'uso:

  • CA predefinita gestita da Google: utilizza questa opzione per una soluzione completamente gestita e senza costi. L'autorità di certificazione predefinita fornisce una radice di attendibilità condivisa per tutti gli utenti diGoogle Cloud .

  • CA personalizzata: utilizza questa opzione per configurare la tua infrastruttura a chiave pubblica (PKI) tramite Certificate Authority Service. Questa opzione è appropriata se richiedi una radice di attendibilità personalizzata o se devi archiviare le chiavi di firma in un modulo di sicurezza hardware (HSM) per soddisfare i requisiti di conformità. Certificate Authority Service viene addebitato separatamente dall'identità di workload gestita. Per ulteriori informazioni, vedi i prezzi del servizio CA.

Configura una CA

CA predefinita

Per associare la CA predefinita al pool di identità del workload, aggiorna il pool di identità del workload con il flag use-default-shared-ca.

  gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
      --location="global" \
      --use-default-shared-ca \
      --project=PROJECT_ID

Sostituisci quanto segue:

  • TRUST_DOMAIN_NAME:

    Il nome del dominio di trust. A seconda del tipo di pool, formatta il nome nel seguente modo:

    • Pool gestito da Google: PROJECT_ID.svc.id.goog
    • Pool autogestito: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
  • PROJECT_ID: L'ID progetto del tuo progetto host del parco risorse.

CA personalizzata

  1. Configura CA Service per emettere certificati per identità di workload gestite.
  2. Collega le CA al pool di identità del workload.
  3. Autorizza le identità del workload gestite a richiedere certificati dal pool di CA.

Configurare CA Service per emettere certificati per le identità dei workload gestite

Per configurare le identità dei workload gestite per GKE, devi prima configurare un'autorità di certificazione (CA) e una o più CA subordinate. Questa configurazione è nota come gerarchia CA.

Puoi utilizzare i pool del servizio CA per configurare questa gerarchia. Con questa gerarchia, il pool di CA subordinate emette i certificati di identità del workload X.509 per i tuoi workload.

I pool di CA configurati per emettere certificati per i workload che utilizzano identità del workload gestite devono risiedere nella stessa regione del workload. Se vuoi progettare un'architettura multiregionale per la resilienza alle interruzioni a livello regionale, ti consigliamo di configurare un pool di CA del servizio CA subordinato per ogni regione in cui esegui i carichi di lavoro. In questo modo, ogni workload può fare riferimento a un pool di CA Certificate Authority Service subordinato nella regione.

Configura il pool di CA radice

Per creare il pool di CA radice:

Crea il pool di CA radice nel livello Enterprise utilizzando gcloud privateca pools create. Questo livello è destinato all'emissione di certificati di lunga durata e a basso volume.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

Sostituisci quanto segue:

  • ROOT_CA_POOL_ID: un ID univoco per il pool di CA radice. L'ID può contenere fino a 64 caratteri e deve contenere solo caratteri alfanumerici minuscoli e maiuscoli, trattini bassi o trattini. L'ID pool deve essere univoco all'interno della regione.

  • REGION: la regione in cui si trova il pool di CA radice.

  • CA_PROJECT_ID: l'ID progetto in cui vuoi creare la CA radice.

Per scoprire di più su pool di CA, livelli e regioni, consulta la sezione Creazione di pool di CA.

Configura la CA radice

Crea una CA radice nel pool di CA radice utilizzando gcloud privateca roots create. Potrebbe esserti chiesto di attivare la CA radice se è l'unica CA nel pool di CA radice.

Per creare una CA radice, esegui questo comando:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

Sostituisci quanto segue:

  • ROOT_CA_ID: un nome univoco per la CA radice. Il nome dell'autorità di certificazione può contenere fino a 64 caratteri e deve contenere solo caratteri alfanumerici minuscoli e maiuscoli, trattini bassi o trattini. Il nome della CA deve essere univoco all'interno della regione.
  • ROOT_CA_POOL_ID: l'ID del pool di CA radice.
  • ROOT_CA_CN: il nome comune della CA radice.
  • ROOT_CA_ORGANIZATION: l'organizzazione della CA radice.
  • KEY_ALGORITHM: l'algoritmo della chiave, ad esempio ec-p256-sha256.
  • REGION: la regione in cui si trova il pool di CA radice.
  • CA_PROJECT_ID: l'ID progetto in cui hai creato la CA radice.

Per ulteriori informazioni sui campi subject per la CA, vedi Soggetto.

Se vuoi, puoi creare altre CA radice nel pool di CA radice. Questa operazione può essere utile per la rotazione della CA radice.

Configura le CA subordinate

Se vuoi, puoi configurare le CA subordinate. La configurazione delle CA subordinate può aiutare con quanto segue:

  • Scenari di emissione di più certificati: se hai più scenari di emissione di certificati, puoi creare una CA subordinata per ogni scenario.

  • Bilanciamento del carico migliore: l'aggiunta di più CA subordinate in un pool di CA consente di ottenere un migliore bilanciamento del carico delle richieste di certificato.

Per creare un pool di CA subordinate e una CA subordinata:

  1. Crea il pool di CA subordinate nel livello DevOps, che è destinato all'emissione di certificati di breve durata e ad alto volume.

    gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops

    Sostituisci quanto segue:

    • SUBORDINATE_CA_POOL_ID: un ID univoco per il pool di CA secondarie. L'ID può contenere fino a 64 caratteri e deve contenere solo caratteri alfanumerici minuscoli e maiuscoli, trattini bassi o trattini. L'ID pool deve essere univoco all'interno della regione.
    • REGION: La regione in cui creare il pool di CA subordinate.
    • CA_PROJECT_ID: l'ID del progetto in cui hai creato la CA subordinata.

    Per saperne di più, consulta la sezione Creazione di pool di CA.

  2. Crea una CA subordinata nel pool di CA subordinate. Non modificare la modalità di emissione basata sulla configurazione predefinita.

    gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable

    Sostituisci quanto segue:

    • SUBORDINATE_CA_ID: un nome univoco per la CA subordinata. Il nome può contenere fino a 64 caratteri e deve contenere solo caratteri alfanumerici minuscoli e maiuscoli, trattini bassi o trattini. Il nome del pool deve essere univoco all'interno della regione.
    • SUBORDINATE_CA_POOL_ID: il nome del pool di CA subordinato.
    • REGION: la regione in cui si trova il pool di CA subordinate.
    • ROOT_CA_POOL_ID: l'ID del pool di CA radice.
    • REGION: la regione del pool di CA radice.
    • SUBORDINATE_CA_CN: il nome comune della CA subordinata.
    • SUBORDINATE_CA_ORGANIZATION: il nome dell'organizzazione che emette la CA subordinata.
    • KEY_ALGORITHM: l'algoritmo della chiave, ad esempio ec-p256-sha256.
    • CA_PROJECT_ID: l'ID del progetto in cui hai creato la CA subordinata.

    Per ulteriori informazioni sui campi subject per la CA, vedi Soggetto.

Crea un file di configurazione dell'emissione dei certificati

Il binding delle CA ai pool di identità del workload richiede una configurazione dell'emissione di certificati. Se devi autenticare i tuoi workload in più domini attendibili, consulta Abilitare la federazione di trust tra i pool di identità dei workload (facoltativo).

Per configurare la configurazione dell'emissione dei certificati, crea un file di configurazione dell'emissione dei certificati denominato cic.json. Il formato del file è simile al seguente:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

Sostituisci quanto segue:

  • REGION: le regioni in cui si trovano le CA.

  • CA_PROJECT_NUMBER: il numero del progetto in cui hai creato il pool di CA subordinate. Per ottenere il numero di progetto dal progetto CA_PROJECT_ID, esegui questo comando:

    gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"

  • SUBORDINATE_CA_POOL_ID: il nome del pool di CA subordinato.

  • ALGORITHM: (Facoltativo) L'algoritmo di crittografia utilizzato per generare la chiave privata. I valori validi sono ECDSA_P256, ECDSA_P384, RSA_2048, RSA_3072, RSA_4096. Se non specificato, ECDSA_P256 viene utilizzato come algoritmo predefinito.

  • DURATION: (Facoltativo) La durata della validità del certificato end-entity, in secondi. Il valore deve essere compreso tra 86.400 (1 giorno) e 2.592.000 (30 giorni). Se non specificato, viene utilizzato il valore predefinito di 86400 (1 giorno). La validità effettiva del certificato emesso dipende anche dalla CA emittente, perché può limitare la durata del certificato emesso.

  • ROTATION_WINDOW_PERCENTAGE: (Facoltativo) la percentuale della durata del certificato in cui viene attivato un rinnovo. Il valore deve essere compreso tra 50 e 80. Se non specificato, viene utilizzato 50 come valore predefinito.

Associa le CA al pool di identità del workload

Dopo aver creato la gerarchia di CA e le configurazioni di emissione dei certificati per ogni CA, associa le CA al pool di identità del workload. Per associare una CA al pool di identità del workload, aggiorna il pool di identità del workload con la configurazione di emissione dei certificati della CA. Dopodiché, puoi verificare che il pool sia stato aggiornato.

Aggiorna il pool di identità del workload

Per aggiornare il pool, esegui questo comando:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --project=PROJECT_ID

Sostituisci quanto segue:

  • TRUST_DOMAIN_NAME: il nome del dominio attendibile. A seconda del tipo di pool, formatta il nome nel seguente modo:

    • Pool gestito da Google: PROJECT_ID.svc.id.goog
    • Pool autogestito: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  • CIC_JSON_FILE_PATH: il percorso del file di configurazione dell'emissione dei certificati in formato JSON (cic.json) che hai creato in precedenza.

Verifica che il pool di identità del workload sia stato aggiornato

Per verificare che il pool di identità del workload sia stato aggiornato con la configurazione di emissione dei certificati, esegui questo comando:

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

Sostituisci TRUST_DOMAIN_NAME con il nome del dominio attendibile che hai utilizzato per aggiornare il pool di identità del workload in precedenza in questo documento.

L'output comando è simile al seguente:

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
mode: TRUST_DOMAIN
name: TRUST_DOMAIN_NAME
state: ACTIVE

Se inlineCertificateIssuanceConfig non è presente nell'output del comando, verifica di aver configurato correttamente gcloud CLI per utilizzare il progetto corretto per la fatturazione e la quota. Potresti dover eseguire l'aggiornamento a una versione più recente di gcloud CLI.

Autorizza le identità di workload gestite a richiedere certificati dal pool di CA

Dopo aver associato le CA al pool di identità del workload, autorizza le identità del workload gestite a richiedere certificati dal pool di CA. Per autorizzare queste identità:

  1. Concedi il ruolo IAM CA Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester) su ogni pool di CA subordinate al dominio di attendibilità. Il seguente comando gcloud privateca pools add-iam-policy-binding autorizza il dominio attendibile a richiedere certificati dalle catene di certificati del servizio CA.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Sostituisci quanto segue:

    • SUBORDINATE_CA_POOL_ID: l'ID del pool di CA secondario.
    • REGION: la regione del pool di CA subordinate.

    • PROJECT_NUMBER: il numero del progetto che contiene il pool di identità del workload GKE.

      Per ottenere PROJECT_NUMBER dal progetto del pool di identità del workload, esegui questo comando.

      gcloud projects describe WORKLOAD_IDENTITY_POOL_PROJECT_ID --format="value(projectNumber)"

    • WORKLOAD_IDENTITY_POOL_PROJECT_ID: l'ID progetto contenente il pool di identità del workload.

    • TRUST_DOMAIN_NAME: il nome del dominio attendibile. A seconda del tipo di pool, formatta il nome nel seguente modo:

      • Pool gestito da Google: PROJECT_ID.svc.id.goog
      • Pool autogestito: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

    • CA_PROJECT_ID: l'ID del progetto in cui hai creato la CA subordinata.

  2. Concedi il ruolo Lettore pool di CA Service (roles/privateca.poolReader) nei pool di CA secondarie all'identità del workload gestita. In questo modo l'identità del workload gestita viene autorizzata a ottenere i certificati X.509 firmati dalle catene di certificati della CA.

    gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/TRUST_DOMAIN_NAME" \
    --project=CA_PROJECT_ID

    Sostituisci quanto segue:

    • SUBORDINATE_CA_POOL_ID: l'ID del pool di CA secondario.
    • REGION: la regione del pool di CA subordinate.
    • PROJECT_NUMBER: il numero del progetto che contiene il pool di identità del workload GKE.
    • TRUST_DOMAIN_NAME: il nome del dominio attendibile. A seconda del tipo di pool, formatta il nome nel seguente modo:
      • Pool gestito da Google: PROJECT_ID.svc.id.goog
      • Pool autogestito: POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog
    • CA_PROJECT_ID: l'ID del progetto in cui hai creato la CA subordinata.

Esegui il deployment dei workload con identità di workload gestite

Dopo aver configurato i pool di CA per emettere certificati per le identità dei workload gestite, puoi eseguire il deployment dei workload con identità dei workload gestite.

Questa sezione mostra come eseguire il deployment di un workload di test con un'identità di workload gestita. Per farlo, devi eseguire il deployment di un pod, verificare che le credenziali siano state generate e visualizzare il certificato e l'ID SPIFFE.

Esegui il deployment di un pod

Puoi eseguire il deployment di un pod che ottiene la sua identità del workload gestita da un pool di identità del workload gestito da Google o da un pool di identità del workload autogestito.

Pool gestito da Google

Per eseguire il deployment di un pod di test nel cluster:

  1. Recupera le credenziali del cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  2. Crea lo spazio dei nomi Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  3. Esegui il deployment di un PodSpec di test.

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

Pool autogestito

Per eseguire il deployment di un pod di test nel cluster utilizzando un pool di identità dei carichi di lavoro autogestito:

  1. Configura un pool di identità del workload autogestito e configura i cluster fleet in modo che utilizzino questo pool.

  2. Recupera le credenziali del cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

  3. Crea lo spazio dei nomi Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  4. Esegui il deployment di un PodSpec di test.

    La seguente configurazione PodSpec configura l'attributo del volume trustDomain per un pool di identità del workload autogestito:

    cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/tenancy-scope
EOF

Elenca le credenziali del workload

Per elencare le credenziali del workload, esegui questo comando. La creazione delle credenziali può richiedere alcuni minuti.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

L'output comando elenca i seguenti file:

  • ca_certificates.pem: contiene il certificato CA radice che firma il certificato del workload.
  • certificates.pem: contiene il certificato X.509 del workload.
  • private_key.pem: contiene la chiave privata del workload.
  • trust_bundles.json: contiene una mappa dei domini attendibili e dei certificati CA da considerare attendibili per il workload specificato. Ogni voce contiene la stringa del dominio attendibile come chiave e i certificati CA corrispondenti a quel dominio attendibile.
  • credential-bundle.pem: contiene la chiave privata e il certificato concatenati, fornendo un unico file per le credenziali mTLS. Questo file è disponibile solo nelle versioni di GKE successive alla 1.35.2-gke.1291000.

Visualizzare il certificato

Per visualizzare il certificato:

  1. Esporta il certificato in un file di certificato.

    kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

  2. Visualizza il file del certificato.

    cat certfile

    Nel certificato, nell'attributo X509v3 Subject Alternative Name, vedrai l'ID SPIFFE, con un formato simile al seguente a seconda del tipo di pool di identità del workload:

    • Pool gestito da Google: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default
    • Pool autogestito: spiffe://POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    default si riferisce al service account Kubernetes predefinito.

Testa l'autenticazione da workload a workload

Per testare l'autenticazione da workload a workload, vedi Testare l'autenticazione mTLS utilizzando Go.

Il codice campione nel repository crea carichi di lavoro client e server. Puoi testare l'autenticazione reciproca tra i carichi di lavoro utilizzando i certificati che hai generato in precedenza in questo documento.

(Facoltativo) Abilita la federazione attendibile tra i pool di identità dei workload

Per abilitare l'autenticazione reciproca per i workload in domini attendibili diversi, devi configurare la federazione di attendibilità tra i pool di identità del workload. Questo passaggio è necessario solo se i tuoi workload devono autenticarsi con workload in un pool di identità del workload diverso.

Per abilitare la federazione di attendibilità, completa i seguenti passaggi:

  1. Crea il file di configurazione dell'attendibilità.
  2. Aggiorna il pool di identità del workload con la configurazione di attendibilità.

Crea il file di configurazione dell'attendibilità

Crea il file di configurazione dell'attendibilità con una sezione inlineTrustConfig che specifica i certificati per ogni dominio.

Il file di configurazione dell'attendibilità contiene un insieme di trust anchor che l'identità del workload gestito utilizza per convalidare i certificati peer. Il file di configurazione dell'attendibilità mappa il dominio di attendibilità SPIFFE ai certificati CA.

  1. Per la CA personalizzata, scarica i certificati per un dominio attendibile che utilizza una CA personalizzata.

    gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION

    Sostituisci quanto segue:

    • ROOT_CA_POOL_ID: l'ID del pool di CA radice.
    • CERTIFICATE_PATH: il percorso di output per il certificato con codifica PEM.
    • REGION: la regione del pool di CA radice.

  2. Crea un file denominato tc.json contenente la configurazione dell'attendibilità incorporata. Se un dominio utilizza la CA predefinita gestita da Google, utilizza il campo trustDefaultSharedCa. Se un dominio utilizza una CA personalizzata, utilizza i certificati con codifica PEM che hai scaricato in precedenza.

    Il file è simile al seguente:

    In questo esempio, TRUST_DOMAIN_A utilizza la CA predefinita gestita da Google, mentre TRUSTED_DOMAIN_B utilizza una CA personalizzata con i certificati radice scaricati.

    {
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_A": {
        "trustDefaultSharedCa": true
      },
      "TRUSTED_DOMAIN_B": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

    Sostituisci quanto segue:

    • TRUST_DOMAIN_A: il nome del dominio attendibile che utilizza l'AC predefinita gestita da Google.
    • TRUST_DOMAIN_B: il nome del dominio attendibile che utilizza una CA personalizzata.
    • CERTIFICATE_MATERIAL: un insieme di certificati CA in formato PEM attendibili per l'emissione di certificati nel dominio attendibile.

Aggiorna il pool di identità del workload con la configurazione di attendibilità

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Sostituisci quanto segue:

  • TRUST_DOMAIN_NAME: il nome del dominio attendibile.
  • TC_JSON_FILE_PATH: il percorso del file di configurazione dell'attendibilità (tc.json) in formato JSON che hai creato.
  • PROJECT_ID: l'ID progetto.

Passaggi successivi

Provalo

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 senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia senza costi