Questo documento aiuta a risolvere i problemi di autenticazione in Google Distributed Cloud. Vengono fornite informazioni e indicazioni generali per la risoluzione dei problemi, nonché informazioni specifiche per OpenID Connect (OIDC) e Lightweight Directory Access Protocol (LDAP).
L'autenticazione OIDC e LDAP utilizza GKE Identity Service. 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 provider più comuni:
Consulta la guida alla risoluzione dei problemi del provider di identità di GKE Identity Service per informazioni su come attivare e controllare i log delle identità e testare la connettività.
Risoluzione dei problemi generali
I seguenti suggerimenti per la risoluzione dei problemi possono aiutarti a risolvere i problemi generali di autenticazione e autorizzazione con Google Distributed Cloud. Se questi problemi non si applicano o hai problemi con OIDC o LDAP, continua con la sezione relativa alla risoluzione dei problemi di GKE Identity Service.
Mantieni gcloud anthos auth
aggiornato
Puoi evitare molti problemi comuni verificando che i componenti dell'installazione di gcloud anthos auth
siano aggiornati.
Devono essere verificati due elementi. Il comando gcloud anthos auth
ha una logica nel componente principale di Google Cloud CLI e un componente anthos-auth
con pacchetto separato.
Per aggiornare Google Cloud CLI:
gcloud components update
Per aggiornare il componente
anthos-auth
:gcloud components install anthos-auth
Configurazione del fornitore non valida
Se la configurazione del provider di identità non è valida, dopo aver fatto clic su LOGIN (ACCEDI) vedrai 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 ACCEDI è disattivato. Per risolvere i problemi relativi alla configurazione OIDC del cluster, consulta la seguente sezione 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 che hai utilizzato con OIDC. Potrebbe trattarsi di un account diverso da quello che utilizzi 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, nella risorsa ClientConfig
, aggiungi prompt=consent
al campo authentication.oidc.extraParams
. Quindi, rigenera il file di autenticazione client.
Il token di aggiornamento è scaduto
Si verifica il seguente problema 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
.
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 un https://
, le librerie client HTTP GoLang potrebbero non funzionare se il proxy è configurato per gestire le connessioni HTTPS utilizzando 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
per omettere https:// prefix
. In 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 dell'API Kubernetes non riesce ad autorizzare l'utente. Ciò può accadere se i RBAC appropriati non sono presenti o sono errati oppure se si verifica un errore nella configurazione OIDC per il cluster. Potrebbe essere visualizzato il seguente errore di esempio:
Unauthorized
Per risolvere il problema, completa i seguenti passaggi:
Nel file kubeconfig generato da
gcloud anthos auth login
, copia il valore diid-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
ha i campigroup
eusername
. Questi campi vengono utilizzati per impostare i flag--oidc-group-claim
e--oidc-username-claim
nel server API Kubernetes. Quando il server API riceve il token, lo inoltra a GKE Identity Service, che restituiscegroup-claim
eusername-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 rivendicazioni impostate per
group
euser
nella risorsaClientConfig
siano presenti nel token ID.Controlla i RBAC applicati.
Verifica che esista un RBAC con le autorizzazioni corrette per l'utente specificato da
username-claim
o per uno dei gruppi elencatigroup-claim
nel passaggio precedente. Il nome dell'utente o del gruppo nel controllo dell'accesso basato sui ruoli deve avere come prefissousernameprefix
ogroupprefix
specificato nella risorsaClientConfig
.Se
usernameprefix
è vuoto eusername
è un valore diverso daemail
, il prefisso è impostato suissuerurl#
per impostazione predefinita. Per disattivare i prefissi dei nomi utente, impostausernameprefix
su-
.Per ulteriori informazioni sui prefissi di utenti e gruppi, 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" ], ... }
I seguenti binding RBAC concedono a questo gruppo e utente il ruolo cluster
pod-reader
. Nota la singola barra nel campo del nome anziché la doppia barra:ClusterRoleBinding di 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
ClusterRoleBinding utente:
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 dell'API Kubernetes.
Se il plug-in OIDC configurato nel server API Kubernetes non viene avviato correttamente, il server API restituisce un errore
Unauthorized
quando viene presentato con 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 cui 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 è per 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 non riesce a causa di un nome del cluster duplicato
Questo problema si verifica se tenti di scrivere dati di configurazione di accesso che contengono un nome cluster già esistente nel file di destinazione. Ogni file di configurazione di accesso deve contenere nomi di cluster univoci.
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 fornisci --output
, questi dati di configurazione dell'accesso vengono scritti in un file denominato kubectl-anthos-config.yaml
nella directory corrente.
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 del provider di identità di GKE Identity Service per informazioni su come attivare e controllare i log delle identità e testare la connettività. Dopo aver verificato che GKE Identity Service funziona come previsto o aver identificato un problema, esamina le seguenti informazioni per la risoluzione dei problemi di OIDC.
Controlla la specifica OIDC nel cluster
Le informazioni OIDC per il cluster sono specificate nella risorsa ClientConfig
nello spazio dei nomi kube-public
.
Utilizza
kubectl get
per stampare la risorsa OIDC per il tuo 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.Rivedi i valori dei campi per verificare che la specifica sia configurata correttamente per il tuo provider OIDC.
Se identifichi un problema di configurazione nella specifica, riconfigura OIDC.
Se non riesci a diagnosticare e risolvere il problema autonomamente, contatta l' Google Cloud assistenza.
Google Cloud Il team di assistenza ha bisogno dei log di GKE Identity Service e della specifica OIDC per diagnosticare e risolvere i problemi relativi a OIDC.
Verifica che l'autenticazione OIDC sia abilitata
Prima di testare l'autenticazione OIDC, verifica che sia abilitata nel 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 è abilitata correttamente:
... I1011 22:14:21.684580 33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started. ...
Se l'autenticazione OIDC non è attivata correttamente, vengono visualizzati errori simili a questo esempio:
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 la GUI 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:
- Scarica Google Cloud CLI.
Per generare il file di configurazione di 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.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 per creare che includa le credenziali per accedere al cluster. Per ulteriori informazioni, consulta Autenticarsi nel cluster.
Dovresti visualizzare una pagina di consenso per l'accesso nel browser web predefinito della tua workstation locale. Fornisci informazioni di autenticazione valide per un utente in questo prompt di accesso.
Dopo aver completato correttamente il passaggio di accesso precedente, viene generato un file kubeconfig nella directory corrente.
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 mostra che puoi autenticarti correttamente, ma non sono assegnati controlli dell'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
Esaminare i log di autenticazione OIDC
Se non riesci ad autenticarti 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 file kubeconfig del cluster utente.Controlla i log per individuare gli errori che possono aiutarti a diagnosticare i problemi di OIDC.
Ad esempio, la risorsa
ClientConfig
potrebbe avere un errore di battitura nel campoissuerURL
, ad esempiohtps://accounts.google.com
(manca unt
inhttps
). I log di GKE Identity Service conterranno una voce come la seguente: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 correggi i problemi di configurazione.
Se non riesci a diagnosticare e risolvere il problema autonomamente, contatta l' Google Cloud assistenza.
Google Cloud Per diagnosticare e risolvere i problemi di OIDC, l'assistenza ha bisogno dei log di GKE Identity Service e della specifica OIDC.
Problemi comuni relativi a OIDC
Se riscontri problemi con l'autenticazione OIDC, esamina i problemi comuni riportati di seguito. Segui le indicazioni su come 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 GKE Identity Service non integro. Il pod GKE Identity Service non è in grado di gestire il webhook di convalida.
Per confermare che il pod GKE Identity Service non è integro, esegui il seguente 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 del servizio di identità GKE è in 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 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"
Se il report sugli eventi del pod segnala un problema, continua a risolvere i problemi nelle aree interessate. Se hai bisogno di ulteriore assistenza, contatta Google Cloud l'assistenza.
Errore durante la lettura dei byte di risposta dal server
Nei log di GKE Identity Service potrebbero essere presenti 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: gli errori sporadici probabilmente non sono il problema principale e potrebbero essere problemi di rete intermittenti.
Il plug-in OIDC di GKE Identity Service ha un processo daemon per sincronizzare periodicamente l'URL di rilevamento OIDC ogni 5 secondi. Se la connessione di rete è instabile, questa richiesta di uscita potrebbe non andare a buon fine. Un errore occasionale non influisce sull'autenticazione OIDC. I dati memorizzati nella cache esistenti possono essere riutilizzati.
Se nei log riscontri errori di riserva, continua con ulteriori passaggi per la risoluzione dei problemi.
Appare costantemente nel log o GKE Identity Service 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 per la risoluzione dei problemi possono aiutarti a diagnosticare questi problemi di connettività:
- Assicurati che un firewall non blocchi le richieste in uscita da GKE Identity Service.
- Verifica che il server del provider di identità sia in esecuzione correttamente.
- Verifica che l'URL dell'emittente OIDC nella risorsa
ClientConfig
sia configurato correttamente. - Se hai attivato il campo proxy nella risorsa
ClientConfig
, esamina lo stato o il log del server proxy di uscita. - Verifica la connettività tra il 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 il seguente messaggio di errore:
You must be logged in to the server (Unauthorized)
Questo errore è un problema di autenticazione Kubernetes generale che non fornisce informazioni aggiuntive. Tuttavia, questo errore indica un problema di configurazione.
Per determinare il problema, esamina le sezioni precedenti per
controllare la specifica OIDC nel cluster
e
configurare la risorsa ClientConfig
.
Impossibile effettuare la richiesta di autenticatore 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 riesce a stabilire la connessione con il pod del servizio di identità GKE.
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 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 Google Cloud console 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 i passaggi per la risoluzione dei problemi riportati di seguito. Dopo ogni passaggio, prova di nuovo ad accedere:
Se il provider di identità non è raggiungibile tramite internet pubblico, attiva il proxy HTTP OIDC per accedere utilizzando la console Google Cloud . Modifica la risorsa personalizzata
ClientConfig
e impostauseHTTPProxy
sutrue
:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Sostituisci
USER_CLUSTER_KUBECONFIG
con il percorso del file kubeconfig del cluster utente.Se il proxy HTTP è abilitato e continui a riscontrare questo errore, potrebbe essersi verificato un problema con l'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 personalizzataClientConfig
affinché il proxy HTTP venga avviato correttamente.Se il server di autorizzazione richiede il consenso e non hai incluso i parametri
extraparam
prompt=consent
, modifica la risorsa personalizzataClientConfig
e aggiungiprompt=consent
ai parametriextraparams
:kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
Sostituisci
USER_CLUSTER_KUBECONFIG
con il percorso del file kubeconfig del cluster utente.Se le impostazioni di configurazione vengono modificate nel servizio di archiviazione, potresti dover 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
Se riscontri problemi con l'autenticazione LDAP, assicurati di aver configurato il tuo ambiente seguendo uno dei documenti di configurazione appropriati:
Devi anche assicurarti di
compilare il secret dell'account di servizio LDAP
e di aver
configurato la risorsa ClientConfig
per attivare l'autenticazione LDAP.
Consulta la guida alla risoluzione dei problemi del provider di identità di GKE Identity Service per informazioni su come attivare e controllare i log delle identità e testare la connettività. Dopo aver verificato che GKE Identity Service funziona come previsto o aver identificato un problema, esamina le seguenti informazioni per la risoluzione dei problemi LDAP.
Verifica che l'autenticazione LDAP sia abilitata
Prima di testare l'autenticazione LDAP, verifica che sia abilitata nel 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 è abilitata correttamente:
... I1012 00:14:11.282107 34 plugin_list.h:139] LDAP[0] started. ...
Se l'autenticazione LDAP non è attivata correttamente, vengono visualizzati errori simili a questo esempio:
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, usa 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 l'autenticazione LDAP funzioni correttamente nel tuo cluster, completa i seguenti passaggi:
- Scarica Google Cloud CLI.
Per generare il file di configurazione di 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.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 per creare un file che includa le credenziali per accedere al cluster. Per ulteriori informazioni, consulta Autenticarsi nel cluster.
Dovresti visualizzare una pagina di consenso per l'accesso nel browser web predefinito della tua workstation locale. Fornisci informazioni di autenticazione valide per un utente in questo prompt di accesso.
Dopo aver completato correttamente il passaggio di accesso precedente, viene generato un file kubeconfig nella directory corrente.
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 file 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 di LDAP
Se riscontri problemi con l'autenticazione LDAP, esamina i problemi comuni riportati di seguito. Segui le indicazioni su come risolvere il problema.
Gli utenti non possono eseguire l'autenticazione con le virgole nel nome comune
Quando utilizzi LDAP, potresti riscontrare problemi di autenticazione degli utenti se
il loro CN contiene una virgola, ad esempio CN="a,b"
. Se abiliti 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 di GKE Identity Service esegue l'escape doppio 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:
- Esegui l'upgrade del cluster a Google Distributed Cloud 1.13 o versioni successive.
- Scegli un altro
identifierAttribute
, ad esempiosAMAccountName
, anziché utilizzare il CN. - Rimuovi le virgole all'interno di 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 viene visualizzato 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 versione 1.4.2:
anthos-auth
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 alla versione 1.4.3 o successive.
Problemi comuni
Questa sezione descrive i problemi di autenticazione comuni e come risolverli.
Accesso alla workstation di amministrazione perso a causa dell'errore della chiave SSH permission denied
Si verifica il seguente errore quando provi a connetterti alla workstation amministrativa e
ricevi un messaggio "Permission denied"
simile al seguente esempio:
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 di nessuna chiave quando ti connetti alla workstation amministrativa tramite SSH.
Per risolvere il problema, trova 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:
Crea una VM di salvataggio temporanea. Questa VM di recupero deve connettersi alla stessa rete e allo stesso datastore della VM workstation amministrativa corrente.
Spegni la VM workstation di amministrazione e la VM di recupero.
Collega il disco di dati della VM workstation di amministrazione alla VM di ripristino. Il disco di dati è in genere di 512 MB, a meno che tu non abbia specificato una dimensione diversa nel file di configurazione della workstation amministrativa, che è diverso dal disco di avvio.
Accendi la VM di recupero.
Connettiti alla VM di ripristino tramite SSH.
Sul computer locale, genera una nuova coppia di chiavi SSH.
Sul computer locale, copia la nuova chiave SSH pubblica nella VM di ripristino 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 che hai creato nel passaggio precedente.RESCUE_VM
con l'indirizzo IP o il nome di dominio completo della VM di ripristino.
Sulla VM di soccorso, monta il disco dati sulla VM di soccorso:
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
.Nella VM di soccorso, copia la nuova chiave SSH pubblica nel file
authorized_keys
sul disco di dati montato dalla VM della workstation amministrativa.Visualizza i contenuti del file
authorized_keys
nella VM di ripristino, che include la nuova chiave pubblica SSH copiata utilizzando il comandossh-copy-id
in un passaggio precedente:ls ~/.ssh/authorized_keys
Copia l'ultima voce della chiave pubblica SSH dal file
authorized_keys
, quindi chiudi il file.Modifica il file
authorized_keys
sul disco dati montato dalla VM workstation amministrativa:vi /mnt/ext-disk/.ssh/authorized_keys
Incolla i contenuti della chiave pubblica SSH dal file
authorized_keys
della VM di ripristino.Salva e chiudi il file
authorized_keys
sul disco di dati montato dalla VM della workstation amministrativa.Verifica che i file in
/mnt/ext-disk/.ssh/
abbiano le autorizzazioni corrette applicate:chown -R ubuntu /mnt/ext-disk/.ssh/* chmod -R 600 /mnt/ext-disk/.ssh/*
Esci dalla connessione SSH alla VM di ripristino.
Arresta la VM di soccorso.
Scollega il disco di dati dalla VM di ripristino e ricollegalo alla VM della workstation amministrativa.
Accendi la workstation di amministrazione.
Dopo aver avviato correttamente la VM, connettiti alla workstation amministrativa 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 postazione di amministrazione.
Verifica di poterti connettere correttamente utilizzando SSH.
Elimina la VM di recupero.
Passaggi successivi
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.
Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per aiutarti a risolvere i problemi, come log e metriche.
- Componenti supportati, versioni e funzionalità di Google Distributed Cloud per VMware (solo software).