Esegui l'autenticazione alle API Google Cloud dai workload del parco risorse con attendibilità mista

Questa pagina mostra come configurare le applicazioni per l'autenticazione alle Google Cloud API, come l'API Compute Engine o l'API AI Platform, da parchi risorse con un modello di fiducia misto. Se il tuo parco risorse ha un modello di fiducia condiviso, consulta Eseguire l'autenticazione alle Google Cloud API dai workload del parco risorse con fiducia condivisa.

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma e agli ingegneri della sicurezza che vogliono eseguire l'autenticazione in modo programmatico dai workload del parco risorse alle Google Cloud API. Per saperne di più sui ruoli utente e sulle attività di esempio a cui facciamo riferimento nella Google Cloud documentazione, consulta Ruoli e attività utente GKE comuni.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Informazioni sulla federazione delle identità per i workload del parco risorse per ambienti con fiducia mista

La federazione delle identità per i workload del parco risorse consente di concedere ruoli IAM su Google Cloud API e risorse alle entità del parco risorse, come i workload in uno spazio dei nomi specifico. Per impostazione predefinita, il progetto host del parco risorse utilizza un pool di identità del workload gestito da Google per eseguire il provisioning delle identità per le entità del parco risorse. Tuttavia, negli ambienti con fiducia mista, come i parchi risorse multi-tenant o nei progetti host del parco risorse che eseguono cluster autonomi, ti consigliamo di configurare un pool di identità del workload autogestito separato per un sottoinsieme di workload e cluster.

Le entità che utilizzano un pool di identità del workload autogestito hanno identificatori diversi nelle policy IAM rispetto alle entità che utilizzano il pool di identità del workload gestito da Google del progetto host del parco risorse. In questo modo, la concessione dell'accesso alle entità in uno spazio dei nomi del parco risorse specifico non concede inavvertitamente l'accesso ad altre entità che corrispondono all'identificatore.

I pool di identità del workload autogestiti richiedono l'utilizzo di ambiti dei team. Gli ambiti dei team consentono di controllare l'accesso ai sottoinsiemi di risorse del parco risorse in base al team. Puoi associare ambiti dei team specifici a cluster membri del parco risorse specifici per consentire al team di eseguire il deployment dei workload su questi cluster. All'interno di un ambito del team, i membri del team possono eseguire il deployment dei workload solo negli spazi dei nomi del parco risorse.

L'utilizzo di pool di identità del workload autogestiti per fornire identità per i workload dell'ambito del team offre vantaggi come i seguenti:

  • Assicurati che le concessioni di accesso alle entità negli spazi dei nomi del parco risorse non si applichino inavvertitamente alle entità in altri spazi dei nomi o cluster.
  • Configura un insieme di cluster del parco risorse per ottenere le identità dal pool autogestito associandole a un ambito del team e configurando il pool autogestito come provider di identità in questi cluster.
  • Configura un sottoinsieme dei cluster associati di un ambito del team per ottenere le identità dal pool autogestito configurando il pool autogestito come provider di identità solo in cluster specifici.

Esempio di identità identica in un ambiente con fiducia mista

Tieni presente il seguente scenario:

  • Hai due cluster membri del parco risorse: frontend-cluster e finance-cluster.
  • Non hai configurato un pool di identità del workload autogestito.
  • Crea un ambito del team finance-team e uno spazio dei nomi del parco risorse finance-ns nell'ambito del team.
  • Associa il cluster finance-cluster all'ambito del team finance-team.
  • Concedi un ruolo IAM al service account Kubernetes finance-sa nello spazio dei nomi del parco risorse finance-ns.

Tutti i workload che soddisfano i seguenti criteri condividono la stessa identità:

  • Esegui nello spazio dei nomi del parco risorse finance-ns.
  • Utilizza il service account finance-sa.

