Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi di autenticazione di Google Distributed Cloud

Questo documento aiuta a risolvere i problemi di autenticazione in Google Distributed Cloud. Vengono fornite informazioni e indicazioni generali per la risoluzione dei problemi, oltre a informazioni specifiche per OpenID Connect (OIDC) e Lightweight Directory Access protocollo (LDAP).

L'autenticazione OIDC e LDAP utilizza il servizio di identità GKE. Prima di poter utilizzare GKE Identity Service con Google Distributed Cloud, devi configurare o il provider di identità. Se non hai configurato un provider di identità per GKE Identity Service, segui le istruzioni per una delle più comuni seguenti fornitori:

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

Risoluzione dei problemi generali

I seguenti suggerimenti per la risoluzione dei problemi possono essere utili per l'autenticazione generale di autorizzazione con Google Distributed Cloud. Se questi problemi non si applicano o in caso di problemi con OIDC o LDAP, passa alla sezione sulla risoluzione dei problemi GKE Identity Service.

Mantieni aggiornato `gcloud anthos auth`

Per evitare molti problemi comuni, verifica che i componenti L'installazione di gcloud anthos auth è aggiornata.

Ci sono due parti che devono essere verificate. gcloud anthos auth ha una logica nel componente principale di Google Cloud CLI, mentre un comando separato componente pacchettizzato anthos-auth.

Per aggiornare Google Cloud CLI:
```
gcloud components update
```
Per aggiornare il componente anthos-auth:
```
gcloud components install anthos-auth
```

Configurazione del provider non valida

Se la configurazione del provider di identità non è valida, verrà visualizzato un errore schermata dal tuo provider di identità dopo aver fatto clic su ACCEDI. Segui le istruzioni specifiche del provider per configurarlo correttamente oppure nel tuo cluster.

Configurazione non valida

Se la console Google Cloud non riesce a leggere la configurazione OIDC dal cluster, Il pulsante ACCESSO sia disabilitato. Risoluzione dei problemi del cluster OIDC consulta la seguente sezione per la risoluzione dei problemi relativi a OIDC in questo documento.

Autorizzazioni non valide

Se completi il flusso di autenticazione, ma ancora non vedi i dettagli di cluster, assicurati di aver concesso all'account le autorizzazioni RBAC corrette utilizzato con OIDC. Potrebbe essere un account diverso da quello che usi per accedere alla console Google Cloud.

Token di aggiornamento mancante

Il seguente problema si verifica quando il server di autorizzazione richiede il consenso. ma il parametro di autenticazione richiesto non è stato fornito.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Per risolvere il problema, aggiungi prompt=consent nella risorsa ClientConfig al campo authentication.oidc.extraParams. Quindi rigenera il client di autenticazione.

Token di aggiornamento scaduto

Il seguente problema si verifica quando il token di aggiornamento nel file kubeconfig ha scaduto:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

Per risolvere il problema, esegui di nuovo il comando gcloud anthos auth login.

L'accesso gcloud anthos auth non va a buon fine e: `proxyconnect tcp`

Questo problema si verifica quando si verifica un errore in https_proxy o HTTPS_PROXY configurazioni variabile di ambiente. Se c'è un valore https:// specificato in variabili di ambiente, le librerie client HTTP di GoLang potrebbero generare errori se è configurato per gestire le connessioni HTTPS utilizzando altri protocolli come CALZIO5.

Potrebbe essere restituito il seguente messaggio di errore di esempio:

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

Per risolvere il problema, modifica gli ambienti https_proxy e HTTPS_PROXY per omettere https:// prefix. Su Windows, modifica il sistema variabili di ambiente. Ad esempio, modifica il valore dell'attributo 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 utente. Ciò può accadere se gli RBAC appropriati mancano o sono errati oppure si è verificato un errore nella configurazione OIDC per il cluster. Le seguenti potrebbe essere visualizzato un esempio di errore:

Unauthorized

Per risolvere il problema, completa i seguenti passaggi:

Nel file kubeconfig generato da gcloud anthos auth login, copia valore di id-token.

kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

