Autenticazione con OpenID Connect (OIDC)

Scopri come configurare i cluster Anthos su VMware (GKE On-Prem) per utilizzare OpenID Connect (OIDC) per l'autenticazione nei cluster utente. Questa pagina illustra la procedura in generale per aiutarti a comprendere come configurare qualsiasi provider OpenID.

Per una panoramica del flusso di autenticazione dei cluster Anthos su VMware, vedi Autenticazione. Per scoprire come configurare OIDC con altri provider OpenID, consulta le risorse seguenti:

• Autenticazione con OIDC e Active Directory Federation Services (AD FS)
• Autenticarsi con OIDC e Google

I cluster Anthos su VMware supportano OIDC come uno dei meccanismi di autenticazione per interagire con un server API Kubernetes di un cluster utente. Con OIDC puoi gestire l'accesso ai cluster Kubernetes utilizzando le procedure standard nella tua organizzazione per creare, abilitare e disabilitare gli account utente.

Gli utenti possono autorizzare gli account in due modi:

• Utilizza Google Cloud CLI per avviare il flusso OIDC e ottenere l'autorizzazione dell'utente tramite una pagina di consenso basata sul browser.

• Utilizza Google Cloud Console per avviare il flusso di autenticazione OIDC.

Prima di iniziare

• Questo argomento presuppone che tu abbia familiarità con i seguenti concetti di autenticazione e OpenID:

  • OAuth 2.0
  • OpenID Connect
  • ambiti
  • rivendicazioni

• I sistemi headless non sono supportati. Un flusso di autenticazione basato su browser viene utilizzato per chiederti il consenso e autorizzare il tuo account utente.

• Per autenticarti tramite la console Google Cloud, ogni cluster che vuoi configurare per l'autenticazione OIDC deve essere registrato con Google Cloud.

Utenti tipo

Questo argomento si riferisce a tre utenti tipo:

• Amministratore dell'organizzazione. Questa persona sceglie un provider OpenID e registra le applicazioni client con il provider.

• Amministratore del cluster. Questa persona crea uno o più cluster utente e crea file di configurazione di autenticazione per gli sviluppatori che utilizzano i cluster.

• Sviluppatore. Questa persona esegue carichi di lavoro su uno o più cluster e utilizza OIDC per l'autenticazione.

Scelta di un provider OpenID

Questa sezione è rivolta agli amministratori dell'organizzazione.

Puoi utilizzare qualsiasi provider OpenID di tua scelta. Per un elenco dei provider certificati, consulta la sezione Certificazione OpenID.

Per i seguenti provider OpenID, consulta i passaggi di configurazione specifici nelle seguenti risorse:

• Servizi federati Active Directory

• Google

Creare URL di reindirizzamento

Questa sezione è rivolta agli amministratori dell'organizzazione.

Devi creare URL di reindirizzamento sia per l'interfaccia a riga di comando gcloud che per Google Cloud Console, che il provider OpenID può utilizzare per restituire i token ID.

URL di reindirizzamento dell'interfaccia a riga di comando gcloud

Google Cloud CLI è installato su ogni macchina locale dello sviluppatore. Puoi specificare un numero di porta superiore a 1024 da utilizzare per l'URL di reindirizzamento:

http://localhost:PORT/callback

Sostituisci PORT con il numero della tua porta.

Quando configuri il provider OpenID, specifica http://localhost:PORT/callback come uno degli URL di reindirizzamento. L'operazione dipende dal provider.

URL di reindirizzamento della console Google Cloud

L'URL di reindirizzamento per la console Google Cloud è:

https://console.cloud.google.com/kubernetes/oidc

Quando configuri il tuo provider OIDC, specifica https://console.cloud.google.com/kubernetes/oidc come uno dei tuoi URL di reindirizzamento. Le modalità da eseguire dipendono dal provider.

Registrazione delle applicazioni client con il provider OpenID

Questa sezione è rivolta agli amministratori dell'organizzazione.

