Informazioni sui service account in GKE

Questo documento descrive i service account in Google Kubernetes Engine (GKE) e il modo in cui forniscono identità per le applicazioni. Scoprirai i diversi tipi di service account e quando utilizzare ciascun tipo per autenticare l'accesso alle risorse in GKE senza fare affidamento su credenziali personali.

Questo documento è destinato a specialisti della sicurezza e operatori che creano e gestiscono service account per interagire con le applicazioni GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta la pagina Ruoli utente e attività comuni di GKE. Google Cloud

Service account Kubernetes e service account IAM

La seguente tabella descrive le principali differenze tra gli account di servizio Kubernetes e gli account di servizio IAM:

Tipi di service account in GKE
ServiceAccount Kubernetes
  • oggetto ServiceAccount nel server API Kubernetes
  • Ambito di uno spazio dei nomi Kubernetes in un cluster
  • Fornisce un'identità da utilizzare per i pod all'interno del cluster
Service account IAM
  • Gestisci utilizzando l'API IAM
  • Ambito limitato a un progetto Google Cloud
  • Fornisce un'identità per le applicazioni nel progetto

ServiceAccount Kubernetes

Gli account di servizio Kubernetes sono gestiti a livello di cluster ed esistono nel server API di Kubernetes come oggetti ServiceAccount. La documentazione di Kubernetes e la documentazione di GKE utilizzano spesso il termine ServiceAccount per distinguere queste risorse Kubernetes dai service account in altri ambienti come IAM.

Crea un ServiceAccount Kubernetes in uno spazio dei nomi e poi assegna questo ServiceAccount a un pod utilizzando il campo serviceAccountName nel manifest del pod. Il processo kubelet sul nodo riceve un token di autenticazione temporaneo per il service account assegnato e monta il token come volume proiettato nel pod. Per impostazione predefinita, questo volume proiettato ha un nome che inizia con il prefisso kube-api-access-. Tutti i volumi che iniziano con questo prefisso sono gestiti da GKE, il che significa che non puoi modificarne le dimensioni. Per un monitoraggio più accurato dell'utilizzo del disco, escludi i volumi che iniziano con il prefisso kube-api-access- dalla configurazione del monitoraggio.

Il token di autenticazione temporaneo è un token web JSON (JWT) firmato dal server API, che è un provider OpenID Connect (OIDC). Per convalidare il token di autenticazione, recupera la chiave di convalida pubblica per il cluster chiamando il metodo projects.locations.clusters.getJwks nell'API GKE.

Credenziali del service account Kubernetes compromesse

Se le credenziali di un account di servizio Kubernetes vengono compromesse, utilizza una delle seguenti opzioni per revocarle:

  • Ricrea i pod: il token di autenticazione è associato a ogni UID pod univoco, quindi la ricreazione dei pod invalida le credenziali precedenti.
  • Ricrea il service account Kubernetes: il token di autenticazione è associato all'UID dell'oggetto ServiceAccount nell'API Kubernetes. Elimina ServiceAccount e creane uno nuovo con lo stesso nome. I token precedenti diventano non validi perché l'UID del nuovo ServiceAccount è diverso.
  • Esegui una rotazione delle credenziali: questa operazione revoca tutte le credenziali del account di servizio Kubernetes nel cluster. La rotazione modifica anche il certificato CA e l'indirizzo IP del cluster. Per maggiori dettagli, vedi Rotazione delle credenziali.

Service account IAM

I service account IAM vengono gestiti a livello di progetto utilizzando l'API IAM. Puoi utilizzare questi service account per eseguire azioni come chiamare in modo programmatico le API di Google Cloude gestire le autorizzazioni per le applicazioni in esecuzione nei prodotti Google Cloud.

Per saperne di più, consulta la panoramica dei service account IAM.

Agenti di servizio GKE

Un agente di servizio IAM è un account di servizio IAM che Google Cloud gestisce. GKE utilizza i seguenti due service agent:

Kubernetes Engine Service Agent

GKE utilizza l'agente di servizio Kubernetes Engine per gestire il ciclo di vita delle risorse del cluster per tuo conto, come nodi, dischi e bilanciatori del carico. Questo service agent ha il dominio container-engine-robot.iam.gserviceaccount.com e gli viene concesso il ruolo Agente di servizio Kubernetes Engine (roles/container.serviceAgent) sul tuo progetto quando abiliti l'API GKE.

L'identificatore di questo agente di servizio è il seguente:

service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER è il numero di progetto numerico del progetto che contiene il cluster GKE.

Kubernetes Engine Default Node Service Agent