Installa jwt-cli ed esegui:
```
jwt ID_TOKEN
```
Verifica la configurazione OIDC.

La risorsa ClientConfig contiene i campi group e username. Questi vengono utilizzati per impostare --oidc-group-claim e --oidc-username-claim nel server API Kubernetes. Quando al server API viene presentata automaticamente il token, lo inoltra al servizio di identità GKE, che restituisce ha estratto group-claim e username-claim di nuovo al server API. L'API server utilizza la risposta per verificare che il gruppo o l'utente corrispondente abbia le autorizzazioni corrette.

Verifica che le rivendicazioni impostate per group e user in ClientConfig risorse sono presenti nel token ID.
Controlla gli RBAC applicati.

Verifica che esista un RBAC con le autorizzazioni corrette per l'utente specificato da username-claim o da uno dei gruppi elencati group-claim da al passaggio precedente. Il nome dell'utente o del gruppo in RBAC deve essere con prefisso usernameprefix o groupprefix specificato in ClientConfig risorsa.

Se usernameprefix è vuoto e username è un valore diverso da email, il prefisso è sempre issuerurl#. Per disattivare i prefissi nome utente, imposta Da usernameprefix a -.

Per ulteriori informazioni sui prefissi utente e di gruppo, consulta Autenticazione con OIDC.

Nota: il server API Kubernetes tratta una barra rovesciata come carattere di escape. Se il nome dell'utente o del gruppo contiene \\, l'API il server lo legge come un singolo \ durante l'analisi del token ID. Di conseguenza, l'associazione del ruolo RBAC applicata a questo utente o gruppo deve contengono una singola barra rovesciata o potresti visualizzare un errore Unauthorized.

ClientConfig risorsa:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
Token ID:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
Le seguenti associazioni RBAC concedono a questo gruppo e all'utente pod-reader nel tuo cluster GKE. Nota la singola barra nel campo del nome anziché una doppia barra:

ClusterRoleBinding del gruppo:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Utente ClusterRoleBinding:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Controlla i log del server API Kubernetes.

Se il plug-in OIDC configurato nel server API Kubernetes non si avvia correttamente, il server API restituisce un errore Unauthorized quando viene visualizzato con il token ID. Per verificare se si sono verificati problemi con il plug-in OIDC in il server API, esegui:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Sostituisci quanto segue:
- USER_CLUSTER_NAME: il nome del cluster utente da utilizzare visualizza i log.
- ADMIN_CLUSTER_KUBECONFIG: il cluster di amministrazione kubeconfig.

Risolvere i problemi relativi a OIDC

Quando l'autenticazione OIDC non funziona per Google Distributed Cloud, in genere il servizio la specifica nella risorsa ClientConfig non è stata configurata correttamente. La risorsa ClientConfig fornisce istruzioni per esaminare i log e Specifica OIDC per identificare la causa di un problema OIDC.

Esamina il Guida alla risoluzione dei problemi relativi al provider di identità del servizio di identità GKE per informazioni su come abilitare e rivedere i log delle identità e testare la connettività. Dopo aver confermato che il servizio di identità GKE funziona come previsto Identifica un problema, esamina le seguenti informazioni per la risoluzione dei problemi OIDC.

Controlla la specifica OIDC nel cluster

Le informazioni OIDC per il cluster sono specificate nella sezione ClientConfig nello spazio dei nomi kube-public.

Utilizza kubectl get per stampare la risorsa OIDC per il cluster utente:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.
Esamina i valori dei campi per verificare che la specifica sia configurata correttamente per il provider OIDC.
Se identifichi un problema di configurazione nella specifica, riconfigurare OIDC.
Se non riesci a diagnosticare e risolvere autonomamente il problema, contattare l'assistenza Google Cloud.

L'assistenza Google Cloud richiede Log di GKE Identity Service e la specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Verifica che l'autenticazione OIDC sia abilitata

Prima di testare l'autenticazione OIDC, verifica che sia abilitata nel tuo cluster.

Esamina i log di GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
L'output di esempio seguente mostra che l'autenticazione OIDC è corretta attivato:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Se l'autenticazione OIDC non è abilitata correttamente, vengono rilevati errori simili i seguenti esempi:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Esamina gli errori specifici segnalati e prova a correggerli.