Prima che gli sviluppatori possano utilizzare l'interfaccia a riga di comando gcloud o la console Google Cloud con il tuo provider OpenID, devi registrare i due client presso il provider OpenID. La registrazione prevede questi passaggi:

• Scopri l'URI dell'emittente del fornitore. È qui che vengono inviate le richieste di autenticazione dall'interfaccia a riga di comando gcloud o da Google Cloud Console.

• Fornisci al provider l'URL di reindirizzamento per l'interfaccia a riga di comando gcloud.

• Fornisci al provider l'URL di reindirizzamento della console Google Cloud. Questo è https://console.cloud.google.com/kubernetes/oidc.

• Stabilisci un singolo ID client. Questo è l'ID utilizzato dal provider per identificare sia l'interfaccia a riga di comando gcloud che Google Cloud Console.

• Stabilisci un singolo client secret. L'interfaccia a riga di comando gcloud e la console Google Cloud utilizzano entrambi questo secret per autenticarsi al provider OpenID.

• Definisci un ambito personalizzato che l'interfaccia a riga di comando gcloud o Google Cloud Console possa utilizzare per richiedere i gruppi di sicurezza degli utenti.

• Definisci un nome di rivendicazione personalizzato che il provider utilizzerà per restituire i gruppi di sicurezza dell'utente.

Le modalità di esecuzione di questi passaggi dipendono dal provider OpenID.

Configurazione di oidc sui cluster Anthos sui cluster VMware

Questa sezione è rivolta agli amministratori del cluster.

Per configurare l'autenticazione OIDC, devi configurare il CRD ClientConfig del cluster utente con i dettagli di autenticazione per un cluster. Per fare ciò, modifica l'oggetto predefinito KRM di tipo clientconfig nello spazio dei nomi kube-public.

kubectl --kubeconfig USER_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. La configurazione include le seguenti informazioni OIDC.

authentication:
  - name: NAME_STRING
    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:password@10.10.10.10:8888.	Stringa

Esempio: autorizzare utenti e gruppi

Molti provider codificano le proprietà di identificazione degli utenti, come email e User-ID, in un token. Tuttavia, queste proprietà presentano rischi impliciti per i criteri di autenticazione:

• Gli ID utente possono rendere i criteri difficili da leggere e controllare.

• Le email possono creare sia un rischio di disponibilità (se un utente cambia l'email principale) sia potenzialmente un rischio per la sicurezza (se un'email può essere riassegnata).

Pertanto, è una best practice utilizzare i criteri di gruppo, perché un ID gruppo può essere sia persistente che più facile da controllare.

Supponiamo che il tuo provider crei dei token di identità che includono i seguenti campi:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['[e-mail]', '[e-mail]']
  ...
}

Dato questo formato di token, dovrai completare la specifica del file di configurazione oidc come la seguente:

issuerURL: 'https://server.example.com'
userClaim: 'sub'
usernamePrefix: 'uid-'
groupsClaim: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Dopo aver creato il cluster utente, puoi utilizzare il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere l'accesso con privilegi agli utenti autenticati. Ad esempio, puoi creare un elemento ClusterRole che conceda agli utenti l'accesso in sola lettura ai secret del cluster e creare una risorsa ClusterRoleBinding per associare il ruolo al gruppo autenticato.

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Nota: se il provider OIDC restituisce un nome di gruppo che contiene caratteri di barra rovesciata doppia, uno dei caratteri di barra rovesciata deve essere omesso quando fai riferimento al nome del gruppo nella risorsa ClusterRoleBinding. Ad esempio, se hai creato un gruppo denominato corp\\my-group, fai riferimento alla risorsa ClusterRoleBinding come corp\my-group. Questo perché la prima barra rovesciata viene considerata un carattere di escape.

Creazione e distribuzione del file di configurazione dell'autenticazione

Questa sezione è rivolta agli amministratori del cluster.

Dopo aver creato un cluster utente, crei un file di configurazione di autenticazione per il cluster. Puoi configurare più cluster in un unico file di configurazione dell'autenticazione. Devi fornire ogni file di configurazione di autenticazione agli utenti che vogliono eseguire l'autenticazione con ciascuno di questi cluster.