Tuttavia, se qualcuno nel cluster frontend-cluster crea uno spazio dei nomi Kubernetes finance-ns e un service account finance-sa, ottiene la stessa identità dei workload nel cluster finance-cluster. Questo perché l'intero parco risorse utilizza il pool di identità del workload gestito da Google del progetto host del parco risorse e perché l'identificatore dell'entità non specifica un cluster host.

Considera le seguenti modifiche allo scenario precedente:

  • Configura un pool di identità del workload autogestito nel tuo parco risorse.
  • Configura il cluster finance-cluster in modo che ottenga le identità dal pool autogestito anziché dal pool gestito da Google.
  • Crea una concessione di ruolo IAM che specifichi il pool autogestito nell'identificatore dell'entità anziché il pool gestito da Google.

I workload in esecuzione nello spazio dei nomi del parco risorse finance-ns in finance-cluster ora ottengono un'identità dal pool autogestito. Tuttavia, le entità nello spazio dei nomi Kubernetes finance-ns nel cluster frontend-cluster continuano a ottenere le identità dal pool di identità del workload gestito da Google del progetto host del parco risorse.

Queste modifiche comportano i seguenti vantaggi:

  • Puoi concedere esplicitamente i ruoli alle entità nello spazio dei nomi del parco risorse finance-ns.
  • Le entità nel cluster frontend-cluster non possono ottenere lo stesso accesso perché le identità nel cluster frontend-cluster provengono dal pool di identità del workload gestito da Google.

Prima di iniziare

  • Assicurati di aver installato i seguenti strumenti a riga di comando:

    • L'ultima versione di Google Cloud CLI, che include gcloud, lo strumento a riga di comando per l'interazione con Google Cloud.
    • kubectl

    Se utilizzi Cloud Shell come ambiente shell per l'interazione con Google Cloud, questi strumenti sono installati per te.

  • Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

Requisiti

Devi utilizzare le funzionalità di gestione dei team del parco risorse, come gli ambiti dei team e gli spazi dei nomi del parco risorse. Le istruzioni riportate in questa pagina mostrano come configurare un ambito del team e uno spazio dei nomi del parco risorse di esempio.

Prepara i cluster

Prima che le applicazioni nel parco risorse possano ricevere un'identità federata, i cluster su cui vengono eseguite devono essere registrati nel parco risorse e configurati correttamente per utilizzare la federazione delle identità per i workload del parco risorse. Le seguenti sezioni descrivono come configurare la federazione delle identità per i workload del parco risorse per diversi tipi di cluster.

GKE

Per i cluster GKE, devi registrare il cluster nel parco risorse.

Cluster esterni Google Cloud

I seguenti tipi di cluster abilitano automaticamente la federazione delle identità per i workload del parco risorse e vengono registrati nel parco risorse durante la creazione del cluster:

  • Google Distributed Cloud (solo software) su VMware
  • Google Distributed Cloud (solo software) su bare metal
  • GKE su AWS
  • GKE su Azure

Cluster collegati

I cluster collegati EKS e AKS registrati utilizzando l'API GKE Multi-cloud vengono registrati con la federazione delle identità per i workload del parco risorse abilitata per impostazione predefinita. Altri cluster collegati possono essere registrati con la federazione delle identità per i workload del parco risorse abilitata se soddisfano i requisiti necessari. Segui le istruzioni per il tipo di cluster in Registrare un cluster.

Configura un pool di identità del workload IAM

In questa sezione crei un nuovo pool di identità del workload IAM nel progetto host del parco risorse e concedi all'agente di servizio del parco risorse l'accesso al nuovo pool. Questo pool di identità del workload è il pool autogestito.

  1. Crea un pool di identità del workload:

    gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN

    Sostituisci quanto segue:

    • POOL_NAME: il nome del nuovo pool di identità del workload.
    • POOL_HOST_PROJECT_ID: l'ID progetto del progetto in cui vuoi creare il pool di identità del workload autogestito. Puoi utilizzare qualsiasi Google Cloud progetto, incluso il progetto host del parco risorse progetto.

  2. Concedi il ruolo Amministratore pool Workload Identity IAM (roles/iam.workloadIdentityPoolAdmin) sul nuovo pool di identità del workload all'agente di servizio del parco risorse:

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

    Sostituisci FLEET_HOST_PROJECT_NUMBER con il numero del progetto host del parco risorse.

    Per seguire il principio di sicurezza delle best practice del privilegio minimo, questo comando concede il ruolo Amministratore pool Workload Identity IAM per il pool di identità del workload specifico che stai utilizzando per il parco risorse e non per tutti i pool di identità del workload nel progetto.

