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, di solito è il risultato di un problema di configurazione nella specifica OIDC nel file di configurazione del cluster. 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.

  1. 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
    
  2. 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.
    
  3. Se hai identificato un problema di configurazione nei log, vai alla pagina di riconfigurazione del OIDC.

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

  1. 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
    
  2. Rivedi i valori del campo per verificare che la specifica sia configurata correttamente per il tuo provider OIDC.

  3. Se hai identificato un problema di configurazione nella specifica, vai alla pagina relativa alla riconfigurazione dell'OIDC.

  4. 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 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 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 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 L'URL di reindirizzamento utilizzato da kubectl per l'autorizzazione. Stringa URL
ambiti Ambiti aggiuntivi da inviare al provider OpenID. Microsoft Azure e Okta richiedono l'ambito offline_access. Elenco delimitato da virgole
RivendicazioneUtente 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:password@10.10.10.10:8888. Stringa