Spesso le applicazioni devono eseguire l'autenticazione (fornire un'identità autenticabile) quando si connettono ad altri servizi. Ad esempio, le applicazioni devono eseguire l'autenticazione per utilizzare le API Google Cloud come le API Compute Engine o AI Platform. In questa pagina viene spiegato come utilizzare Workload Identity del parco risorse, il modo più semplice e consigliato per eseguire l'autenticazione nelle API e nei servizi Google Cloud per i carichi di lavoro delle applicazioni ospitati in un parco risorse.
Cos'è Workload Identity del parco risorse?
Workload Identity del parco risorse estende la funzionalità fornita in Workload Identity di GKE, che consente ai carichi di lavoro nel tuo cluster di autenticarsi su Google senza che sia necessario scaricare, ruotare manualmente e in generale gestire le chiavi degli account di servizio Google Cloud. I carichi di lavoro vengono invece autenticati utilizzando token di breve durata generati dal cluster. Tutti i cluster in cui è abilitata l'identità dei carichi di lavoro GKE utilizzano il pool di identità per i carichi di lavoro del loro progetto durante l'emissione degli ID, il che consente a Identity and Access Management di considerare attendibili e comprendere le credenziali degli account di servizio Kubernetes. Puoi scoprire di più su Workload Identity di GKE in Utilizzo di Workload Identity.
Con i parchi risorse, i cluster registrati possono ottenere il vantaggio aggiuntivo dell'utilizzo di Floet Workload Identity. I cluster registrati con Workload Identity abilitato nell'appartenenza al parco risorse possono utilizzare il pool di identità dei carichi di lavoro a livello di parco risorse, semplificando la configurazione dell'autenticazione alle API di Google e ad altri servizi nel parco risorse e in più progetti. Workload Identity del parco risorse può essere utilizzato anche dall'agente Connect su alcuni tipi di cluster per eseguire l'autenticazione a Google come parte dell'appartenenza al parco risorse ed è necessario utilizzare alcune funzionalità di GKE Enterprise che funzionano su più progetti, come Cloud Service Mesh.
Come funziona
I parchi risorse utilizzano la federazione delle identità per i carichi di lavoro per fornire a ogni applicazione un'identità federata distinta che può essere utilizzata per l'autenticazione in Google Cloud e in altri servizi che sviluppi. Le applicazioni in esecuzione in un parco risorse ricevono un'identità dei carichi di lavoro federata nel seguente formato:
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]
Dove:
- FLEET_PROJECT_ID.svc.id.goog è una rappresentazione in formato breve del pool di identità per i carichi di lavoro per il parco risorse. Per ogni parco risorse è presente un solo pool di identità per i carichi di lavoro fisso, che viene creato automaticamente.
- K8S_NAMESPACE è lo spazio dei nomi Kubernetes in cui è definito l'account di servizio Kubernetes.
- KSA_NAME è il nome dell'account di servizio Kubernetes collegato all'applicazione.
Tutte le applicazioni ospitate in un parco risorse condividono lo stesso pool di identità per i carichi di lavoro, fornendo alle applicazioni un'identità federata che astrae la posizione in cui è ospitata ciascuna applicazione. In questo modo è possibile concedere a un'applicazione all'interno di un parco l'accesso a una risorsa (ad esempio un'API Google Cloud) una sola volta anziché cluster per cluster, anche se il deployment dell'applicazione viene eseguito in diversi progetti Google Cloud o in cloud diversi. Come per altre funzionalità abilitate per il parco risorse, si basa sul principio dell'identicità del parco risorse, in cui gli oggetti Kubernetes con lo stesso nome in cluster diversi vengono trattati come la stessa cosa. Quindi, ad esempio, se hai un'applicazione con un backend di cui è stato eseguito il deployment in più cluster nello stesso parco risorse e che deve eseguire l'autenticazione in un'API di Google, puoi configurare facilmente l'applicazione in modo che tutti i servizi nel "backend" dello spazio dei nomi può accedere all'API. Per maggiori informazioni su come i parchi risorse utilizzano l'uguaglianza, inclusa l'identicità delle identità, consulta Come funzionano i parchi risorse.
I cluster esterni a Google Cloud possono anche utilizzare Workload Identity del parco risorse per fornire un'identità all'agente Connect per eseguire l'autenticazione su Google. Per saperne di più su quali tipi di cluster utilizzano Workload Identity del parco risorse, consulta la sezione Configurazione del cluster di seguito.
Prima di iniziare
Assicurati di avere 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 interagire con Google Cloud. kubectl
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti sono installati automaticamente.
- L'ultima versione di Google Cloud CLI, che include
Assicurati di aver inizializzato la gcloud CLI per utilizzarla con il tuo progetto.
Configurazione del cluster
Prima che le applicazioni nel parco risorse possano ricevere un'identità del carico di lavoro, i cluster su cui vengono eseguite devono essere registrati nel parco risorse e configurati correttamente per utilizzare Workload Identity. Il modo in cui esegui questa operazione dipende dal tipo di cluster. La maggior parte dei cluster GKE esterni a Google Cloud viene registrata automaticamente nel parco progetti quando li crei. I cluster GKE su Google Cloud e i cluster collegati devono essere registrati manualmente.
Per ulteriori informazioni sulla configurazione del cluster, consulta la documentazione relativa a ciascun tipo di cluster.
GKE
- Abilita GKE Workload Identity sul cluster Google Kubernetes Engine, se non è già abilitato.
- Segui le istruzioni per registrare il cluster utilizzando Workload Identity.
Cluster GKE esterni a Google Cloud
I cluster on-premise su VMware e on bare metal e cluster GKE multi-cloud (sia su AWS che su Azure) vengono registrati automaticamente nel parco risorse al momento della creazione del cluster. Tutti questi tipi di cluster abilitano automaticamente Workload Identity del parco risorse quando viene registrato.
Cluster collegati
I cluster collegati EKS e AKS registrati utilizzando l'API GKE Multi-Cloud sono registrati con Workload Identity del parco risorse abilitato per impostazione predefinita. Altri cluster collegati possono essere registrati con Workload Identity del parco risorse abilitato se soddisfano i requisiti necessari. Segui le istruzioni relative al tipo di cluster in Registrazione di un cluster.
Utilizza Workload Identity del parco risorse
Dopo aver registrato il cluster, i carichi di lavoro di cui è stato eseguito il deployment nel cluster possono utilizzare le identità dei carichi di lavoro dal pool di identità dei carichi di lavoro del parco risorse. Questa sezione mostra come utilizzare l'identità del carico di lavoro per impersonare un account di servizio Google Cloud in modo che i carichi di lavoro possano accedere alle API Google Cloud. Agire come account di servizio è un caso d'uso comune per le identità federate, in quanto consente ai carichi di lavoro di autenticarsi a qualsiasi API Google Cloud a cui l'account di servizio ha accesso, eliminando il carico di manutenzione e sicurezza della gestione delle chiavi degli account di servizio per ogni carico di lavoro.
Rappresentare un account di servizio
Questa sezione mostra come configurare l'identità del carico di lavoro federato di un'applicazione per impersonare un account di servizio fornendo un file delle credenziali predefinite dell'applicazione in un ConfigMap, compresa la creazione e la configurazione dell'account di servizio con le autorizzazioni pertinenti.
L'esempio utilizza i seguenti valori segnaposto:
- WORKLOAD_IDENTITY_POOL è il pool di identità per i carichi di lavoro associato al tuo parco risorse. Come mostrato sopra, il valore di WORKLOAD_IDENTITY_POOL è
FLEET_PROJECT_ID.svc.id.goog
. - IDENTITY_PROVIDER è il nome del provider di identità associato al tuo cluster Kubernetes.
- K8S_NAMESPACE è lo spazio dei nomi Kubernetes in cui è definito l'account di servizio Kubernetes.
- KSA_NAME è il nome dell'account di servizio Kubernetes collegato all'applicazione.
- GSA_NAME è il nome dell'account di servizio Google con cui agirà la tua applicazione.
- GSA_PROJECT_ID è l'ID progetto in cui è definito l'account di servizio Google.
Per configurare l'identità del carico di lavoro del parco risorse per impersonare un account di servizio:
Assicurati che il cluster sia registrato nel parco risorse seguendo i passaggi nella sezione Configurazione del cluster in alto.
Recupera i valori WORKLOAD_IDENTITY_POOL e IDENTITY_PROVIDER per il cluster registrato recuperando i dettagli dell'abbonamento al parco risorse del cluster con il comando seguente. Sostituisci MEMBERSHIP con il nome univoco dell'appartenenza del cluster nel parco risorse:
gcloud container fleet memberships describe MEMBERSHIP \ --project=FLEET_PROJECT_ID
L'output della descrizione dell'abbonamento sarà simile al seguente (alcuni campi sono stati omessi per maggiore chiarezza):
authority: identityProvider: IDENTITY_PROVIDER workloadIdentityPool: WORKLOAD_IDENTITY_POOL name: projects/FLEET_PROJECT_ID/locations/global/memberships/MEMBERSHIP
Crea un account di servizio Google Cloud che la tua applicazione può impersonare durante l'autenticazione su Google, se non ne hai già uno:
gcloud iam service-accounts create GSA_NAME --project=GSA_PROJECT_ID
Non è necessario che l'account di servizio si trovi nel progetto host del parco risorse. Puoi utilizzare qualsiasi account di servizio Google Cloud della tua organizzazione. Puoi scoprire di più sugli account di servizio e sul loro funzionamento in Account di servizio.
Assicurati di aver concesso all'account di servizio le autorizzazioni necessarie per accedere alle API Google Cloud aggiungendo le associazioni di criteri IAM necessarie. Puoi farlo utilizzando
gcloud iam service-accounts add-iam-policy-binding
o un altro metodo, se preferisci. Puoi trovare le autorizzazioni necessarie per utilizzare le API Google Cloud nella documentazione di ciascun servizio e visualizzare un elenco completo dei ruoli predefiniti con le autorizzazioni necessarie nella sezione Informazioni sui ruoli.Autorizza l'identità del carico di lavoro dell'applicazione a impersonare l'account di servizio creando un'associazione di criteri IAM, come descritto di seguito. Questa associazione consente all'identità dei carichi di lavoro federata dell'applicazione di agire come account di servizio Google Cloud.
gcloud iam service-accounts add-iam-policy-binding \ GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \ --project=GSA_PROJECT_ID \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:WORKLOAD_IDENTITY_POOL[K8S_NAMESPACE/KSA_NAME]"
Il campo
--member
è la rappresentazione di IAM dell'identità del carico di lavoro federato dell'applicazione.Crea un ConfigMap contenente il file delle credenziali predefinite dell'applicazione per il carico di lavoro. Questo file indica alla libreria client compilata nel tuo carico di lavoro come eseguire l'autenticazione su Google. Il file delle credenziali predefinite dell'applicazione contiene le informazioni pertinenti sul pool di identità per i carichi di lavoro e sull'account di servizio, nonché il percorso del token previsto che verrà montato nel file system del container nel passaggio successivo.
GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com
è l'indirizzo email dell'account di servizio da impersonare.Questa configurazione in sé non concede l'accesso per impersonare l'account di servizio. Se non esiste anche l'associazione IAM, il pod non sarà in grado di utilizzare l'account di servizio.
kind: ConfigMap apiVersion: v1 metadata: namespace: K8S_NAMESPACE name: my-cloudsdk-config data: config: | { "type": "external_account", "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER", "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken", "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" } }
Segui l'esempio riportato di seguito per configurare il carico di lavoro. Tieni presente che l'oggetto ConfigMap del passaggio precedente è montato nel file system del container come
google-application-credentials.json
, insieme a un file token dell'account di servizio previsto, in/var/run/secrets/tokens/gcp-ksa
. I token previsti vengono emessi da Kubernetes e rappresentano l'identità del carico di lavoro all'interno del cluster. Questi token vengono scambiati automaticamente con Google dalle librerie client di Cloud per ottenerne l'autenticazione con le API di Google. Il campoaudience
del token previsto deve essere impostato sul valore WORKLOAD_IDENTITY_POOL.kind: Namespace apiVersion: v1 metadata: name: K8S_NAMESPACE --- kind: ServiceAccount apiVersion: v1 metadata: namespace: K8S_NAMESPACE name: KSA_NAME automountServiceAccountToken: false --- apiVersion: v1 kind: Pod metadata: name: my-pod namespace: K8S_NAMESPACE spec: serviceAccountName: KSA_NAME containers: - name: my-container image: my-image 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: WORKLOAD_IDENTITY_POOL expirationSeconds: 172800 - configMap: name: my-cloudsdk-config optional: false items: - key: "config" path: "google-application-credentials.json"
Autenticazione dal codice
Le librerie client di Cloud gestiscono automaticamente l'autenticazione in Google Cloud quando le utilizzi per accedere ai servizi Google dal tuo codice. Per utilizzare la configurazione descritta sopra nelle tue applicazioni, devi utilizzare le librerie client di Cloud che supportano la federazione delle identità per i carichi di lavoro. Di seguito sono riportate le versioni minime richieste delle librerie client di Cloud, nonché le istruzioni per controllare la versione attuale:
C++
La maggior parte
Librerie client di Google Cloud per C++
supportare la federazione delle identità utilizzando un oggetto ChannelCredentials
, che
creato chiamando grpc::GoogleDefaultCredentials()
. Per inizializzare questo
credenziale, devi creare le librerie client con la versione 1.36.0 o successiva di
gRPC.
La libreria client di Cloud Storage per C++ utilizza l'API REST, non gRPC, quindi non supporta la federazione delle identità.
Go
Le librerie client per Go supportano la federazione delle identità se utilizzano la versione
v0.0.0-20210218202405-ba52d332ba99 o versioni successive del modulo golang.org/x/oauth2
.
Per verificare quale versione di questo modulo è utilizzata dalla libreria client, esegui il seguenti comandi:
cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2
Java
Le librerie client per Java supportano la federazione delle identità se utilizzano la versione 0.24.0
o successivamente
com.google.auth:google-auth-library-oauth2-http
artefatto.
Per verificare quale versione di questo artefatto è utilizzata dalla libreria client, esegui il comando seguente comando Maven nella directory dell'applicazione:
mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
Node.js
Le librerie client per Node.js supportano la federazione delle identità se utilizzano la versione
7.0.2 o versioni successive del
Pacchetto google-auth-library
.
Per verificare quale versione di questo pacchetto viene utilizzata dalla libreria client, esegui il comando seguente comando nella directory dell'applicazione:
npm list google-auth-library
Quando crei un oggetto GoogleAuth
, puoi specificare un ID progetto oppure
consenti a GoogleAuth
di trovare automaticamente l'ID progetto. Per trovare l'ID progetto
automaticamente, l'account di servizio nel file di configurazione deve avere
Ruolo del browser (roles/browser
) o con autorizzazioni equivalenti, nel tuo
progetto. Per maggiori dettagli, consulta
README
per il pacchetto google-auth-library
.
Python
Le librerie client per Python supportano la federazione delle identità se utilizzano la versione
1.27.0 o versioni successive del
Pacchetto google-auth
.
Per verificare quale versione di questo pacchetto viene utilizzata dalla libreria client, esegui il comando questo comando nell'ambiente in cui è installato il pacchetto:
pip show google-auth
Per specificare un ID progetto per il client di autenticazione, puoi impostare il valore
GOOGLE_CLOUD_PROJECT
o puoi consentire al client di trovare
automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto,
nel file di configurazione deve avere il ruolo Browser (roles/browser
),
o un ruolo con autorizzazioni equivalenti, nel tuo progetto. Per maggiori dettagli, consulta
guida dell'utente per il pacchetto google-auth
.
Passaggi successivi
Scopri le best practice per l'organizzazione dei parchi risorse quando utilizzi la federazione delle identità per i carichi di lavoro.