Aggiungi il pool autogestito alla configurazione del parco risorse

In questa sezione, abiliti i pool autogestiti con la federazione delle identità per i workload del parco risorse e aggiungi il pool che hai creato alla configurazione del parco risorse. Questa sezione fornisce anche istruzioni per creare un nuovo ambito del team e uno spazio dei nomi del parco risorse. Se il tuo parco risorse ha già configurato ambiti dei team e spazi dei nomi del parco risorse, salta questi passaggi.

  1. Abilita la federazione delle identità per i workload del parco risorse a livello di parco risorse:

    gcloud container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    Sostituisci FLEET_HOST_PROJECT_ID con l'ID progetto del progetto host del parco risorse.

  2. Aggiungi il pool di identità del workload autogestito alla configurazione del parco risorse:

    gcloud container fleet workload-identity scope-tenancy-pool set POOL_NAME

    Sostituisci POOL_NAME con il nome del pool di identità del workload autogestito. Questo valore ha la seguente sintassi:

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  3. Crea un nuovo ambito del team. Se hai già un ambito del team e uno spazio dei nomi del parco risorse, vai alla sezione Verifica la configurazione del pool di identità del workload.

    gcloud container fleet scopes create SCOPE_NAME

    Sostituisci SCOPE_NAME con il nome del nuovo ambito del team.

  4. Crea un nuovo spazio dei nomi del parco risorse nell'ambito del team:

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME

    Sostituisci NAMESPACE_NAME con il nome del nuovo spazio dei nomi del parco risorse.

  5. Associa un cluster nel parco risorse all'ambito del team:

    gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME

    Sostituisci quanto segue:

    • BINDING_NAME: il nome della nuova associazione di appartenenza.
    • FLEET_CLUSTER_NAME: il nome del cluster del parco risorse esistente da associare all'ambito del team.

Verifica la configurazione del pool di identità del workload

In questa sezione, ti assicuri che la configurazione del pool di identità del workload autogestito sia andata a buon fine.

  1. Descrivi la configurazione dell'appartenenza al parco risorse:

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global

    Sostituisci FLEET_CLUSTER_NAME con il nome di un cluster del parco risorse esistente associato a un ambito del team nel parco risorse.

    L'output è simile al seguente:

    authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...

    Questo output deve contenere i seguenti campi:

    • scopeTenancyIdentityProvider: il provider di identità per i workload in esecuzione negli spazi dei nomi del parco risorse all'interno degli ambiti dei team. Il valore è un identificatore di risorsa per il cluster.
    • scopeTenancyWorkloadIdentityPool: il pool di identità del workload da cui i workload negli spazi dei nomi del parco risorse all'interno degli ambiti dei team ottengono gli identificatori. Il valore è il pool di identità del workload autogestito, con il formato POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • workloadIdentityPool: il nome del pool di identità del workload gestito da Google del progetto host del parco risorse, da cui tutti gli altri workload del parco risorse ottengono le identità per impostazione predefinita.

  2. (Facoltativo) Controlla se il pool di identità del workload ha uno spazio dei nomi con lo stesso nome dello spazio dei nomi del parco risorse:

    gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

    L'output è simile al seguente:

    ---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

Il parco risorse può ora utilizzare il pool di identità del workload autogestito per ottenere le identità per i workload in esecuzione negli spazi dei nomi del parco risorse. Per iniziare a utilizzare il pool autogestito, configura la modalità di ottenimento delle identità da parte di cluster specifici, come descritto nella sezione successiva.

