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

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

La configurazione e l'utilizzo delle identità dei carichi di lavoro gestite per GKE prevede i seguenti passaggi:

  1. Configura Certificate Authority Service per emettere certificati per le identità dei workload gestite.

  2. Collega le CA al pool di identità del workload.

  3. Autorizza le identità dei carichi di lavoro gestite a richiedere certificati dal pool di CA.

  4. Esegui il deployment dei workload con identità dei workload gestite.

Pool di identità del workload gestito da Google

Quando aggiungi i tuoi cluster ai parchi risorse GKE, questi creano automaticamente un pool di identità dei workload gestito da Google che funge da radice del tuo dominio attendibile. 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 equivalenti privilegiati. I workload eseguiti su uno qualsiasi dei cluster nel pool possono utilizzare qualsiasi identità presente nel pool.

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 ciascuna risorsa.

Prima di iniziare

  1. 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.

  2. Informazioni sulle identità dei workload gestiti.

  3. Assicurati di avere almeno un cluster GKE. Assicurati che i tuoi 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 --enable-workload-identity. Fleet crea automaticamente un pool di identità del workload gestito da Google che funge da dominio attendibile.

    Abilita i fleet GKE eseguendo il seguente comando:

    gcloud container clusters update CLUSTER_NAME \
    --enable-workload-identity \
    --enable-fleet \
    --fleet-project=PROJECT_ID

    Sostituisci quanto segue:

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

  5. Enable the IAM and Certificate Authority Service APIs: 

    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 della flotta.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per creare identità del workload gestite e eseguire il provisioning dei certificati di identità del workload gestiti, 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.

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

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

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

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 saperne di più su pool di CA, livelli e regioni, consulta Creazione di pool di CA.

Configura la CA radice

Crea una CA radice nel pool di CA radice utilizzando gcloud privateca roots create. Potresti dover 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:

  • Più scenari di emissione di 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 bilanciamento del carico migliore 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 in grandi volumi.

    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 secondario. 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 ulteriori informazioni, vedi 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 subordinato.
    • 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

Per associare le CA ai pool di identità per i carichi di lavoro, è necessario disporre di una configurazione di emissione dei certificati. Se vuoi che i tuoi workload si autentichino in più domini di attendibilità, puoi anche aggiornare il pool con le configurazioni dell'attendibilità.

Per configurare la configurazione dell'emissione dei certificati, crea un file di configurazione dell'emissione dei certificati. 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 di progetto del progetto in cui hai creato il pool di CA secondarie. 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 secondaria.

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

  • 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 corrispondenza della quale viene attivato un rinnovo. Il valore deve essere compreso tra 50 e 80. Il valore predefinito è 50.

Crea il file di configurazione dell'attendibilità

Per impostazione predefinita, i tuoi carichi di lavoro all'interno dello stesso dominio di attendibilità possono autenticarsi reciprocamente utilizzando le identità del carico di lavoro gestite. Se vuoi che i carichi di lavoro che si trovano in domini attendibili diversi si autentichino reciprocamente, devi dichiarare esplicitamente la relazione di trust nel pool di identità dei carichi di lavoro. A questo scopo, crea un file di configurazione dell'attendibilità che contenga un inlineTrustConfig che fornisca 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.

Per creare il file di configurazione dell'attendibilità:

  1. Scarica i certificati. 

    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 in cui generare il certificato con codifica PEM
    • REGION: la regione del pool di CA radice

  2. Crea un file denominato che contenga la configurazione dell'attendibilità incorporata, con certificati in formato PEM. Il file è simile al seguente: 
    {
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_NAME1": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      },
      "TRUSTED_DOMAIN_NAME2": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

    Sostituisci quanto segue:

    • TRUST_DOMAIN_NAME: il nome del dominio di trust, formattato nel seguente modo: 
      PROJECT_ID.svc.id.goog
    • CERTIFICATE_MATERIAL: Un insieme di certificati CA in formato PEM considerati attendibili per l'emissione di certificati nel dominio di attendibilità.

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à per i carichi di lavoro, aggiorna il pool di identità per i carichi di lavoro 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 \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Sostituisci quanto segue:

  • TRUST_DOMAIN_NAME: Il nome del dominio trust, formattato nel seguente modo:

    PROJECT_ID.svc.id.goog

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

  • TC_JSON_FILE_PATH: (Facoltativo). Il percorso del file di configurazione dell'attendibilità in formato JSON (tc.json) che hai creato in precedenza. Se i tuoi carichi di lavoro si autenticano su domini attendibili diversi, devi specificare questo file. In caso contrario, puoi omettere --inline-trust-config.

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

Per verificare che il pool di identità del workload sia stato aggiornato insieme alla configurazione di emissione dei certificati e alla configurazione di attendibilità, 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 del 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
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

Se inlineCertificateIssuanceConfig o inlineTrustConfig 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à dei carichi di lavoro gestite a richiedere certificati dal pool di CA

Dopo aver associato le CA al pool di identità per i carichi di lavoro, devi autorizzare le identità per i carichi di lavoro 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 subordinata 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/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID

    Sostituisci quanto segue:

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

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

      Per ottenere PROJECT_NUMBER da PROJECT_ID, esegui questo comando:

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

    • PROJECT_ID: l'ID progetto del progetto host del parco risorse GKE.

    • 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 carico di lavoro 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/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID

    Sostituisci quanto segue:

    • SUBORDINATE_CA_POOL_ID: l'ID del pool di CA subordinato.
    • REGION: la regione del pool di CA subordinato.
    • PROJECT_NUMBER: il numero di progetto del progetto che contiene il pool di identità dei workload GKE.
    • PROJECT_ID: l'ID progetto del progetto host del parco risorse GKE.
    • CA_PROJECT_ID: l'ID del progetto in cui hai creato la CA subordinata.

Esegui il deployment dei workload con identità del workload gestite

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

Questa sezione mostra come eseguire il deployment di un carico di lavoro di test con un'identità del workload gestita. Per farlo, devi eseguire il deployment di un pod, verificare che siano state generate le credenziali 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/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.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.

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

Inizia gratuitamente