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

Questo documento spiega come configurare le identità dei carichi di lavoro gestiti per Google Kubernetes Engine (GKE) nei cluster gestiti dai fleet GKE. Inoltre, spiega come eseguire il deployment di un carico di lavoro e verificarne l'identità e il certificato.

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à per i carichi di lavoro gestiti.

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

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

  4. Esegui il deployment dei carichi di lavoro con identità del carico di lavoro gestite.

Pool di identità del workload gestito da Google

Quando aggiungi i tuoi cluster ai parchi risorse GKE, questi ultimi creano automaticamente un pool di identità dei carichi di lavoro gestito da Google che funge da radice del tuo dominio attendibile. Il pool di identità per i carichi di lavoro gestito da Google presenta i seguenti vincoli:

  • Google gestisce completamente il pool, pertanto non puoi creare risorse secondarie, come ambiti, 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 del pool sono soggetti al modello di identità dello spazio dei nomi Kubernetes standard. Ciò significa che tutti i cluster del pool sono equiparati ai cluster con privilegi. I carichi di lavoro eseguiti su uno dei cluster del pool possono utilizzare qualsiasi identità al suo interno.

Configurazione per più progetti

Le risorseGoogle Cloud che utilizzi in questo documento, come i cluster GKE, la CA radice e le CA secondarie, 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. 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. Scopri di più sulle identità dei carichi di lavoro gestiti.

  3. Assicurati di aver creato un cluster GKE.

  4. Aggiungi i tuoi cluster ai parchi risorse GKE. Se il cluster è un cluster Autopilot, ometti --enable-workload-identity. Fleets crea 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 \
    --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 che ospita il parco risorse 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 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 ulteriori informazioni sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

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

Configurare il servizio CA per emettere certificati per le identità per i carichi di lavoro gestiti

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

Puoi utilizzare i pool di servizi CA per configurare questa gerarchia. Con questa gerarchia, il pool di CA secondarie emette i certificati di identità del carico di lavoro X.509 per i tuoi carichi di lavoro.

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 a lungo termine 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 principale. 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 Creare 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 principale, esegui il seguente 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 della CA può avere una lunghezza massima di 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 principale.
  • KEY_ALGORITHM: l'algoritmo 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, consulta Soggetto.

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

Configura le CA subordinate

Se vuoi, puoi configurare le CA secondarie. La configurazione delle CA subordinate può essere utile per:

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

  • Miglior bilanciamento del carico: l'aggiunta di più CA subordinate in un pool di CA consente di bilanciare meglio il 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, pensato per l'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 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 Creare 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 secondario.
    • REGION: la regione in cui si trova il pool di CA secondario.
    • 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 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, consulta 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 carichi di lavoro si autentichino in più domini di attendibilità, puoi anche aggiornare il pool con le configurazioni di attendibilità.

Per configurare la configurazione dell'emissione dei certificati, crea un file di configurazione dell'emissione dei certificati. Il formato del file è simile a quanto segue:

{
  "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 secondario. Per ottenere il numero di progetto dal progetto CA_PROJECT_ID, esegui il seguente comando:

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

  • SUBORDINATE_CA_POOL_ID: il nome del pool di CA secondario.

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

  • DURATION: facoltativo. La durata di validità del certificato end-entity, in secondi. Il valore deve essere compreso tra 86400 (1 giorno) e 2592000 (30 giorni). Se non specificato, viene utilizzato il valore predefinito 86400 (1 giorno). La validità effettiva del certificato emesso dipende anche dall'autorità di certificazione emittente, in quanto 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. Il valore predefinito è 50.

Crea il file di configurazione dell'attendibilità

Per impostazione predefinita, i carichi di lavoro all'interno dello stesso dominio attendibile possono autenticarsi reciprocamente utilizzando le identità dei carichi di lavoro gestiti. Se vuoi che i carichi di lavoro che si trovano in domini di attendibilità diversi si autentichino reciprocamente, devi dichiarare esplicitamente la relazione di attendibilità nel pool di identità dei carichi di lavoro. Per farlo, crea un file di configurazione attendibile contenente un inlineTrustConfig che fornisce i certificati per ogni dominio.

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

Per creare il file di configurazione della 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 di attendibilità in linea, con certificati in formato PEM. Il file sarà 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 di dominio attendibile, nel seguente formato: 
      PROJECT_ID.svc.id.goog
    • CERTIFICATE_MATERIAL: un insieme di certificati CA in formato PEM considerati attendibili per l'emissione di certificati nel dominio attendibile.

Associa le CA al pool di identità del workload

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

Aggiorna il pool di identità del workload

Per aggiornare il pool, esegui il seguente 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 attendibile, formato come segue:

    PROJECT_ID.svc.id.goog

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

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

Verificare che il pool di identità per i carichi di lavoro sia stato aggiornato

Per verificare che il pool di identità del carico di lavoro sia stato aggiornato insieme alla configurazione di emissione dei certificati e alla configurazione della attendibilità, esegui il seguente comando:

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

Sostituisci TRUST_DOMAIN_NAME con il nome di 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 la CLI gcloud in modo da utilizzare il progetto corretto per la fatturazione e la quota. Potresti dover eseguire l'aggiornamento a una versione più recente della CLI gcloud.

Autorizza le identità per i carichi di lavoro gestite a richiedere certificati dal pool 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 al dominio attendibile il ruolo IAM CA Service Workload Certificate Requester (roles/privateca.workloadCertificateRequester) su ogni pool di CA secondarie. Il seguente comando gcloud privateca pools add-iam-policy-binding consente al dominio attendibile di 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 secondario.
    • REGION: la regione del pool di CA secondarie.

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

      Per ottenere PROJECT_NUMBER da PROJECT_ID, esegui il seguente comando:

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

    • PROJECT_ID: l'ID 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 CA Service Pool Reader (roles/privateca.poolReader) ai pool di CA secondari per l'identità del carico di lavoro gestito. In questo modo, l'identità del carico di lavoro gestito 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 secondarie.
    • PROJECT_NUMBER: il numero del progetto che contiene il pool di identità del workload GKE.
    • PROJECT_ID: l'ID 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 carichi di lavoro con identità del carico di lavoro gestite

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

Questa sezione mostra come eseguire il deployment di un carico di lavoro di test con un'identità di carico di lavoro gestito. Per farlo, esegui il deployment di un pod, controlla che le credenziali siano state generate e visualizza 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 carico di lavoro

Per elencare le credenziali del carico di lavoro, esegui il seguente 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

Visualizza il certificato

Per visualizzare il certificato:

  1. Esporta il certificato in un file del 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 il seguente formato: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

    default si riferisce all'account di servizio 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 di esempio nel repository crea carichi di lavoro client e server. Puoi verificare 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