Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvere i problemi di autenticazione di GKE

Autopilot Standard

Questa pagina mostra come risolvere i problemi relativi alle configurazioni di sicurezza nei cluster Autopilot e standard di Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

RBAC e IAM

Gli account IAM autenticati non riescono a eseguire azioni all'interno del cluster

Il seguente problema si verifica quando provi a eseguire un'azione nel cluster, ma GKE non riesce a trovare un criterio RBAC che autorizzi l'azione. GKE tenta di trovare un criterio di autorizzazione IAM concede la stessa autorizzazione. Se il problema persiste, viene visualizzato un messaggio di errore simile a le seguenti:

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).

Per risolvere il problema, utilizza un criterio RBAC per concedere le autorizzazioni per l'azione tentata. Ad esempio, per risolvere il problema nell'esempio precedente, concedi un ruolo con l'autorizzazione list per gli oggetti roles in kube-system nello spazio dei nomi. Per istruzioni, consulta Autorizzare le azioni nei cluster utilizzando il controllo dell'accesso basato sui ruoli.

Federazione delle identità per i carichi di lavoro per GKE

Il pod non riesce ad autenticarsi su Google Cloud

Se la tua applicazione non è in grado di eseguire l'autenticazione in Google Cloud, assicurati che le seguenti impostazioni siano configurate correttamente:

Verifica di aver attivato l'API Credentials degli account di servizio IAM nel progetto contenente il cluster GKE.

Attiva API IAM Credentials
Verifica che la federazione delle identità per i carichi di lavoro per GKE sia abilitata nel cluster verificando che sia impostato un pool di identità per i carichi di lavoro:
```
gcloud container clusters describe CLUSTER_NAME \
    --format="value(workloadIdentityConfig.workloadPool)"
```
Sostituisci CLUSTER_NAME con il nome del cluster GKE.

Se non hai già specificato una zona o una regione predefinita per gcloud, potresti anche dover specificare un flag --region o --zone quando esegui questo comando.
Assicurati che il server metadati GKE sia configurato nel pool di nodi in cui è in esecuzione l'applicazione:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Sostituisci quanto segue:
- NODEPOOL_NAME con il nome del pool di nodi.
- CLUSTER_NAME con il nome del cluster GKE.
Verifica che l'account di servizio Kubernetes sia annotato correttamente:
```
kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME
```
Sostituisci quanto segue:
- NAMESPACE con lo spazio dei nomi del tuo cluster GKE.
- KSA con il nome del tuo account di servizio Kubernetes.
L'output previsto contiene un'annotazione simile alla seguente:
```
iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```

Verifica che l'account di servizio IAM sia configurato correttamente:

gcloud iam service-accounts get-iam-policy \
    GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

L'output previsto contiene una associazione simile alla seguente:

- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

Se hai un criterio di rete del cluster, devi consentire l'uscita su 127.0.0.1/32 sulla porta 988 per i cluster che eseguono versioni di GKE precedenti alla 1.21.0-gke.1000 o su 169.254.169.252/32 sulla porta 988 per i cluster che eseguono GKE versione 1.21.0-gke.1000 e successive. Per i cluster che eseguono GKE Dataplane V2, devi consentire il traffico in uscita verso 169.254.169.254/32 sulla porta 80.
```
kubectl describe networkpolicy NETWORK_POLICY_NAME
```
Sostituisci NETWORK_POLICY_NAME con il nome del tuo criterio di rete GKE.

Accesso all'account di servizio IAM negato

I pod potrebbero non riuscire ad accedere a una risorsa con la federazione delle identità per i carichi di lavoro per GKE immediatamente dopo aver aggiunto le associazioni di ruoli IAM. Un errore di accesso ha maggiori probabilità avvengono nelle pipeline di deployment o nelle configurazioni dichiarative di Google Cloud. in cui risorse come IAM consentono i criteri, le associazioni di ruoli I pod Kubernetes vengono creati insieme. Il seguente messaggio di errore nei log dei pod:

HTTP/403: generic::permission_denied: loading: GenerateAccessToken("SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com", ""): googleapi: Error 403: Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).