Creare il file di configurazione dell'autenticazione

Per creare il file di configurazione dell'autenticazione nella directory corrente, esegui il comando gkectl seguente:

gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente. Quando hai eseguito gkectl create cluster per creare il tuo cluster utente, è stato creato il tuo file kubeconfig.

Risultato: il file di configurazione dell'autenticazione, denominato kubectl-anthos-config.yaml, viene creato nella directory corrente.

Aggiunta di più cluster al file di configurazione dell'autenticazione

Puoi archiviare i dettagli della configurazione di autenticazione per più cluster all'interno di un singolo file di configurazione di autenticazione.

Puoi utilizzare il comando seguente per unire ulteriori dettagli di autenticazione del cluster utente in un file di configurazione di autenticazione esistente. Dato che è già presente un file di configurazione dell'autenticazione, puoi unire o combinare ulteriori dettagli sull'autenticazione del cluster utente:

• Unisci i dettagli aggiuntivi dell'autenticazione del cluster utente nel file di configurazione dell'autenticazione esistente.
• Combina i dettagli aggiuntivi di autenticazione del cluster utente in un nuovo file.

Ad esempio, potresti dover gestire sia i file di configurazione dell'autenticazione anthos-config-1cluster.yaml che anthos-config-3clusters.yaml per soddisfare le esigenze di accesso dei vari gruppi di utenti dell'organizzazione.

Per aggiungere altri cluster utente al file di configurazione dell'autenticazione esistente:

1. Assicurati che ogni cluster abbia un nome univoco. Se i tuoi cluster hanno gli stessi nomi, non puoi combinarli nello stesso file di configurazione di autenticazione. Tieni presente che, una volta creato, un cluster non può essere rinominato.

2. Esegui il comando gkectl seguente per unire o combinare i dettagli di configurazione:

   gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG \
   --merge-from IN_AUTH_CONFIG_FILE --output OUT_AUTH_CONFIG_FILE

   Sostituisci quanto segue:

   • USER_CLUSTER_KUBECONFIG specifica il file kubeconfig del cluster utente che vuoi aggiungere.

   • IN_AUTH_CONFIG_FILE specifica il percorso del file di configurazione dell'autenticazione esistente che vuoi unire alle informazioni aggiuntive sul cluster.

   • OUT_AUTH_CONFIG_FILE specifica il percorso del file in cui vuoi archiviare la configurazione di autenticazione unita:

     • Specifica lo stesso file di IN_AUTH_CONFIG_FILE per unire le informazioni aggiuntive sul cluster in tale file esistente.
     • Specifica un nuovo percorso e un nuovo nome file per combinare i dettagli di configurazione dell'autenticazione in un nuovo file.

Distribuzione del file di configurazione dell'autenticazione

Per consentire agli utenti di eseguire l'autenticazione nei cluster utente, devi fornire loro l'accesso a uno o più file di configurazione di autenticazione che hai creato. Tieni presente che i passaggi seguenti utilizzano il nome file predefinito e la posizione prevista dall'interfaccia a riga di comando gcloud. Per informazioni sull'utilizzo di nomi di file e posizioni alternativi, consulta Configurazione personalizzata.

Valuta se distribuire i file di configurazione dell'autenticazione:

• Ospitare il file su un URL accessibile. Se includi il flag --login-config nel comando gcloud anthos auth login, l'interfaccia a riga di comando gcloud ottiene il file di configurazione di autenticazione da quella posizione.

  Ti consigliamo di ospitare il file su un host sicuro. Per ulteriori informazioni sull'utilizzo dei certificati PEM per un accesso HTTPS sicuro, consulta il flag --login-config-cert dell'interfaccia a riga di comando gcloud.

