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 alle flotte 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 presenta i seguenti vincoli:

• Google gestisce completamente il pool, quindi non puoi creare risorse secondarie, come spazi dei nomi, identità o provider di identità.

• Il pool può essere utilizzato solo per i carichi di lavoro GKE. Non puoi aggiungere altri tipi di carichi di lavoro, come le VM Compute Engine, al pool.

• 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 sono equivalentemente privilegiati. I workload su qualsiasi cluster nel pool possono utilizzare qualsiasi identità all'interno di quel pool.

Configurazione per più progetti

Le risorseCloud de Confiance 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 ciascuna risorsa.

Prima di iniziare

1. Crea o seleziona un Cloud de Confiance 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 Cloud de Confiance :

     gcloud projects create PROJECT_ID

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

   • Seleziona il progetto Cloud de Confiance che hai creato:

     gcloud config set project PROJECT_ID

     Sostituisci PROJECT_ID con il nome del progetto Cloud de Confiance .

2. Scopri di più sulle identità dei 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 fleet 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.s3ns.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.

   gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com

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à dei carichi di lavoro gestite e eseguire il provisioning dei certificati di identità dei carichi di lavoro gestiti, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

• Per creare e configurare le identità del workload gestite: IAM Workload Identity Pool Admin (roles/iam.workloadIdentityPoolAdmin)
• Per creare e configurare i pool di CA: CA Service Admin (roles/privateca.admin)

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'AC predefinita fornisce una radice di attendibilità condivisa per tutti gli utenti di Cloud de Confiance .

• 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à del workload gestita. Per ulteriori informazioni, consulta Prezzi del servizio CA.

Configura una CA

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

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

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

{
  "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"
  }
}

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

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

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: PROJECT_ID.s3ns.svc.id.goog
state: ACTIVE

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

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/s3ns.svc.id.goog
   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

Dovresti vedere l'output seguente:

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

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, viene visualizzato l'ID SPIFFE, con il seguente formato: spiffe://PROJECT_ID.s3ns.svc.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, consulta 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 l'autorità di certificazione (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

• Risolvi i problemi relativi a Workload Identity gestita per GKE.
• Scopri di più sulla creazione di pool di CA.