Testa l'autenticazione OIDC

Per utilizzare la funzionalità OIDC, utilizza una workstation con l'interfaccia utente e il browser abilitati. Tu non possono eseguire questi passaggi da una sessione SSH basata su testo. Per verificare che OIDC funzioni correttamente nel cluster, completa i seguenti passaggi:

Scarica con Google Cloud CLI.
Per generare il file di configurazione dell'accesso, esegui questo comando gcloud anthos create-login-config :
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.
Per autenticare l'utente, esegui questo comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster utente su connettersi.
- AUTH_KUBECONFIG con il nuovo file kubeconfig da creare che include le credenziali per accedere al cluster. Per ulteriori informazioni le informazioni, vedi Esegui l'autenticazione nel cluster.
Dovresti ricevere una pagina per il consenso di accesso aperta nel browser web predefinito di dalla workstation locale. Fornisci informazioni di autenticazione valide per un utente in questa richiesta di accesso.

Dopo aver completato correttamente il passaggio di accesso precedente, verrà visualizzato un file kubeconfig viene generato nella directory corrente.
Per testare il nuovo file kubeconfig che include le tue credenziali, elenca i pod nel tuo cluster utente:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Sostituisci AUTH_KUBECONFIG con il percorso del nuovo kubeconfig generato nel passaggio precedente.

Potrebbe essere restituito il seguente messaggio di esempio che mostra che puoi l'autenticazione è riuscita, ma non sono presenti controlli di accesso basati sui ruoli (RBAC, Role-Based Access Control) assegnati all'account:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Esamina i log di autenticazione OIDC

Se non riesci ad eseguire l'autenticazione con OIDC, i log di GKE Identity Service forniscono le informazioni più pertinenti e utili per il debug del problema.

Utilizza kubectl logs per stampare i log di GKE Identity Service:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.
Esamina i log per individuare errori che possono aiutarti a diagnosticare i problemi OIDC.

Ad esempio, la risorsa ClientConfig potrebbe contenere un errore di battitura in issuerURL campo, come htps://accounts.google.com (t mancante in https). La I log di GKE Identity Service contengono una voce simile alla seguente esempio:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Se identifichi un problema di configurazione nei log, Riconfigura OIDC e correggere i problemi di configurazione.
Se non riesci a diagnosticare e risolvere autonomamente il problema, contatta l'assistenza Google Cloud. L'assistenza Google Cloud richiede i log di GKE Identity Service e Specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Problemi OIDC comuni

In caso di problemi con l'autenticazione OIDC, consulta i seguenti suggerimenti che le applicazioni presentino problemi di prestazioni. Segui le indicazioni per risolvere il problema.

Nessun endpoint disponibile per il servizio "ais"

Quando salvi la risorsa ClientConfig, viene visualizzato il seguente messaggio di errore restituito:

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

Questo errore è causato dall'endpoint in stato non integro di GKE Identity Service. La Il pod del servizio di identità GKE non è in grado di gestire il webhook di convalida.

Per verificare che il pod del servizio di identità GKE sia in stato non integro, esegui seguente comando:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.

L'output di esempio seguente indica che il pod GKE Identity Service è arresto anomalo:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Per capire perché il pod ha un problema, esamina gli eventi del pod:

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

Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.

L'output di esempio seguente segnala un errore di autorizzazione durante il pull del immagine:

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

Se gli eventi del pod segnalano un problema, continua con la risoluzione dei problemi nel in queste aree. Se hai bisogno di ulteriore assistenza, contatta l'assistenza Google Cloud.

Errore durante la lettura dei byte di risposta dal server

Nei log di GKE Identity Service potresti notare i seguenti errori:

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

Questi errori di rete potrebbero essere visualizzati nei log in uno dei seguenti modi:

Appaiono raramente nel log: è probabile che gli errori di riserva non siano il problema principale. e potrebbero verificarsi problemi di rete intermittenti.