• Fornendo manualmente il file a ogni utente. Dopo che gli utenti hanno scaricato il file, devi indicare loro come archiviare il file nella posizione predefinita e con il nome file predefinito previsto dall'interfaccia a riga di comando gcloud.

  Ad esempio, gli utenti possono eseguire i seguenti comandi per archiviare il file di configurazione dell'autenticazione con il nome file kubectl-anthos-config.yaml predefinito e nella posizione predefinita:

  Linux

  mkdir -p  $HOME/.config/google/anthos/
  cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

  macOS

  mkdir -p  $HOME/Library/Preferences/google/anthos/
  cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

  Windows

  md "%APPDATA%\google\anthos"
  copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

  dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

• Utilizzo degli strumenti interni per il push del file di configurazione di autenticazione su ogni computer dell'utente. Ad esempio, puoi utilizzare gli strumenti per eseguire il push dei file utilizzando il nome file kubectl-anthos-config.yaml predefinito nelle posizioni predefinite sulla macchina di ogni utente:

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Configurazione personalizzata

L'interfaccia a riga di comando gcloud prevede che il file di configurazione di autenticazione venga archiviato nella posizione predefinita e con il nome file predefinito kubectl-anthos-config.yaml, come indicato nella sezione precedente. Tuttavia, hai la possibilità di rinominare o archiviare il file di configurazione dell'autenticazione in una posizione alternativa. Se il nome e la posizione del file sono diversi da quelli predefiniti, devi aggiungere il flag --login-config a ogni comando che esegui durante l'autenticazione con il cluster. Il flag di comando aggiuntivo passa nel percorso e nel nome file personalizzati. Per scoprire di più sul flag di comando, consulta la pagina relativa all'autenticazione tramite l'interfaccia a riga di comando gcloud.

Installazione dell'interfaccia a riga di comando gcloud

Questa sezione è rivolta sia agli amministratori e agli sviluppatori del cluster.

Ogni sviluppatore o utente che deve eseguire l'autenticazione con un cluster deve installare Google Cloud CLI sulla propria macchina. I comandi di autenticazione Anthos sono stati integrati nell'interfaccia a riga di comando gcloud come anthos-authcomponente.

• Se hai una versione precedente del componente plug-in "Anthos for Kubectl", devi disinstallare il plug-in prima di installare l'interfaccia a riga di comando gcloud e il componente anthos-auth.

• Se hai già una versione dell'interfaccia a riga di comando gcloud, installa la versione più recente e il componente anthos-auth.

Rimozione di plug-in precedenti

Devi disinstallare il plug-in precedente per poter utilizzare il componente anthos-auth dell'interfaccia a riga di comando gcloud. Puoi controllare se sul tuo computer è presente uno dei plug-in precedenti basati su kubectl eseguendo il comando seguente:

kubectl anthos version

• Se il comando risponde con Error: unknown command "anthos" for "kubectl", non è stato trovato alcun plug-in e puoi passare alla sezione successiva.

• Se è stata trovata una versione 1.0beta del plug-in, devi individuarlo ed eliminarlo. Esegui questo comando per elencare la località, quindi utilizza la località per rimuovere il programma binario dalla macchina:

  kubectl plugin list

Installazione dell'interfaccia a riga di comando gcloud e dell'interfaccia a riga di comando gcloud

Per installare l'interfaccia a riga di comando gcloud, devi prima installare l'interfaccia a riga di comando gcloud:

Importante: l'uso dell'interfaccia a riga di comando gcloud con i cluster Anthos su VMware non richiede un Account Google. Se hai un account, l'accesso è facoltativo, ma non è necessario eseguire il comando gcloud init.

1. Installa l'interfaccia a riga di comando gcloud, ma ignora il comando gcloud init.

2. Per installare il componente anthos-auth, esegui questi comandi:

   gcloud components update
   gcloud components install anthos-auth

3. Verifica che l'interfaccia a riga di comando gcloud sia stata installata correttamente eseguendo uno dei comandi seguenti:

   gcloud anthos auth
   gcloud anthos auth login

   Risultato: ogni comando deve rispondere con i dettagli relativi agli argomenti richiesti e alle opzioni disponibili.

Ottenere il file di configurazione dell'autenticazione

Questa sezione è rivolta agli sviluppatori.