Configura i workload in modo che utilizzino i pool autogestiti per le identità

Per configurare i workload in modo che utilizzino il pool autogestito, configura spazi dei nomi del parco risorse specifici nei cluster membri del parco risorse utilizzando un oggetto ConfigMap di Kubernetes. Questa configurazione per cluster e per spazio dei nomi consente di ridurre ulteriormente l'ambito delle concessioni di accesso dagli interi spazi dei nomi del parco risorse ai workload in esecuzione in spazi dei nomi del parco risorse specifici in cluster specifici.

  1. Connettiti al cluster membro del parco risorse:

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION

    Sostituisci quanto segue:

    • FLEET_CLUSTER_NAME: il nome di un cluster membro del parco risorse già associato a un ambito del team.
    • CLUSTER_PROJECT_ID: l'ID progetto del progetto del cluster.
    • CLUSTER_LOCATION: la località del cluster.

  2. Recupera il nome completo del pool di identità del workload autogestito. Ti servirà in un secondo momento.

    gcloud iam workload-identity-pools describe POOL_NAME --location=global

    L'output è simile al seguente:

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. Recupera il nome del provider di identità per gli ambiti dei team. Ti servirà in un secondo momento.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

    L'output è simile al seguente:

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

  4. In un editor di testo, salva il seguente manifest YAML per un oggetto ConfigMap come self-managed-pool.yaml:

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:POOL_NAME:IDENTITY_PROVIDER",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "credential_source": {
        "file": "/var/run/secrets/tokens/gcp-ksa/token"
      }
    }

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse.
    • POOL_NAME: il nome completo del pool di identità del workload autogestito dall'output dei passaggi precedenti in questa sezione. Ad esempio, projects/1234567890/locations/global/workloadIdentityPools/example-pool.
    • IDENTITY_PROVIDER: il nome del provider di identità dall'output dei passaggi precedenti in questa sezione. Ad esempio, https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.

  5. Esegui il deployment dell'oggetto ConfigMap nel cluster:

    kubectl create -f self-managed-pool.yaml

Il deployment dell'oggetto ConfigMap indica a GKE che i workload in questo spazio dei nomi devono utilizzare il pool di identità del workload autogestito per ottenere le identità.

Concedi ruoli IAM alle entità

In questa sezione crei un service account Kubernetes in uno spazio dei nomi del parco risorse e concedi un ruolo IAM al service account. I pod che utilizzano questo service account possono quindi accedere alle Google Cloud risorse su cui concedi il ruolo.

  1. Crea un service account Kubernetes nello spazio dei nomi del parco risorse:

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Sostituisci quanto segue:

    • SERVICEACCOUNT_NAME: il nome del nuovo service account.
    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse.

  2. Concedi un ruolo IAM al service account. Il seguente comando di esempio concede il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) su un bucket al service account:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

Il flag member contiene l'identificatore dell'entità per il nuovo service account che hai creato. Le richieste che i workload inviano alle Google Cloud API utilizzano un token di accesso federato. Questo token di accesso federato include l'identificatore dell'entità che invia la richiesta. Se l'entità in una policy di autorizzazione che concede un ruolo sulla risorsa di destinazione corrisponde all'entità nel token di accesso federato, l'autenticazione e l'autorizzazione possono continuare.

Esegui il deployment dei workload che utilizzano il pool autogestito

