Versione 1.11. Questa versione non è più supportata. Per ulteriori informazioni, consulta le norme relative all'assistenza per le versioni. Per informazioni su come eseguire l'upgrade alla versione 1.12, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.12.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Risolvi i problemi relativi a OIDC nei cluster Anthos su Bare Metal

Questa pagina mostra come identificare e risolvere i problemi di OpenID Connect (OIDC) con Cluster Anthos on bare metal.

Identificare i problemi OIDC

Quando OIDC non funziona per Cluster Anthos on bare metal, in genere la specifica OIDC all'interno del file di configurazione del cluster è stata configurata in modo errato. Questa sezione fornisce istruzioni per esaminare i log e le specifiche OIDC al fine di identificare la causa di un problema OIDC.

Esaminare i log del servizio Anthos Identity

Anthos Identity Service supporta OIDC nei cluster Anthos su Bare Metal.

Utilizza kubectl logs per stampare i log del servizio Anthos Identity:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

Esamina i log per individuare errori che possono aiutarti a diagnosticare i problemi OIDC.

Se non riesci ad autenticarti con OIDC, i log del servizio Anthos Identity forniscono le informazioni più pertinenti e utili per eseguire il debug del problema.

Ad esempio, se la specifica OIDC (nel file di configurazione del cluster) presenta un tipo nel campo issuerURL, come htps://accounts.google.com (senza "t" in https), i log del servizio Anthos Identity conterranno una voce simile alla seguente:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Se hai riscontrato un problema di configurazione nei log, consulta Riconfigurare OIDC.
Se non riesci a diagnosticare e risolvere il problema, contatta l'assistenza clienti Google Cloud.

L'assistenza clienti Google Cloud avrà bisogno dei log del servizio Anthos Identity e della specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Verifica delle specifiche OIDC nel cluster

Le informazioni OIDC per il cluster sono specificate nell'oggetto clientconfig nello spazio dei nomi kube-public.

Utilizza kubectl get per stampare la risorsa OIDC per il tuo cluster:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml
```
Nota: le specifiche clientconfig potrebbero differire leggermente dalle specifiche OIDC nel file di configurazione del cluster. Ad esempio, l'URL del provider OIDC è specificato con il campo issuerURL nel file di configurazione del cluster, ma l'oggetto clientconfig restituisce queste informazioni nel campo issuerURI.
Esamina i valori dei campi per confermare che la specifica sia configurata correttamente per il provider OIDC.
Se hai identificato un problema di configurazione nella specifica, vai alla sezione Riconfigurare OIDC.
Se non riesci a diagnosticare e risolvere il problema, contatta l'assistenza clienti Google Cloud.

L'assistenza clienti Google Cloud avrà bisogno dei log di servizio Anthos Identity e della specifica OIDC per diagnosticare e risolvere i problemi OIDC.

Riconfigurazione OIDC

Se hai riscontrato problemi nei log del servizio Anthos Identity o nell'oggetto clientconfig, puoi riconfigurare OIDC nel cluster (senza ricreare il cluster) per risolverli. Per riconfigurare OIDC, modifica l'oggetto predefinito KRM di tipo clientconfig nello spazio dei nomi kube-public:

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

I dettagli del CRD di ClientConfig vengono utilizzati per configurare OIDC sia per la console Google Cloud che per il plug-in di autenticazione di Anthos. Per informazioni dettagliate sulle informazioni OIDC incluse nel CRD ClientConfig, consulta la seguente descrizione di campi YAML e associati.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

La seguente tabella descrive i campi dell'oggetto oidc CRD ClientConfig.

Campo	Obbligatoria	Descrizione	Formatta
name	Sì	Il nome della configurazione OIDC da creare.	Stringa
CertificateAuthorityData	No	Un certificato con codifica PEM con codifica `base64` per il provider OIDC. Per creare la stringa, codifica il certificato, incluse le intestazioni, in `base64`. Includi la stringa risultante in `certificateAuthorityData` come una singola riga. Esempio: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	Stringa
ID cliente	Sì	ID dell'applicazione client che invia richieste di autenticazione al provider OpenID.	Stringa
clientSecret	No	Secret condiviso tra l'applicazione client OIDC e il provider OIDC.	Stringa
parametri aggiuntivi	No	Parametri chiave-valore aggiuntivi da inviare al provider OpenID. Se autorizzi un gruppo, passa in `resource=token-groups-claim`. Se il server di autorizzazione richiede il consenso per l'autenticazione con Microsoft Azure e Okta, imposta `extraParams` su `prompt=consent`. Per Cloud Identity, imposta `extraParams` su `prompt=consent,access_type=offline`.	Elenco delimitato da virgole
gruppoClaim	No	JWT che il fornitore utilizza per restituire i tuoi gruppi di sicurezza.	Stringa
prefisso gruppo	No	Prefisso anteposto alle attestazioni dei gruppi per evitare conflitti con i nomi esistenti. Ad esempio, se hai due gruppi denominati `foobar`, aggiungi un prefisso `gid-`. Il gruppo risultante è `gid-foobar`.	Stringa
emittenteURI	Sì	URL a cui vengono inviate le richieste di autorizzazione al tuo OpenID, ad esempio `https://example.com/adfs`. Il server API Kubernetes utilizza questo URL per rilevare le chiavi pubbliche per la verifica dei token. L'URI deve utilizzare HTTPS.	Stringa URL
kubectlRedirectURI	Sì	L'URL di reindirizzamento che `kubectl` utilizza per l'autorizzazione.	Stringa URL
ambiti	Sì	Ambiti aggiuntivi da inviare al provider OpenID. Microsoft Azure e Okta richiedono l'ambito `offline_access`.	Elenco delimitato da virgole
Rivendicazione utente	No	Attestazione JWT da utilizzare come nome utente. Puoi scegliere altre rivendicazioni, ad esempio email o nome, a seconda del provider OpenID. Tuttavia, le rivendicazioni diverse dall'email sono precedute dall'URL dell'emittente per evitare conflitti di denominazione.	Stringa
Prefisso utente	No	Prefisso anteposto alle attestazioni dei nomi utente per evitare conflitti con i nomi esistenti.	Stringa
proxy	No	Server proxy da utilizzare per il metodo `auth`, se applicabile. Ad esempio: `http://user:password@10.10.10.10:8888.`.	Stringa