Il tuo amministratore è responsabile della creazione del tuo file di configurazione di autenticazione e, quindi, di fornirlo. Per maggiori dettagli, consulta la sezione Distribuzione del file di configurazione dell'autenticazione.

Per impostazione predefinita, l'interfaccia a riga di comando gcloud utilizza un nome file e una posizione di archiviazione predefiniti per il tuo file di configurazione di autenticazione. Se ti è stato fornito manualmente il file e devi salvarlo sulla macchina, utilizza le impostazioni predefinite per semplificare i comandi di autenticazione gcloud.

Utilizza i comandi seguenti per copiare il file di configurazione dell'autenticazione nella posizione predefinita:

Linux

mkdir -p  $HOME/.config/google/anthos/
cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml

dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

Windows

md "%APPDATA%\google\anthos"
copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

dove AUTH_CONFIG_FILE è il nome del tuo file di configurazione dell'autenticazione. Ad esempio: kubectl-anthos-config.yaml.

Se scegli di utilizzare un nome file o una posizione diversa, puoi includere il flag --login-config in ciascuna delle tue richieste di autenticazione. Vedi la sezione seguente per i dettagli sull'utilizzo del comando gcloud anthos auth login.

Autenticazione con i cluster utente

Questa sezione è rivolta agli sviluppatori.

Ora che l'interfaccia a riga di comando gcloud è installata sulla tua macchina e il file di configurazione dell'autenticazione ti è stato fornito dall'amministratore, puoi utilizzare l'interfaccia a riga di comando gcloud o la console Google Cloud per eseguire l'autenticazione con i cluster.

Autenticazione mediante l'interfaccia a riga di comando gcloud

Esegui gcloud comandi per eseguire l'autenticazione con i cluster:

1. Esegui il comando gcloud anthos auth login per avviare il flusso di autenticazione:

   gcloud anthos auth login \
    --cluster CLUSTER_NAME \
    --user USER_NAME \
    --login-config AUTH_CONFIG_FILE_PATH \
    --login-config-cert CA_CERT_PEM_FILE \
    --kubeconfig USER_CLUSTER_KUBECONFIG

   dove:

   • CLUSTER_NAME (facoltativo) specifica il nome del cluster utente. Se questo flag viene omesso, ti verrà chiesto di scegliere tra i cluster utente specificati nel file di configurazione di autenticazione.

   • USER_NAME (facoltativo) specifica il nome utente per le credenziali memorizzate nel file kubeconfig. Il valore predefinito è CLUSTER_NAME-anthos-default-user.

   • AUTH_CONFIG_FILE_PATH (facoltativo) specifica il percorso o l'URL personalizzato in cui viene archiviato o ospitato il file di configurazione dell'autenticazione. Puoi omettere questo parametro se il file si trova nella posizione predefinita. Esempio: --login-config /path/to/custom/authentication-config.yaml

   • CA_CERT_PEM_FILE (facoltativo) specifica il percorso di un file del certificato PEM dalla tua CA. Se il file di configurazione dell'autenticazione è ospitato in modo sicuro, puoi utilizzare una connessione HTTPS per accedere al file. Esempio: --login-config-cert my-cert.pem

   • USER_CLUSTER_KUBECONFIG (facoltativo) specifica il percorso personalizzato per il file kubeconfig del tuo cluster utente. I token ID OIDC restituiti dal tuo provider OpenID sono memorizzati nel file kubeconfig.

     Utilizza questo flag se il tuo file kubeconfig si trova in una posizione diversa da predefinita. Se questo flag viene omesso, viene creato un nuovo file kubeconfig nella località predefinita. Esempio: --kubeconfig /path/to/custom.kubeconfig

   Esempi:

   • Esegui l'autenticazione in un cluster specifico:

     gcloud anthos auth login --cluster my-production-cluster
     

   • Utilizza un prompt per selezionare il cluster con cui eseguire l'autenticazione:

     gcloud anthos auth login
     

     Risultato:

     Please use the --cluster flag to specify a cluster from the list below:
     Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
     1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
     2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
     3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
     

   • Utilizzare un file di configurazione dell'autenticazione ospitata:

     gcloud anthos auth login \
      --cluster my-production-cluster \
      --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
      --login-config-cert my-cert.pem
     

