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 Protocol (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 un provider di identità. Se non hai configurato un provider di identità per GKE Identity Service, segui le istruzioni per uno dei seguenti provider più comuni:

Consulta la guida alla risoluzione dei problemi relativi al provider di identità del servizio di identità GKE per informazioni su come abilitare ed esaminare i log di identità e testare la connettività.

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

Risoluzione dei problemi generali

I seguenti suggerimenti per la risoluzione dei problemi possono aiutarti a risolvere i problemi di autenticazione e autorizzazione generali con Google Distributed Cloud. Se questi problemi non si applicano o se hai problemi con OIDC o LDAP, passa alla sezione relativa alla risoluzione dei problemi di GKE Identity Service.

Mantieni aggiornato gcloud anthos auth

Per evitare molti problemi comuni, verifica che i componenti dell'installazione di gcloud anthos auth siano aggiornati.

Ci sono due parti che devono essere verificate. Il comando gcloud anthos auth ha una logica nel componente principale di Google Cloud CLI e un componente anthos-auth in pacchetti separati.

  1. Per aggiornare Google Cloud CLI:

    gcloud components update

  2. 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, dopo aver fatto clic su Accedi verrà visualizzata una schermata di errore del provider di identità. Segui le istruzioni specifiche del provider per configurare correttamente il provider o il cluster.

Configurazione non valida

Se la console Google Cloud non riesce a leggere la configurazione OIDC dal cluster, il pulsante ACCESSO è disabilitato. Per risolvere i problemi della configurazione OIDC del cluster, 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 non vedi ancora i dettagli del cluster, assicurati di aver concesso le autorizzazioni RBAC corrette all'account 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 al campo authentication.oidc.extraParams nella risorsa ClientConfig. Quindi rigenera il file di autenticazione del client.

Token di aggiornamento scaduto

Il seguente problema si verifica quando il token di aggiornamento nel file kubeconfig è 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 nelle configurazioni variabile di ambiente https_proxy o HTTPS_PROXY. Se nelle variabili di ambiente è specificato un valore https://, le librerie client HTTP di GoLang potrebbero avere esito negativo se il proxy è configurato per gestire le connessioni HTTPS che utilizzano altri protocolli come SOCK5.

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 le variabili di ambiente https_proxy e HTTPS_PROXY in modo da omettere https:// prefix. Su Windows, modifica le variabili di ambiente di sistema. Ad esempio, modifica il valore della variabile di ambiente https_proxy 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. Questo può accadere se mancano gli RBAC appropriati o se sono errati oppure se si verifica un errore nella configurazione OIDC per il cluster. Potrebbe essere visualizzato il seguente errore:

Unauthorized

Per risolvere il problema, completa i seguenti passaggi:

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

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

  2. Installa jwt-cli ed esegui:

    jwt ID_TOKEN

  3. Verifica la configurazione OIDC.

    La risorsa ClientConfig contiene i campi group e username. Questi campi sono utilizzati per impostare i flag --oidc-group-claim e --oidc-username-claim nel server API Kubernetes. Quando il server API viene presentato con il token, lo inoltra a GKE Identity Service, che restituisce group-claim e username-claim estratti al server API. 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 risorsa ClientConfig siano presenti nel token ID.

  4. Controlla gli RBAC applicati.

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

    Se il campo usernameprefix è vuoto e username è un valore diverso da email, il prefisso è issuerurl# per impostazione predefinita. Per disabilitare i prefissi nome utente, imposta usernameprefix su -.

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

    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 il ruolo cluster pod-reader. Annota la singola barra nel campo del nome invece di 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

  5. 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 il token ID. Per verificare se si sono verificati problemi con il plug-in OIDC nel 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 per il quale visualizzare i log.
    • ADMIN_CLUSTER_KUBECONFIG: il file kubeconfig del cluster di amministrazione.

gkectl create-login-config non riesce a recuperare clientconfig

Questo problema si verifica quando il file kubeconfig passato a gkectl create-login-config non si riferisce a un cluster utente o la risorsa ClientConfig non è stata visualizzata durante la creazione del cluster.

Error getting clientconfig using KUBECONFIG

Per risolvere il problema, assicurati di avere il file kubeconfig corretto per il tuo cluster utente. Poi controlla se la risorsa ClientConfig si trova nel cluster:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

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

gkectl create-login-config ha esito negativo a causa di un nome cluster duplicato

Questo problema si verifica se tenti di scrivere dati di configurazione dell'accesso che contengono un nome di cluster già esistente nel file di destinazione. Ogni file di configurazione dell'accesso deve contenere nomi univoci per il cluster.

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

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

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

Risolvere i problemi relativi a OIDC

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

Consulta la guida alla risoluzione dei problemi relativi al provider di identità del servizio di identità GKE per informazioni su come abilitare ed esaminare i log di identità e testare la connettività. Dopo aver confermato che GKE Identity Service funziona come previsto o aver identificato un problema, rivedi le seguenti informazioni per la risoluzione dei problemi OIDC.

Controlla la specifica OIDC nel cluster

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

  1. 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 file kubeconfig del cluster utente.

  2. Esamina i valori del campo per confermare che la specifica sia configurata correttamente per il tuo provider OIDC.

  3. Se rilevi un problema di configurazione nella specifica, riconfigura OIDC.

  4. Se non riesci a diagnosticare e risolvere autonomamente il problema, rivolgiti all'assistenza Google Cloud.

    L'assistenza Google Cloud ha bisogno dei log di GKE Identity Service e della specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Verifica che l'autenticazione OIDC sia abilitata

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

  1. 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 è abilitata correttamente:

    ...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...

    Se l'autenticazione OIDC non è abilitata correttamente, vengono visualizzati errori simili all'esempio seguente:

    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. Non puoi eseguire questi passaggi da una sessione SSH basata su testo. Per verificare che OIDC funzioni correttamente nel tuo cluster, completa i seguenti passaggi:

  1. Scarica Google Cloud CLI.

  2. 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 file kubeconfig del cluster utente.

  3. 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 a cui connetterti.
    • AUTH_KUBECONFIG con il nuovo file kubeconfig da creare che include le credenziali per accedere al cluster. Per ulteriori informazioni, consulta Autenticazione nel cluster.

  4. Dovresti ricevere una pagina per il consenso di accesso aperta nel browser web predefinito della workstation locale. Fornisci informazioni di autenticazione valide per un utente in questa richiesta di accesso.

    Dopo aver completato il passaggio di accesso precedente, viene generato un file kubeconfig nella directory attuale.

  5. Per testare il nuovo file kubeconfig che include le tue credenziali, elenca i pod nel cluster utente:

    kubectl get pods --kubeconfig AUTH_KUBECONFIG

    Sostituisci AUTH_KUBECONFIG con il percorso del nuovo file kubeconfig generato nel passaggio precedente.

    Potrebbe essere restituito il seguente messaggio di esempio che indica che l'autenticazione è riuscita, ma non sono stati assegnati controlli di accesso basati sui ruoli (RBAC) 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.

  1. 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 file kubeconfig del cluster utente.

  2. 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 nel campo issuerURL, come htps://accounts.google.com (manca t in https). I log di GKE Identity Service contengono una voce come la seguente:

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.

  3. Se rilevi un problema di configurazione nei log, riconfigura OIDC e correggi i problemi di configurazione.

  4. Se non riesci a diagnosticare e risolvere autonomamente il problema, contatta l'assistenza Google Cloud. L'assistenza Google Cloud ha bisogno dei log del servizio di identità GKE e della specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Problemi OIDC comuni

In caso di problemi con l'autenticazione OIDC, esamina i seguenti problemi comuni. Segui le indicazioni per risolvere il problema.

Nessun endpoint disponibile per il servizio "ais"

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

  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. Il pod del servizio di identità GKE non è in grado di gestire il webhook di convalida.

  1. Per confermare che il pod del servizio di identità GKE non è integro, esegui questo comando:

    kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG

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

    L'output di esempio seguente indica che il pod GKE Identity Service si arresta in modo anomalo:

    NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s

  2. 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 file kubeconfig del cluster utente.

    L'output di esempio seguente segnala un errore di autorizzazione durante il pull dell'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"

  3. Se gli eventi del pod segnalano un problema, continua con la risoluzione dei problemi nelle aree interessate. Se hai bisogno di ulteriore aiuto, 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 sparsamente nel log: è probabile che gli errori di riposo non siano il problema principale e potrebbero essere problemi di rete intermittenti.

    Il plug-in OIDC di GKE Identity Service dispone di un processo daemon per sincronizzare periodicamente l'URL di rilevamento OIDC ogni 5 secondi. Se la connessione di rete è instabile, questa richiesta in uscita potrebbe non riuscire. Un errore occasionale non influisce sull'autenticazione OIDC. I dati esistenti memorizzati nella cache possono essere riutilizzati.

    Se si verificano errori di riserva nei log, continua con i passaggi aggiuntivi per la risoluzione dei problemi.

  • Vengono visualizzati costantemente nel log oppure il servizio di identità GKE non raggiunge mai l'endpoint noto: questi problemi costanti indicano un problema di connettività tra GKE Identity Service e il tuo provider di identità OIDC.

    I seguenti passaggi di risoluzione dei problemi possono aiutare a diagnosticare questi problemi di connettività:

    1. Assicurati che un firewall non stia bloccando le richieste in uscita da 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 proxy nella risorsa ClientConfig, controlla lo stato o il log del server proxy in uscita.
    5. Verifica la connettività tra il pod di 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 il seguente messaggio di errore:

  You must be logged in to the server (Unauthorized)

Questo errore è un problema generale di autenticazione di Kubernetes che non fornisce informazioni aggiuntive. Tuttavia, questo errore indica un problema di configurazione.

Per determinare il problema, esamina le sezioni precedenti su Verificare la specifica OIDC nel cluster e Configurare 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.

  1. Per verificare se l'endpoint di GKE Identity Service è raggiungibile dall'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 del tuo server API.

    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 ulteriore 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 il provider di identità. Un tentativo di accesso viene reindirizzato a una pagina con un errore 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:

  1. Se il provider di identità non è raggiungibile sulla rete internet pubblica, abilita il proxy HTTP OIDC per accedere utilizzando la console Google Cloud. Modifica la risorsa personalizzata ClientConfig e imposta useHTTPProxy su true:

    kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG

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

  2. Se il proxy HTTP è abilitato, ma continui a riscontrare questo errore, potrebbe esserci un problema di 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 file kubeconfig del cluster utente.

    Anche se il tuo provider di identità ha una CA nota, devi fornire un valore per oidc.caPath nella risorsa personalizzata ClientConfig per avviare il proxy HTTP.

  3. Se il server di autorizzazione richiede il consenso e non hai incluso i parametri extraparam prompt=consent, modifica la risorsa personalizzata ClientConfig 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 file kubeconfig del cluster utente.

  4. Se le impostazioni di configurazione vengono modificate nel servizio di archiviazione, potrebbe essere necessario uscire esplicitamente dalle sessioni esistenti. Nella console Google Cloud, vai alla 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 l'ambiente seguendo uno dei documenti di configurazione appropriati:

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

Consulta la guida alla risoluzione dei problemi relativi al provider di identità del servizio di identità GKE per informazioni su come abilitare ed esaminare i log di identità e testare la connettività. Dopo aver confermato che GKE Identity Service funziona come previsto o aver identificato un problema, esamina le seguenti informazioni sulla risoluzione dei problemi LDAP.

Verificare che l'autenticazione LDAP sia attiva

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

  1. 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 è abilitata correttamente:

    ...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...

    Se l'autenticazione LDAP non è abilitata correttamente, vengono visualizzati errori simili all'esempio seguente:

    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. Non puoi eseguire questi passaggi da una sessione SSH basata su testo. Per verificare che l'autenticazione LDAP funzioni correttamente nel cluster, completa i seguenti passaggi:

  1. Scarica Google Cloud CLI.

  2. 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 file kubeconfig del cluster utente.

  3. 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 a cui connetterti.
    • AUTH_KUBECONFIG con il nuovo file kubeconfig da creare che include le credenziali per accedere al cluster. Per ulteriori informazioni, consulta Autenticazione nel cluster.

  4. Dovresti ricevere una pagina per il consenso di accesso aperta nel browser web predefinito della workstation locale. Fornisci informazioni di autenticazione valide per un utente in questa richiesta di accesso.

    Dopo aver completato il passaggio di accesso precedente, viene generato un file kubeconfig nella directory attuale.

  5. Per testare il nuovo file kubeconfig che include le tue credenziali, elenca i pod nel cluster utente:

    kubectl get pods --kubeconfig AUTH_KUBECONFIG

    Sostituisci AUTH_KUBECONFIG con il percorso kubeconfig del cluster utente 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

Se hai problemi con l'autenticazione LDAP, esamina i problemi comuni riportati di seguito. Segui le indicazioni per risolvere il problema.

Gli utenti non possono autenticarsi con le virgole nel loro CN

Quando utilizzi LDAP, potresti riscontrare problemi nei quali gli utenti non possono autenticarsi se il loro nome di rete contiene una virgola, come CN="a,b". Se abiliti il log di debug per GKE Identity Service, viene visualizzato 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 esegue due volte l'escape della virgola. Questo problema si verifica solo nelle versioni Google Distributed Cloud 1.13 e precedenti.

Per risolvere il problema, completa uno dei seguenti passaggi:

  1. Esegui l'upgrade del cluster a Google Distributed Cloud 1.13 o versioni successive.
  2. Scegli un identifierAttribute diverso, ad esempio sAMAccountName, invece di utilizzare il CN.
  3. 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 messaggio di 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:

  1. 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

  2. Se esegui Google Cloud CLI anthos-auth versione 1.4.2, esegui l'upgrade alla versione 1.4.3 o successiva.

Problemi comuni

Questa sezione descrive i problemi comuni di autenticazione e come risolverli.

Accesso alla workstation di amministrazione perso a causa di un errore della chiave SSH permission denied

Quando provi a connetterti alla workstation di amministrazione e ricevi un messaggio "Permission denied" simile all'esempio seguente:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

Questo errore si verifica a causa dell'utilizzo di una chiave privata errata o dell'assenza di chiave quando ti connetti alla workstation di amministrazione mediante SSH.

Per risolvere il problema, individua e utilizza la chiave SSH corretta. Se non riesci a trovare la chiave SSH corretta, genera una nuova coppia di chiavi SSH per la workstation di amministrazione seguendo questi passaggi:

  1. Crea una VM di recupero temporanea. Questa VM di recupero deve connettersi alla stessa rete e allo stesso Datastore dell'attuale VM della workstation di amministrazione.

  2. Spegni la VM della workstation di amministrazione e la VM di recupero.

  3. Collega il disco dati della VM della workstation di amministrazione alla VM di recupero. Il disco dati in genere è di 512 MB, a meno che tu non abbia specificato una dimensione del disco diversa nel file di configurazione della workstation di amministrazione, che è diverso dal disco di avvio.

  4. Accendi la VM di recupero.

  5. Connettiti alla Rescue VM tramite SSH.

  6. Genera una nuova coppia di chiavi SSH sul computer locale.

  7. Sul tuo computer locale, copia la nuova chiave pubblica SSH nella VM di recupero utilizzando il comando ssh-copy-id:

    ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM

    Sostituisci quanto segue:

    • NEW_SSH_KEY con il nome della nuova chiave SSH creata nel passaggio precedente.
    • RESCUE_VM con l'indirizzo IP o il nome di dominio completo della VM di recupero.

  8. Sulla Rescue VM, monta il disco dati sulla Rescue VM:

    sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk

    Sostituisci DEVICE con l'identificatore univoco del tuo disco, ad esempio /dev/sdb1.

  9. Sulla VM di recupero, copia la nuova chiave pubblica SSH nel file authorized_keys sul disco dati montato dalla VM della workstation di amministrazione.

    Visualizza i contenuti del file authorized_keys sulla VM di recupero, che include la nuova chiave pubblica SSH copiata utilizzando il comando ssh-copy-id in un passaggio precedente:

    ls ~/.ssh/authorized_keys

    Copia l'ultima voce di chiave pubblica SSH dal file authorized_keys, quindi chiudi il file.

  10. Modifica il file authorized_keys sul disco dati montato dalla VM della workstation di amministrazione:

    vi /mnt/ext-disk/.ssh/authorized_keys

    Incolla i contenuti della chiave pubblica SSH dal file authorized_keys della VM di recupero.

  11. Salva e chiudi il file authorized_keys sul disco dati montato dalla VM della workstation di amministrazione.

  12. Verifica che ai file in /mnt/ext-disk/.ssh/ siano applicate le autorizzazioni corrette:

    chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*

  13. Esci dalla connessione SSH alla VM di recupero.

  14. Arresta la VM di recupero.

  15. Scollega il disco dati dalla VM di recupero e ricollegalo alla VM della workstation di amministrazione.

  16. Accendi la workstation di amministrazione.

  17. Dopo che la VM è in esecuzione, connettiti alla workstation di amministrazione utilizzando SSH e la nuova coppia di chiavi SSH.

    ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM

    Sostituisci quanto segue:

    • NEW_SSH_KEY con il nome della nuova chiave SSH che hai creato in un passaggio precedente e copiato nella VM della workstation di amministrazione.
    • RESCUE_VM con l'indirizzo IP o il nome di dominio completo della VM della workstation di amministrazione.

    Verifica di poter connetterti correttamente tramite SSH.

  18. Elimina la VM di recupero.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.