Risolvere i problemi di accesso degli utenti

Questo documento fornisce indicazioni per la risoluzione dei problemi di accesso degli utenti quando utilizzi provider di identità di terze parti per l'autenticazione ai cluster membri del parco risorse.

gcloud anthos create-login-config non riesce a recuperare clientconfig

Questo problema si verifica in uno dei seguenti casi:

  • Il file kubeconfig passato a gcloud anthos create-login-config non è corretto.
  • La risorsa personalizzata ClientConfig non è presente nel cluster (l'autenticazione di terze parti non è configurata nel cluster).

Messaggio di errore

  failed to get clientconfig default in namespace kube-public

Soluzione

Per risolvere il problema, segui questi passaggi:

  1. Assicurati di avere il file kubeconfig corretto per il tuo cluster.

  2. Per verificare se la risorsa personalizzata ClientConfig è presente nel cluster, esegui il comando seguente:

    kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public

    Se ClientConfig non è presente nel cluster, installa e configura ClientConfig nel cluster. Per ulteriori informazioni sulle opzioni di configurazione del cluster, consulta Opzioni di configurazione per i cluster.

gcloud anthos create-login-config non riesce a causa di un nome cluster duplicato

Questo problema si verifica se tenti di creare una configurazione di accesso per un cluster in un file che contiene già una configurazione di accesso per questo cluster.

Messaggio di errore

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.

Soluzione

Per risolvere il problema, utilizza il flag --output per specificare un nuovo file di destinazione.

Se non fornisci --output, questi dati di configurazione di accesso vengono scritti in un file denominato kubectl-anthos-config.yaml nella directory corrente.

gcloud anthos auth login non riesce con proxyconnect tcp

Questo problema si verifica quando si verifica un errore nelle configurazioni variabile di ambiente https_proxy o HTTPS_PROXY. Se nelle variabili di ambiente è specificato https://, le librerie client HTTP GoLang potrebbero non riuscire se il proxy è configurato per gestire le connessioni HTTPS utilizzando altri protocolli come SOCK5.

Messaggio di errore

  proxyconnect tcp: tls: first record does not look like a TLS handshake

Soluzione

Per risolvere il problema, modifica le variabili di ambiente https_proxy e HTTPS_PROXY per omettere https:// prefix. In Windows, modifica le variabili di ambiente di sistema. Ad esempio, modifica il valore della https_proxy variabile di ambiente da https://webproxy.example.com:8000 a webproxy.example.com:8000.

L'accesso al cluster non riesce quando si utilizza kubeconfig generato da gcloud anthos auth login

Questo problema si verifica quando il server API Kubernetes non è in grado di autorizzare l'utente per uno dei seguenti motivi:

  • Si è verificato un errore nella configurazione utilizzata per accedere con il comando gcloud anthos auth login.
  • I criteri RBAC necessari non sono corretti o mancano per l'utente.

Messaggio di errore

  Unauthorized

Soluzione

Per risolvere il problema, segui questi passaggi:

  1. Verifica la configurazione utilizzata per l'accesso.

    Configurazione OIDC

    La sezione authentication.oidc nel file di configurazione del cluster utente contiene i campi group e username utilizzati per impostare i flag --oidc-group-claim e --oidc-username-claim nel server API Kubernetes. Quando al server API viene presentato il token di identità di un utente, il token viene inoltrato al cluster, che restituisce al server API i valori group-claim e username-claim estratti. Il server API utilizza la risposta per verificare che il gruppo o l'utente corrispondente disponga delle autorizzazioni corrette.

    Verifica che le attestazioni impostate per group e user nella sezione authentication.oidc del file di configurazione del cluster siano presenti nel token ID.

  2. Verifica i criteri RBAC applicati.

    Per scoprire come configurare i criteri RBAC corretti, consulta Configurare il controllo dell'accesso basato sui ruoli (RBAC).

RBAC per i gruppi che non funzionano per Google Gruppi

  1. Assicurati che il parco risorse o il cluster sia configurato per l'autenticazione di terze parti.

    Segui i passaggi di configurazione per assicurarti che l'autenticazione di terze parti sia configurata e abilitata.

  2. Assicurati di aver configurato correttamente i gruppi Google Workspace:

RBAC per i gruppi che non funzionano per i provider OIDC

  1. Verifica se il token ID contiene le informazioni del gruppo

    Dopo aver eseguito il comando gcloud anthos auth login per avviare il flusso di autenticazione OIDC, il token ID viene archiviato nel file kubeconfig nel campo id-token. Utilizza jwt.io per decodificare il token ID e verificare se contiene le informazioni del gruppo dell'utente come previsto.

  2. Se il token ID non contiene le informazioni del gruppo dell'utente, configura correttamente il provider OIDC in modo che restituisca le informazioni del gruppo in base alla documentazione del provider OIDC. Ad esempio, se utilizzi la configurazione OIDC del provider di identità Okta, segui la documentazione del provider di identità Okta per configurare i gruppi nel token ID.

  3. Se il token ID contiene le informazioni del gruppo, verifica se la chiave delle informazioni del gruppo nel token ID corrisponde al campo groupsClaim configurato nella sezione oidc.

    Ad esempio, se il token ID contiene le informazioni del gruppo nella chiave groups:

    "groups" : ["group1", "group2" ...]

    allora il valore del campo groupsClaim deve essere groups nella sezione oidc.

    Dopo aver modificato la configurazione nella sezione oidc, assicurati di eseguire le istruzioni elencate in Configurare l'accesso degli utenti e Accedere di nuovo ai cluster.

Risolvere i problemi dei provider di identità

Se hai problemi a utilizzare OIDC o LDAP con il tuo cluster, segui i passaggi descritti in questa sezione per risolvere questi problemi e determinare se si è verificato un problema con la configurazione del provider di identità.

Abilitare il log di debug

Per risolvere i problemi relativi all'identità nel cluster, abilita i log di debug per i pod nel deployment ais.

  1. Applica la patch al cluster esistente con kubectl patch:

    kubectl patch deployment ais \
  -n anthos-identity-service --type=json \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
  --kubeconfig KUBECONFIG

    Sostituisci quanto segue:

    • LOG_LEVEL: per i log più dettagliati, imposta questo valore sul livello 3 durante la risoluzione dei problemi.

    • KUBECONFIG: il percorso del file kubeconfig del cluster utente.

Controllare il log del container

Esamina il contenuto dei log dei container per verificare la presenza di errori o avvisi.

  1. Per esaminare i log, utilizza kubectl logs:

    kubectl logs -f -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster utente.

Riavviare il pod

Se i log dei container mostrano problemi, riavvia il pod.

  1. Per riavviare il pod, elimina il pod esistente. Viene creato automaticamente un nuovo pod in sostituzione.

    kubectl delete pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster utente.

Risolvere i problemi di connettività al provider di identità

Se il pod sembra essere in esecuzione correttamente, testa la connettività al provider di identità remoto.

  1. Avvia un pod busybox nello stesso spazio dei nomi:

    kubectl run curl --image=radial/busyboxplus:curl \
  -n anthos-identity-service -- sleep 3000 \
  --kubeconfig KUBECONFIG

    Sostituisci KUBECONFIG con il percorso del file kubeconfig del cluster utente.

  2. Per verificare se puoi recuperare l'URL di rilevamento, esegui il pod busybox ed esegui il comando curl:

    kubectl exec pod/curl -n anthos-identity-service -- \
  curl ISSUER_URL \
  --kubeconfig KUBECONFIG

    Sostituisci quanto segue:

    • ISSUER_URL: l'URL dell'emittente del provider di identità.
    • KUBECONFIG: il percorso del file kubeconfig del cluster utente.

    Una risposta positiva è un risultato JSON con gli endpoint dettagliati del provider di identità.

  3. Se il comando precedente non restituisce il risultato previsto, contatta l'amministratore del provider di identità per ulteriore assistenza.

L'accesso LDAP non funziona per il cluster di amministrazione di Google Distributed Cloud

Al momento, LDAP è supportato solo per il cluster utente di Google Distributed Cloud.