Autenticazione con OIDC e AD FS

Scopri come configurare OpenID Connect (OIDC) con Active Directory Federation Services (AD FS) in cluster Anthos su Bare Metal.

In questo argomento, il server Active Directory Federation Services è configurato come provider OpenID e Active Directory viene utilizzato come database utente.

Per una panoramica dei cluster Anthos sul flusso di autenticazione bare metal, consulta Autenticazione. Consulta gli argomenti seguenti per scoprire come configurare OIDC con altri provider OpenID:

Panoramica

I cluster Anthos su Bare Metal supportano OIDC come uno dei meccanismi di autenticazione per interagire con un server API Kubernetes di un cluster. 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:

  • Per completare i passaggi in questo argomento, devi avere un server AD FS e un database utente Active Directory esistenti.

  • OIDC è supportato solo in AD FS versione 2016 e successive.

  • Dovresti essere a conoscenza dei seguenti comportamenti in AD FS:

    • Nelle versioni AD FS precedenti alla 5.0, l'attributo LDAP Token-Groups Qualified Names nel database Active Directory è mappato alla rivendicazione groups. Nella versione 5.0 e successive, l'attributo è Token-Groups Qualified by Domain name.

    • Il server AD FS restituisce token che includono ID utente, ID emittente, rivendicazione openid e rivendicazione groups. La rivendicazione groups (Group in 5.0) elenca i gruppi di sicurezza a cui appartiene l'utente.

  • 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 organizzazione: questa persona sceglie un provider OpenID e registra le applicazioni client con il provider.

  • Amministratore cluster: questa persona crea uno o più cluster 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.

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 sia 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 e include l'interfaccia a riga di comando gcloud. Puoi specificare un numero di porta superiore a 1024 da utilizzare per l'URL di reindirizzamento:

http://localhost:[PORT]/callback

dove [PORT] è il tuo numero di porta.

Quando configuri il server AD FS, specifica http://localhost:[PORT]/callback come uno degli URL di reindirizzamento.

URL di reindirizzamento della console Google Cloud

L'URL di reindirizzamento per Google Cloud Console è:

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

Quando configuri il server AD FS, specifica https://console.cloud.google.com/kubernetes/oidc come uno degli URL di reindirizzamento.

Configurazione di AD FS

Questa sezione è rivolta agli amministratori dell'organizzazione.

Utilizza un insieme di procedure guidate di gestione di AD FS per configurare il server AD FS e il database degli utenti di AD.

  1. Apri il riquadro di gestione di AD FS.

  2. Seleziona Gruppi di applicazioni > Azioni > Aggiungi un gruppo di applicazioni.

  3. Seleziona Server Application. Inserisci un nome e una descrizione scelti da te. Fai clic su Avanti.

  4. Inserisci i tuoi due URL di reindirizzamento. Ti viene fornito un ID client. Ecco come il server AD FS identifica l'interfaccia a riga di comando gcloud e Google Cloud Console. Salva l'ID client per un secondo momento.

  5. Seleziona Genera un secret condiviso. L'interfaccia a riga di comando gcloud e Google Cloud Console utilizzano questo secret per eseguire l'autenticazione sul server AD FS. Salva il secret per un secondo momento.

Configurare i gruppi di sicurezza (facoltativo)

Questa sezione è rivolta agli amministratori dell'organizzazione.

  1. Nella gestione di AD FS, seleziona Affidabilità di parte del partner > Aggiungi un nuovo trust di parte affidabile.

  2. Seleziona Rivendicazioni sensibili e fai clic su Avvia.

  3. Seleziona Inserisci i dati sull'affidamento manuale del soggetto.

  4. Inserisci un nome visualizzato.

  5. Salta i due passaggi successivi.

  6. Inserisci un identificatore di attendibilità componente. Suggerimento: token-groups-claim.

  7. In Criterio di controllo dell'accesso, seleziona Consenti tutti. Questo significa che tutti gli utenti condividono le informazioni del loro gruppo di sicurezza con l'interfaccia a riga di comando gcloud e Google Cloud Console.

  8. Fai clic su Fine.

Mappatura degli attributi LDAP ai nomi delle rivendicazioni