Questo errore potrebbe essere causato dalla propagazione delle modifiche dell'accesso in IAM, il che significa che le modifiche dell'accesso come le concessioni dei ruoli richiedono tempo per essere propagate nel sistema. Per le concessioni di ruoli, la propagazione richiede in genere circa due minuti, ma a volte potrebbero essere necessari almeno sette minuti. Per ulteriori dettagli, vedi Propagazione delle modifiche dell'accesso.

Per risolvere questo errore, ti consigliamo di aggiungere un ritardo prima che i pod provino ad accedere alle risorse Google Cloud dopo la creazione.

Problemi di risoluzione DNS

Alcune librerie client di Google Cloud sono configurate per la connessione i server di metadati GKE e Compute Engine risolvendo il problema DNS nome metadata.google.internal; per queste librerie, il DNS nel cluster è integro è una dipendenza critica per l'autenticazione dei carichi di lavoro servizi Google Cloud.

Il modo in cui rilevi questo problema dipende dai dettagli dell'applicazione di cui è stato eseguito il deployment, incluso il relativo logging. Cerca messaggi di errore che:

ti chiede di configurare GOOGLE_APPLICATION_CREDENTIALS oppure
ti comunica che le tue richieste a un servizio Google Cloud sono state rifiutate perché non contenevano credenziali.

Se riscontri problemi con la risoluzione DNS di metadata.google.internal, alcune librerie client di Google Cloud possono saltare la risoluzione DNS imposta la variabile di ambiente GCE_METADATA_HOST su 169.254.169.254:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: default
spec:
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    env:
    - name: GCE_METADATA_HOST
      value: "169.254.169.254"

Si tratta dell'indirizzo IP hardcoded a cui il servizio di metadati viene sempre disponibili sulle piattaforme Google Cloud Compute.

Librerie Google Cloud supportate:

Python
Java
Node.js
Golang (tieni presente, tuttavia, che la libreria client Golang preferisce già connettersi tramite IP anziché tramite nome DNS).

Errori di timeout all'avvio del pod

Il server di metadati GKE ha bisogno di alcuni secondi prima di poter essere avviato accettare richieste su un nuovo pod. Tenta di eseguire l'autenticazione utilizzando La federazione delle identità per i carichi di lavoro per GKE potrebbe non riuscire entro i primi secondi di vita di un pod e librerie client di Google Cloud configurate con un breve timeout.

In caso di errori di timeout, prova a procedere nel seguente modo:

Aggiorna le librerie client di Google Cloud utilizzate dai tuoi carichi di lavoro.
Modifica il codice dell'applicazione in attesa di qualche secondo e riprova.

Esegui il deployment di un'istanza initContainer attende che il server di metadati GKE sia pronto prima di essere eseguito dal container principale del pod.

Ad esempio, il seguente manifest è per un pod con un initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: KSA_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Workload Identity Federation for GKE non riesce a causa della mancata disponibilità del control plane

Il server metadati non può restituire la federazione delle identità per i carichi di lavoro per GKE quando il cluster Il piano di controllo non è disponibile. Le chiamate al server dei metadati restituiscono il codice di stato 500.

In Esplora log, una voce di log potrebbe essere simile alla seguente:

dial tcp 35.232.136.58:443: connect: connection refused

Questo comportamento porta all'indisponibilità della federazione delle identità per i carichi di lavoro per GKE.

Il piano di controllo potrebbe non essere disponibile sui cluster di zona durante la manutenzione del cluster come la rotazione di IP, l'upgrade delle VM del piano di controllo o il ridimensionamento di cluster o pool di nodi. Consulta Scegliere un piano di controllo regionale o zonale per informazioni sulla disponibilità del piano di controllo. Il passaggio a un cluster regionale elimina questo problema.

L'autenticazione di Workload Identity Federation per GKE non va a buon fine nei cluster che utilizzano Istio

Se il server dei metadati GKE è bloccato per qualsiasi motivo, l'autenticazione di Workload Identity Federation for GKE non va a buon fine.