GKE utilizza l'agente di servizio del nodo predefinito di Kubernetes Engine per supportare il logging e il monitoraggio dei nodi Kubernetes per i cluster che utilizzano Kubernetes versione 1.33 e successive. Questo service agent ha il dominio gcp-sa-gkenode.iam.gserviceaccount.com e gli viene concesso il ruolo Kubernetes Engine Default Node Service Agent (roles/container.defaultNodeServiceAgent) sul tuo progetto quando abiliti l'API GKE.

L'identificatore di questo agente di servizio è il seguente:

service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

CLUSTER_PROJECT_NUMBER è il numero di progetto numerico del progetto che contiene il cluster GKE.

Se rimuovi le autorizzazioni dell'agente di servizio nel tuo progetto, puoi recuperarle seguendo le istruzioni riportate in Errore 400/403: autorizzazioni di modifica mancanti per l'account.

Service account del nodo

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account nodo devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) sul tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Se la tua organizzazione applica il vincolo del criterio dell'organizzazione iam.automaticIamGrantsForDefaultServiceAccounts, ilaccount di serviziot Compute Engine predefinito nel tuo progetto potrebbe non ottenere automaticamente le autorizzazioni richieste per GKE.

Se utilizzi il account di servizio predefinito di Compute Engine per altre funzioni nel tuo progetto o nella tua organizzazione, il account di servizio potrebbe disporre di più autorizzazioni di quelle necessarie a GKE, il che potrebbe esporti a rischi per la sicurezza.

Non disattivare il account di servizio Compute Engine predefinito a meno che tu non stia eseguendo la migrazione agli service account gestiti dall'utente.

Indirizzi email dei service account dei nodi

L'indirizzo email del account di servizio del nodo dipende dal tipo di service account, come segue:

  • Service account Compute Engine predefinito:

    CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.com

    Sostituisci CLUSTER_PROJECT_NUMBER con il numero di progetto del progetto che contiene il cluster, ad esempio 1234567890.

  • Service account personalizzato:

    SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com

    Sostituisci quanto segue:

    • SERVICE_ACCOUNT_NAME: il nome del service account.
    • SERVICE_ACCOUNT_PROJECT_ID: l'ID progetto del progetto Google Cloud che contiene l'account di servizio.

Service account del nodo e agenti di servizio del progetto

Quando crei un cluster o un pool di nodi, gli agenti di servizio nel progetto del cluster utilizzano ilaccount di serviziot collegato ai nodi per eseguire attività come il pull delle immagini. Per impostazione predefinita, gli agenti di servizio nel progetto cluster hanno il seguente accesso ai service account dei nodi in quel progetto:

  • L'agente di servizio Compute Engine in un progetto può creare token di accesso per i service account dei nodi nello stesso progetto.
  • L'agente di servizio GKE in un progetto può simulare l'identità dei service account dei nodi nello stesso progetto.

Alcune organizzazioni utilizzano un progetto dedicato per gestire tutti i service account. Se il account di servizio del nodo non si trova nel progetto del cluster, gli agenti di servizio nel progetto del cluster non possono creare token o rappresentare il account di servizio. Devi concedere ai service agent nel progetto del cluster i seguenti ruoli sul account di servizio:

  • Creatore token service account (roles/iam.serviceAccountTokenCreator) sul account di servizio all'agente di servizio Compute Engine nel progetto cluster.
  • Utente service account (roles/iam.serviceAccountUser) sul account di servizio all'agente di servizio GKE nel progetto del cluster.

Per ulteriori informazioni, consulta Configurare l'utilizzo del account di servizio nei progetti.

Quando utilizzare un account di servizio specifico

Il tipo di account di servizio che utilizzi dipende dal tipo di identità che vuoi fornire per le tue applicazioni, come segue:

  • Fornisci un'identità da utilizzare nel cluster per i tuoi pod: utilizza un ServiceAccount Kubernetes. Ogni spazio dei nomi Kubernetes ha un default ServiceAccount, ma ti consigliamo di creare nuovi ServiceAccount con privilegi minimi per ogni workload in ogni spazio dei nomi.
  • Fornisci un'identità da utilizzare per i pod al di fuori del cluster: utilizza Workload Identity Federation for GKE. Workload Identity Federation for GKE ti consente di specificare risorse Kubernetes come ServiceAccount come entità nelle norme IAM. Ad esempio, utilizza la federazione delle identità dei carichi di lavoro per GKE quando chiami API come Secret Manager o Spanner dai tuoi pod. Google Cloud
  • Fornisci un'identità predefinita per i tuoi nodi: utilizza un service account IAM personalizzato con privilegi minimi quando crei i cluster o i nodi GKE. Se non utilizzi un account di servizio IAM personalizzato, GKE utilizza il account di servizio Compute Engine predefinito.

Passaggi successivi