2. Inserisci le credenziali nella schermata di consenso basata sul browser che si apre.

3. Verifica che l'autenticazione sia riuscita eseguendo uno dei comandi kubectl per recuperare i dettagli del cluster. Ad esempio:

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Risultato: il tuo file kubeconfig ora contiene un token ID che i comandi kubectl verranno utilizzati per l'autenticazione con il server API Kubernetes sul tuo cluster utente.

Utilizzo di SSH per l'autenticazione da una macchina remota

Supponiamo di voler accedere tramite SSH a una macchina remota e di autenticarti a un cluster utente da una macchina remota. Per farlo, il file di configurazione di autenticazione deve trovarsi sul computer remoto e devi essere in grado di contattare il provider Open ID dalla tua macchina locale.

Sulla macchina locale, esegui il comando seguente:

ssh USER_NAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

dove:

• USER_NAME e REMOTE_MACHINE sono i valori standard utilizzati per accedere con SSH.

• LOCAL_PORT è una porta aperta di tua scelta sulla macchina locale che userai per accedere alla macchina remota.

• REMOTE_PORT è la porta configurata per l'URL di reindirizzamento OIDC. Puoi trovarlo nel campo kubectlRedirectURI del file di configurazione dell'autenticazione.

Nella shell SSH, esegui il comando seguente per avviare l'autenticazione:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

dove AUTH_CONFIG_FILE è il percorso del file di configurazione di autenticazione sulla macchina remota.

Sul computer locale, in un browser, vai alla pagina http://localhost:LOCAL_PORT/login e completa il flusso di accesso OIDC.

Ora il file kubeconfig sul tuo computer remoto dispone del token necessario per accedere al cluster utente.

Nella shell SSH, verifica di avere accesso al cluster utente:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Autenticazione tramite Google Cloud Console

Avvia il flusso di autenticazione dalla pagina Cluster Kubernetes in Google Cloud Console:

1. Apri Google Cloud Console:

   Visita la pagina Cluster Kubernetes

2. Individua i cluster Cluster Anthos su VMware nell'elenco e fai clic su Accedi.

3. Seleziona Autentica con il provider di identità configurato per il cluster, quindi fai clic su ACCEDI.

   Si aprirà il tuo provider di identità, dove potresti dover accedere o dare il tuo consenso alla console Google Cloud che accede al tuo account. Quindi verrai reindirizzato alla pagina Cluster Kubernetes in Google Cloud Console.

Risoluzione dei problemi di configurazione OIDC

Per risolvere i problemi OIDC, consulta i seguenti comportamenti ed errori:

Configurazione non valida

Se Google Cloud Console non riesce a leggere la configurazione OIDC dal cluster, il pulsante ACCESSO verrà disabilitato.

Configurazione del provider non valida

Se la configurazione del tuo provider di identità non è valida, verrà visualizzata una schermata di errore del provider di identità dopo aver fatto clic su ACCESSO. Segui le istruzioni specifiche del provider per configurare correttamente il provider o il cluster.

Autorizzazioni non valide

Se completi il flusso di autenticazione, ma continui a non vedere i dettagli del cluster, assicurati di aver concesso le autorizzazioni RBAC corrette all'account che hai utilizzato con OIDC. Tieni presente che questo potrebbe essere un account diverso da quello che utilizzi per accedere a Google Cloud Console.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Potresti visualizzare questo errore se il server di autorizzazione richiede il consenso, ma il parametro di autenticazione richiesto non è stato fornito. Fornisci il parametro prompt=consent ai cluster Anthos sul file di configurazione VMware sui file di configurazione oidc: extraparams e rigenera il file di autenticazione client con il flag --extra-params prompt=consent.

Passaggi successivi

• Scopri di più su ambiti e rivendicazioni.