Se utilizzi Istio o Cloud Service Mesh, aggiungi la seguente annotazione a livello di pod a tutti i carichi di lavoro che utilizzano la federazione delle identità per i carichi di lavoro per GKE per escludere l'IP dal reindirizzamento:

traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32

Puoi modificare la chiave global.proxy.excludeIPRanges ConfigMap Istio per fare lo stesso.

In alternativa, puoi anche aggiungere la seguente annotazione a livello di pod a tutti i carichi di lavoro che utilizzano la federazione delle identità per i carichi di lavoro per GKE per ritardare l'avvio del contenitore dell'applicazione fino al momento in cui il sidecar è pronto:

proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

Puoi modificare global.proxy.holdApplicationUntilProxyStarts Istio ConfigMap per fare la stessa cosa.

Il pod `gke-metadata-server` si arresta in modo anomalo

Il pod DaemonSet del sistema gke-metadata-server facilita la federazione delle identità per i carichi di lavoro per GKE sui nodi. Il pod utilizza risorse di memoria proporzionali al numero di account di servizio Kubernetes nel cluster.

Il seguente problema si verifica quando l'utilizzo delle risorse dell'gke-metadata-server il pod supera i propri limiti. Il kubelet rimuove il pod con un errore di memoria insufficiente. Questo potrebbe essere il problema se il tuo cluster ha più di 3000 account di servizio.

Per identificare il problema:

Trova i pod gke-metadata-server con arresto anomalo nello spazio dei nomi kube-system:

kubectl get pods -n=kube-system | grep CrashLoopBackOff

L'output è simile al seguente:

NAMESPACE     NAME                        READY     STATUS             RESTARTS   AGE
kube-system   gke-metadata-server-8sm2l   0/1       CrashLoopBackOff   194        16h
kube-system   gke-metadata-server-hfs6l   0/1       CrashLoopBackOff   1369       111d
kube-system   gke-metadata-server-hvtzn   0/1       CrashLoopBackOff   669        111d
kube-system   gke-metadata-server-swhbb   0/1       CrashLoopBackOff   30         136m
kube-system   gke-metadata-server-x4bl4   0/1       CrashLoopBackOff   7          15m

Descrivi il pod in crash per confermare che la causa è stata un'espulsione per esaurimento della memoria:
```
kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled
```
Sostituisci POD_NAME con il nome del pod da controllare.

Per ripristinare la funzionalità del server metadati GKE, riduci il numero di account di servizio nel cluster a meno di 3000.

L'abilitazione della federazione delle identità per i carichi di lavoro per GKE non riesce a causa del messaggio di errore DeployPatch non riuscito

GKE utilizza l'agente di servizio Kubernetes Engine gestito da Google Cloud per semplificare la federazione delle identità per i carichi di lavoro per GKE nei tuoi cluster. Google Cloud esegue automaticamente concede a questo agente di servizio il ruolo Agente di servizio Kubernetes Engine (roles/container.serviceAgent) sul tuo progetto quando abiliti l'API Google Kubernetes Engine.

Se provi ad attivare la federazione delle identità per i carichi di lavoro per GKE sui cluster di un progetto in cui l'agente di servizio non dispone del ruolo Agente di servizio Kubernetes Engine, l'operazione non va a buon fine con un messaggio di errore simile al seguente:

Error waiting for updating GKE cluster workload identity config: DeployPatch failed

Per risolvere il problema, prova a procedere nel seguente modo:

Verifica che l'agente di servizio esista nel progetto e sia configurato correttamente:
```
gcloud projects get-iam-policy PROJECT_ID \
    --flatten=bindings \
    --filter=bindings.role=roles/container.serviceAgent \
    --format="value[delimiter='\\n'](bindings.members)"
```
Sostituisci PROJECT_ID con il tuo Google Cloud dell'ID progetto.

Se l'agente di servizio è configurato correttamente, l'output mostra l'identità completa dell'agente di servizio:
```
serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
```
Se l'output non mostra l'agente di servizio, devi concedere l'accesso Agente di servizio Kubernetes Engine. Per concedere questo ruolo, completa la i seguenti passaggi.

Ottieni il numero del tuo progetto Google Cloud:

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