Il plug-in OIDC di GKE Identity Service ha un processo daemon sincronizza periodicamente l'URL di rilevamento OIDC ogni 5 secondi. Se connessione di rete non è stabile, questa richiesta in uscita potrebbe non riuscire. Occasionalmente l'errore non influisce sull'autenticazione OIDC. I dati esistenti memorizzati nella cache possono essere riutilizzate.

Se si verificano errori di riserva nei log, continua con altri passaggi per la risoluzione dei problemi.
Appaiono sempre nel log oppure il servizio di identità GKE non è mai raggiunge correttamente l'endpoint noto: questi problemi continui indicare un problema di connettività tra il servizio di identità GKE e il tuo file OIDC o il provider di identità.

I seguenti passaggi per la risoluzione dei problemi possono aiutare a diagnosticare questa connettività. problemi:
1. Assicurati che un firewall non stia bloccando le richieste in uscita GKE Identity Service.
2. Verifica che il server del provider di identità funzioni correttamente.
3. Verifica che l'URL dell'emittente OIDC nella risorsa ClientConfig sia configurato correttamente.
4. Se hai abilitato il campo del proxy nella risorsa ClientConfig, esamina il o il log del server proxy in uscita.
5. Testa la connettività tra il tuo pod GKE Identity Service e il server del provider di identità OIDC.

Devi aver eseguito l'accesso al server (non autorizzato)

Quando provi ad accedere utilizzando l'autenticazione OIDC, potresti ricevere messaggio di errore seguente:

  You must be logged in to the server (Unauthorized)

Questo errore è un problema generale di autenticazione Kubernetes che non restituisce ulteriori informazioni. Tuttavia, questo errore indica una configurazione problema.

Per determinare il problema, rivedi le sezioni precedenti per Controlla la specifica OIDC nel cluster e Configura la risorsa ClientConfig.

Impossibile effettuare la richiesta di autenticazione webhook

Nei log di GKE Identity Service, potresti visualizzare il seguente errore:

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

Questo errore indica che il server API non è in grado di stabilire la connessione con il pod di GKE Identity Service.