I manifest Kubernetes che applichi nello spazio dei nomi del parco risorse devono essere configurati per ottenere le identità dal pool autogestito. I workload di cui esegui il deployment che devono chiamare Google Cloud le API devono includere i seguenti campi:

  • metadata.namespace: il nome dello spazio dei nomi del parco risorse.
  • spec.serviceAccountName: il nome del service account Kubernetes nello spazio dei nomi del parco risorse.
  • spec.containers.env: una variabile di ambiente denominata GOOGLE_APPLICATION_CREDENTIALS che indica il percorso del file delle credenziali predefinite dell'applicazione (ADC).
  • spec.containers.volumeMounts: un volume di sola lettura che consente al container di utilizzare il token di autenticazione per il service account.
  • spec.volumes: un volume proiettato che monta un token del service account nel pod. Il pubblico del token è il pool di identità del workload autogestito. L'oggetto ConfigMap che contiene la configurazione della federazione delle identità per i workload del parco risorse è una fonte per il volume.

Per un esempio di file manifest configurato correttamente, consulta la sezione Verificare l'autenticazione da un workload.

Verifica l'autenticazione da un workload

Questa sezione fornisce istruzioni facoltative per verificare di aver configurato correttamente il pool di identità del workload autogestito elencando i contenuti di un bucket Cloud Storage di esempio. Crea un bucket, concedi un ruolo sul bucket a un service account in uno spazio dei nomi del parco risorse ed esegui il deployment di un pod per provare ad accedere al bucket.

  1. Crea un bucket Cloud Storage:

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

  2. Concedi il ruolo roles/storage.objectViewer sul bucket al service account nello spazio dei nomi del parco risorse:

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Sostituisci quanto segue:

    • FLEET_HOST_PROJECT_NUMBER: il numero del progetto host del parco risorse.
    • POOL_NAME: il nome del pool di identità del workload autogestito.
    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse in cui vuoi eseguire il pod.
    • SERVICEACCOUNT_NAME: il nome del service account Kubernetes che il pod deve utilizzare.

  3. Salva il seguente manifest come pod-bucket-access.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_NAME
  containers:
  - name: sample-container
    image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    env:
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json
    volumeMounts:
    - name: gcp-ksa
      mountPath: /var/run/secrets/tokens/gcp-ksa
      readOnly: true
  volumes:
  - name: gcp-ksa
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          path: token
          audience: POOL_NAME
          expirationSeconds: 172800
      - configMap:
          name: google-application-credentials
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse in cui vuoi eseguire il pod.
    • SERVICEACCOUNT_NAME: il nome del service account Kubernetes che il pod deve utilizzare.
    • POOL_NAME: il nome del pool di identità del workload autogestito.

  4. Esegui il deployment del pod nel cluster:

    kubectl apply -f pod-bucket-access.yaml

  5. Apri una sessione shell nel pod:

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

  6. Prova a elencare gli oggetti nel bucket:

    curl -X GET -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
    "https://storage.googleapis.com/storage/v1/b/FLEET_HOST_PROJECT_ID-workload-id-bucket/o"

    L'output è il seguente:

    {
  "kind": "storage#objects"
}

Facoltativamente, puoi verificare che uno spazio dei nomi e un service account simili in un cluster membro del parco risorse diverso non siano in grado di asserire la stessa identità. In un cluster che utilizza la federazione delle identità per i workload del parco risorse, ma non ha uno spazio dei nomi del parco risorse o una configurazione del pool autogestito, segui questi passaggi:

  1. Crea un nuovo spazio dei nomi Kubernetes con lo stesso nome dello spazio dei nomi del parco risorse in cui hai configurato il pool di identità del workload autogestito.
  2. Crea un nuovo service account Kubernetes con lo stesso nome del service account a cui hai concesso un ruolo IAM nelle sezioni precedenti.

  3. Esegui il deployment di un pod che utilizza lo stesso service account e lo stesso spazio dei nomi, ma per il quale il campo spec.volumes.projected.sources.serviceAccountToken specifica il pool di identità del workload gestito da Google. Questo pool ha la seguente sintassi:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Prova ad accedere al bucket Cloud Storage da una sessione shell nel pod.

L'output dovrebbe essere un errore 401: Unauthorized, perché l'identificatore dell'entità per il pod che utilizza il pool di identità del workload gestito da Google è diverso dall'identificatore dell'entità per il pod che utilizza il pool autogestito.

Passaggi successivi