Versione 1.6. 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.7, consulta la pagina relativa all'upgrade di Anthos su Bare Metal nella documentazione della versione 1.7.

Versioni supportate disponibili: 1.14 | 1.13 | 1.12

Risolvere 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 i cluster Anthos su Bare Metal.

Identificare i problemi relativi all'OIDC

Quando OIDC non funziona per i cluster Anthos su 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 per 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 di Anthos Identity Service:

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

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

Se non riesci a eseguire l'autenticazione con OIDC, i log di Anthos Identity Service 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) contiene un errore di ortografia nel campo issuerURL, ad esempio htps://accounts.google.com (senza un tag "&" in https), i log di servizio di Identity Identity contengono una voce simile alla seguente:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Se hai identificato un problema di configurazione nei log, vai alla pagina di riconfigurazione del OIDC.
Se non sei in grado di diagnosticare e risolvere autonomamente il problema, rivolgiti all'assistenza clienti Cloud.

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

Controllo della specifica OIDC nel cluster in corso...

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 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 viene specificato con il campo issuerURL nel file di configurazione del cluster, ma l'oggetto clientconfig restituisce queste informazioni nel campo issuerURI.
Rivedi i valori del campo per verificare che la specifica sia configurata correttamente per il tuo provider OIDC.
Se hai identificato un problema di configurazione nella specifica, vai alla pagina relativa alla riconfigurazione dell'OIDC.
Se non sei in grado di diagnosticare e risolvere autonomamente il problema, rivolgiti all'assistenza clienti 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 identificato problemi nei log di Anthos Identity Service o nell'oggetto clientconfig, puoi riconfigurare l'OIDC nel cluster (senza ricreare il cluster) per risolverli. Per riconfigurare l'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 per Anthos. Per maggiori dettagli sulle informazioni OIDC incluse nel CRD ClientConfig, consulta la seguente YAML e la tabella associata delle descrizioni.

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

Nella tabella seguente vengono descritti i campi dell'oggetto CRD oidc di ClientConfig.

Campo	Obbligatoria	Descrizione	Formato
name	Sì	Il nome della configurazione OIDC da creare.	Stringa
CertificateAuthorityData	No	Un certificato 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 riga singola. Esempio: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	Stringa
ID cliente	Sì	ID dell'applicazione client che invia le 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 coppia chiave-valore aggiuntivi da inviare al provider OpenID. Se autorizzi un gruppo, supera `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
Rivendicazione di gruppi	No	JWT che il provider 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 di Kubernetes utilizza questo URL per rilevare le chiavi pubbliche per la verifica dei token. L'URI deve utilizzare HTTPS.	Stringa URL
kubectlReindirizzamentoURI	Sì	L'URL di reindirizzamento utilizzato da `kubectl` 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
RivendicazioneUtente	No	Attestazione JWT da utilizzare come nome utente. Puoi scegliere altre attestazioni, ad esempio email o nome, a seconda del provider OpenID. Tuttavia, alle attestazioni diverse dall'indirizzo email viene aggiunto come prefisso l'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:[email protected]:8888.`	Stringa