Per verificare se l'endpoint del servizio di identità GKE può essere raggiunto dal all'esterno, esegui questo comando curl:
```
curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
Sostituisci APISERVER_HOST con l'indirizzo dell'API o server web.

La risposta prevista è un codice di stato HTTP 400. Se la richiesta è scaduta, riavvia il pod di GKE Identity Service. Se l'errore persiste, significa che il server HTTP di GKE Identity Service non si avvia. Per ulteriori assistenza, contatta l'assistenza Google Cloud.

URL di accesso non trovato

Il seguente problema si verifica quando la console Google Cloud non riesce a raggiungere l'identità o il provider di servizi di terze parti. Un tentativo di accesso viene reindirizzato a una pagina con URL not found .

Per risolvere il problema, segui la procedura di risoluzione dei problemi riportata di seguito. Dopo ogni passaggio, prova ad accedere di nuovo:

Se il provider di identità non è raggiungibile sulla rete internet pubblica, attiva il Proxy HTTP OIDC per accedere utilizzando la console Google Cloud. Modifica ClientConfig risorsa personalizzata e imposta useHTTPProxy su true:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del tuo del cluster utente kubeconfig.
Se il proxy HTTP è abilitato, ma continui a riscontrare questo errore, è possibile potrebbe verificarsi un problema all'avvio del proxy. Visualizza i log del proxy:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del tuo del cluster utente kubeconfig.

Anche se il tuo provider di identità ha una CA nota, devi fornire un valore per oidc.caPath nella tua risorsa personalizzata ClientConfig affinché il proxy HTTP l'avvio riuscito.
Se il server di autorizzazione richiede il consenso e non hai incluso i parametri extraparam prompt=consent, modifica il parametro ClientConfig personalizzato risorsa e aggiungi prompt=consent ai parametri extraparams:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del tuo del cluster utente kubeconfig.
Se le impostazioni di configurazione vengono modificate nel servizio di archiviazione, potrebbe essere necessario uscire esplicitamente dalle sessioni esistenti. Nella console Google Cloud, vai a nella pagina dei dettagli del cluster e seleziona Esci.

Risolvere i problemi relativi a LDAP

In caso di problemi con l'autenticazione LDAP, assicurati di aver configurato per l'ambiente seguendo uno dei documenti di configurazione appropriati:

Devi inoltre assicurarti di Inserire il secret dell'account di servizio LDAP e hanno ha configurato la risorsa ClientConfig per abilitare l'autenticazione LDAP.

Verificare che l'autenticazione LDAP sia attiva

Prima di testare l'autenticazione LDAP, verifica che sia attiva nel tuo cluster.

Esamina i log di GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
L'output di esempio seguente mostra che l'autenticazione LDAP è corretta attivato:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Se l'autenticazione LDAP non è abilitata correttamente, vengono visualizzati errori simili i seguenti esempi:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Esamina gli errori specifici segnalati e prova a correggerli.

Testare l'autenticazione LDAP

Per utilizzare la funzionalità LDAP, utilizza una workstation con la UI e il browser abilitati. Tu non possono eseguire questi passaggi da una sessione SSH basata su testo. Per testare il protocollo LDAP che l'autenticazione funzioni correttamente nel cluster, completa i seguenti passaggi:

Scarica con Google Cloud CLI.
Per generare il file di configurazione dell'accesso, esegui questo comando gcloud anthos create-login-config :
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Sostituisci KUBECONFIG con il percorso del cluster utente kubeconfig.
Per autenticare l'utente, esegui questo comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Sostituisci quanto segue:
- CLUSTER_NAME con il nome del cluster utente su connettersi.
- AUTH_KUBECONFIG con il nuovo file kubeconfig su che includa le credenziali per accedere al cluster. Per ulteriori informazioni le informazioni, vedi Esegui l'autenticazione nel cluster.
Dovresti ricevere una pagina per il consenso di accesso aperta nel browser web predefinito di dalla workstation locale. Fornisci informazioni di autenticazione valide per un utente in questa richiesta di accesso.

Dopo aver completato correttamente il passaggio di accesso precedente, verrà visualizzato un file kubeconfig viene generato nella directory corrente.
Per testare il nuovo file kubeconfig che include le tue credenziali, elenca i pod nel tuo cluster utente:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Sostituisci AUTH_KUBECONFIG con il percorso del cluster utente kubeconfig generato nel passaggio precedente.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Problemi comuni relativi a LDAP

In caso di problemi con l'autenticazione LDAP, consulta le seguenti risorse comuni che le applicazioni presentino problemi di prestazioni. Segui le indicazioni per risolvere il problema.

Gli utenti non possono autenticarsi con le virgole nel loro CN

Quando utilizzi LDAP, potresti riscontrare problemi quando gli utenti non possono eseguire l'autenticazione se il loro CN contiene una virgola, come CN="a,b". Se attivi il log di debug per GKE Identity Service, viene segnalato il seguente messaggio di errore:

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

Questo problema si verifica perché il plug-in LDAP del servizio di identità GKE è doppio fa precedere da una sequenza di escape la virgola. Questo problema si verifica solo nelle versioni Google Distributed Cloud 1.13 e in precedenza.

Per risolvere il problema, completa uno dei seguenti passaggi:

Esegui l'upgrade del cluster a Google Distributed Cloud 1.13 o versioni successive.
Scegli un altro identifierAttribute, ad esempio sAMAccountName, di utilizzare la CN.
Rimuovi le virgole dall'interno del CN nella directory LDAP.

Errore di autenticazione con Google Cloud CLI 1.4.2

Con Google Cloud CLI anthos-auth 1.4.2, potresti visualizzare il seguente errore quando esegui il comando gcloud anthos auth login:

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

Nel log di GKE Identity Service, vedrai anche il seguente errore:

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

Per risolvere questo errore, completa i seguenti passaggi:

Controlla se utilizzi Google Cloud CLI anthos-auth versione 1.4.2:
```
gcloud anthos auth version
```
L'output di esempio seguente mostra che la versione è 1.4.2:
```
Current Version: v1.4.2
```
Se esegui Google Cloud CLI anthos-auth versione 1.4.2, esegui l'upgrade a versione 1.4.3 o successiva.

Passaggi successivi