Questa pagina mostra come risolvere i problemi relativi alle configurazioni di sicurezza in Autopilot e Standard di Google Kubernetes Engine (GKE) cluster.
Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.RBAC e IAM
Gli account IAM autenticati non riescono a eseguire azioni nel cluster
Il seguente problema si verifica quando provi a eseguire un'azione nel cluster, GKE non riesce a trovare un criterio RBAC che autorizza 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 il
il tentativo di eseguire l'azione. 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, vedi
Autorizzare azioni nei cluster utilizzando il controllo dell'accesso basato sui ruoli.
Federazione delle identità per i carichi di lavoro per GKE
Il pod non può eseguire l'autenticazione in Google Cloud
Se la tua applicazione non è in grado di eseguire l'autenticazione in Google Cloud, assicurati che le seguenti impostazioni siano configurate correttamente:
Verificare di aver abilitato l'account di servizio IAM API Credentials nel progetto contenente il cluster GKE.
Verifica che la federazione delle identità per i carichi di lavoro per GKE sia abilitata nel cluster verificando che ha un pool di identità per i carichi di lavoro impostato:
gcloud container clusters describe CLUSTER_NAME \ --format="value(workloadIdentityConfig.workloadPool)"
Sostituisci
CLUSTER_NAME
con il nome del tuo cluster GKE.Se non hai ancora specificato una zona o una regione predefinite per
gcloud
, potresti anche dover specificare un flag--region
o--zone
quando esegui questo comando.assicurati che il server di metadati GKE sia e configurati 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 tuo pool di nodi.CLUSTER_NAME
con il nome del tuo cluster GKE.
Verifica che l'account di servizio Kubernetes sia annotato correttamente:
kubectl describe serviceaccount \ --namespace NAMESPACE KSA_NAME
Sostituisci quanto segue:
NAMESPACE
con il cluster GKE nello spazio dei nomi.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 un'associazione simile alla seguente:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME] role: roles/iam.workloadIdentityUser
Se hai un criterio di rete cluster, devi consentire il traffico in uscita verso
127.0.0.1/32
sulla porta988
per i cluster che eseguono versioni GKE precedenti alla 1.21.0-gke.1000169.254.169.252/32
sulla porta988
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 verso169.254.169.254/32
sulla porta80
.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 immediatamente ad accedere a una risorsa con la federazione delle identità per i carichi di lavoro per GKE dopo aver aggiunto le associazioni dei 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 di accesso in IAM. il che significa che le modifiche all'accesso, come le concessioni dei ruoli, richiederanno tempo per la propagazione all'interno del 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, valuta la possibilità di aggiungere un ritardo prima che i pod provino a alle risorse Google Cloud dopo la loro 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 hai eseguito il deployment. inclusa la configurazione del logging. Cerca i messaggi di errore che:
- di configurare GOOGLE_APPLICATION_CREDENTIALS oppure
- ti indicherà che le tue richieste a un servizio Google Cloud sono state rifiutate perché la richiesta non aveva 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é 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 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
La federazione delle identità per i carichi di lavoro per GKE non va a buon fine perché il piano di controllo non è disponibile
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.
Una voce di log potrebbe essere simile alla seguente in Esplora log:
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 Scelta di un piano di controllo a livello di regione o zona per scoprire di più sulla disponibilità del piano di controllo. Passaggio a un cluster a livello di regione questo problema.
La federazione delle identità per i carichi di lavoro per l'autenticazione GKE non riesce nei cluster che utilizzano Istio
Se il server di metadati GKE viene bloccato per qualsiasi motivo, La federazione delle identità per i carichi di lavoro per l'autenticazione 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 reindirizzamento:
traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32
Puoi modificare global.proxy.excludeIPRanges
Istio ConfigMap
per fare la stessa cosa.
In alternativa, puoi anche aggiungere la seguente annotazione a livello di pod a tutti carichi di lavoro che utilizzano la federazione delle identità per i carichi di lavoro per GKE, per ritardare l'avvio del container dell'applicazione finché il file collaterale non è pronto:
proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
Puoi modificare global.proxy.holdApplicationUntilProxyStarts
Istio ConfigMap
per fare la stessa cosa.
gke-metadata-server
pod 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
gli account di servizio Kubernetes nel tuo 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 nomikube-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 che ha subito l'arresto anomalo per confermare che la causa era un'esaurimento della memoria eliminazione:
kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled
Sostituisci
POD_NAME
con il nome del pod da verificare.
Per ripristinare la funzionalità nel server di metadati GKE, riduci il o un numero inferiore di account di servizio nel cluster.
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'infrastruttura
Agente di servizio Kubernetes Engine
per facilitare la federazione delle identità per i carichi di lavoro per GKE nei tuoi cluster. Google Cloud automaticamente
concede a questo agente di servizio il ruolo Agente di servizio Kubernetes Engine
(roles/container.serviceAgent
) sul tuo progetto quando abiliti il
l'API Google Kubernetes Engine.
Se provi ad abilitare la federazione delle identità per i carichi di lavoro per GKE sui cluster di un progetto in cui non dispone del ruolo di Agente di servizio Kubernetes Engine, non va a buon fine e viene visualizzato 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 se l'agente di servizio esiste nel progetto e se è 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'intera Identità 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)"
L'output è simile al seguente:
123456789012
Concedi all'agente di servizio il ruolo:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \ --role=roles/container.serviceAgent \ --condition=None
Sostituisci
PROJECT_NUMBER
con il tuo Google Cloud del progetto.Prova ad abilitare di nuovo la federazione delle identità per i carichi di lavoro per GKE.