Questa sezione è rivolta agli amministratori dell'organizzazione.

  1. Nella gestione di AD FS, seleziona Affidabilità ai partiti attendibili > Edit policy riemissione di norme.

  2. Seleziona Invia attributi LDAP come rivendicazioni, quindi fai clic su Avanti.

  3. In Nome regola rivendicazione, inserisci groups.

  4. In Archivio attributi, seleziona Active Directory.

  5. Nella tabella, per Attributo LDAP, seleziona:

    • AD FS versione 5.0 e successive: Gruppi di token qualificati in base al nome di dominio
    • Versioni AD FS precedenti alla 5.0: Gruppi di token - Nomi qualificati

  6. In Tipo di rivendicazione in uscita, seleziona:

    • AD FS 5.0 e versioni successive: Gruppo
    • Versioni AD FS precedenti alla 5.0: gruppi

  7. Fai clic su Fine e poi su Applica.

Registrazione dell'interfaccia a riga di comando gcloud e di Google Cloud Console con AD FS

Questa sezione è rivolta agli amministratori dell'organizzazione.

Apri una finestra di PowerShell in modalità Amministratore e inserisci questo comando:

Grant-AD FSApplicationPermission `
    -ClientRoleIdentifier "[CLIENT_ID]" `
    -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
    -ScopeName "allatclaims", "openid"

dove:

  • [CLIENT_ID] è l'ID client ottenuto in precedenza.

  • [SERVER_ROLE_IDENTIFIER] è l'identificatore della rivendicazione che hai inserito in precedenza. Ricorda che l'identificatore suggerito era token-groups-claim.

Completa la specifica oidc nei cluster Anthos sul file di configurazione Bare Metal

Questa sezione è rivolta agli amministratori del cluster.

Prima di creare un cluster, generi un cluster Anthos su un file di configurazione Bare Metal utilizzando bmctl create config. La configurazione include la seguente specifica oidc. Devi compilare oidc con i valori specifici del tuo provider:

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:
  • issuerURL: obbligatorio. URL del tuo provider OpenID, ad esempio https://example.com/adfs. Le applicazioni client, come l'interfaccia a riga di comando gcloud e Google Cloud Console, inviano le richieste di autorizzazione a questo URL. Il server API di Kubernetes utilizza questo URL per scoprire le chiavi pubbliche per la verifica dei token. È necessario utilizzare HTTPS.
  • kubectlRedirectURL: obbligatorio. L'URL di reindirizzamento che hai configurato in precedenza per l'interfaccia a riga di comando gcloud.
  • clientID: obbligatorio. ID dell'applicazione client che invia le richieste di autenticazione al provider OpenID. Sia l'interfaccia a riga di comando gcloud sia la console Google Cloud utilizzano questo ID.
  • clientSecret: facoltativo. Secret per l'applicazione client. Sia l'interfaccia a riga di comando gcloud che Google Cloud Console utilizzano questo secret.
  • username: facoltativo. Attestazione JWT da utilizzare come nome utente. Il valore predefinito è sub, che dovrebbe essere un identificatore univoco dell'utente finale. Puoi scegliere altre attestazioni, ad esempio email o name, a seconda del provider OpenID. Tuttavia, alle attestazioni diverse da email viene aggiunto come prefisso l'URL dell'emittente per evitare conflitti di denominazione con altri plug-in.
  • usernamePrefix: facoltativo. Prefisso anteposto alle attestazioni dei nomi utente per evitare conflitti con i nomi esistenti. Se non specifichi questo campo e username è un valore diverso da email, il valore predefinito del prefisso è issuerurl#. Puoi utilizzare il valore - per disattivare tutti i prefissi.
  • group: facoltativo. Attestazione JWT che il provider utilizzerà per restituire i tuoi gruppi di sicurezza.
  • groupPrefix: facoltativo. Prefisso anteposto alle attestazioni dei gruppi per evitare conflitti con i nomi esistenti. Ad esempio, dato un gruppo foobar e un prefisso gid-, gid-foobar. Per impostazione predefinita, il valore è vuoto e non esiste un prefisso.
  • scopes: facoltativo. Ambiti aggiuntivi da inviare al provider OpenID come elenco delimitato da virgole.
    • Per l'autenticazione con Microsoft Azure, passa il offline_access.

  • extraParams: facoltativo. Parametri coppia chiave-valore aggiuntivi da inviare al provider OpenID come elenco delimitato da virgole.

  • proxy: facoltativo. A partire dai cluster Anthos su Bare Metal 1.6.1, puoi specificare un server proxy da utilizzare affinché il cluster si connetta al tuo provider OIDC, se applicabile. Ad esempio: http://user:password@10.10.10.10:8888. Se il campo viene lasciato vuoto, per impostazione predefinita non viene usato alcun proxy.

  • deployCloudConsoleProxy: facoltativo. Specifica se eseguire il deployment di un proxy inverso nel cluster per consentire a Google Cloud Console di accedere al provider OIDC on-premise per l'autenticazione degli utenti. Se il tuo provider di identità non è raggiungibile sulla rete Internet pubblica e vuoi eseguire l'autenticazione utilizzando Google Cloud Console, questo campo deve essere impostato su true.

  • certificateAuthorityData: facoltativo. Un certificato di autorità di certificazione con codifica PEM base64 del tuo provider OIDC. Per creare la stringa codifica il certificato, incluse le intestazioni, in formato base64. Includi la stringa risultante in certificateAuthorityData come singola riga. Esempio: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==. Questo valore potrebbe non essere necessario. Ad esempio, se il certificato del tuo provider di identità è stato emesso da una nota CA pubblica, non dovrai fornire un valore qui. Tuttavia, se deployCloudConsoleProxy è true, questo valore deve essere fornito, anche per un'autorità di certificazione pubblica nota.

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'indirizzo email principale) sia un rischio per la sicurezza (se un'email può essere riassegnata).

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

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

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Considerato il formato del token, dovrai completare la specifica del file di configurazione oidc, ad esempio:

issueruri: 'https://server.example.com'
username: 'sub'
usernameprefix: 'uid-'
group: 'groupList'
groupprefix: 'gid-'
extraparams: 'resource=token-groups-claim'
...

Dopo aver creato il cluster, 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 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

Installazione dell'interfaccia a riga di comando gcloud

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

Gli amministratori del cluster che vogliono creare file di configurazione dell'autenticazione del cluster e ogni sviluppatore o utente che deve eseguire l'autenticazione con un cluster deve installare Google Cloud CLI sul proprio computer. I comandi di autenticazione Anthos sono stati integrati nell'interfaccia a riga di comando gcloud come 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:

  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.

Creazione e distribuzione del file di configurazione dell'autenticazione

Questa sezione è rivolta agli amministratori del cluster.

Dopo aver creato un cluster, 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 gcloud seguente:

gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]

dove [CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del tuo cluster. Quando hai eseguito bmctl create cluster per creare il tuo cluster, è 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 in un file di configurazione di autenticazione esistente. Dato che esiste un file di configurazione dell'autenticazione esistente, puoi unire o combinare altri dettagli di autenticazione del cluster:

  • Unisci i dettagli aggiuntivi dell'autenticazione del cluster nel file di configurazione dell'autenticazione esistente.
  • Combina i dettagli aggiuntivi di autenticazione del cluster 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 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 gcloud seguente per unire o combinare i dettagli di configurazione:

    gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \
--merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

    dove

    • [CLUSTER_KUBECONFIG] specifica il file kubeconfig del cluster 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 sui tuoi cluster, 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.

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

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 [CLUSTER_KUBECONFIG]

    dove:

    • [CLUSTER_NAME] (facoltativo) specifica il nome del cluster. Se questo flag viene omesso, ti verrà chiesto di scegliere tra i cluster 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

    • [CLUSTER_KUBECONFIG] (facoltativo) specifica il percorso personalizzato per il file kubeconfig del tuo cluster. 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 [CLUSTER_KUBECONFIG]

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

Utilizzo di SSH per l'autenticazione da una macchina remota

Supponi di volere usare SSH per connetterti a una macchina remota ed eseguirne l'autenticazione in un cluster da quest'ultima. 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.

Nella shell SSH, verifica di avere accesso al cluster:

kubectl --kubeconfig [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 Anthos su cluster Bare Metal nell'elenco, quindi fai clic su Accedi.

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

    Si viene reindirizzati al provider di identità, dove potresti dover accedere o dare il tuo consenso affinché Google Cloud Console acceda al tuo account. Successivamente, ti reindirizzeremo 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 campo oidc: extraparams del file di configurazione Bare Metal e rigenera il file di autenticazione client con il flag --extra-params prompt=consent.

Passaggi successivi