Il prodotto descritto in questa documentazione, Anthos Clusters on AWS (generazione precedente), è ora in modalità di manutenzione. Tutte le nuove installazioni devono utilizzare l'attuale prodotto di generazione, Cluster Anthos on AWS.

Questa pagina è stata tradotta dall'API Cloud Translation.

Autenticazione con OpenID Connect (OIDC)

Scopri come configurare GKE su AWS per utilizzare OpenID Connect (OIDC) per l'autenticazione nei cluster utente. Questo argomento descrive la procedura per configurare GKE su AWS con qualsiasi provider OpenID.

Per eseguire l'upgrade di un cluster che utilizza l'autenticazione OIDC a Kubernetes 1.21, vedi Eseguire l'upgrade alla versione 1.21.

Per una panoramica del flusso di autenticazione di GKE su AWS, vedi Autenticazione.

Panoramica

GKE su AWS supporta OIDC come uno dei meccanismi di autenticazione per interagire con il server API Kubernetes di un cluster utente. Con OIDC, puoi gestire l'accesso ai cluster Kubernetes utilizzando le procedure standard della tua organizzazione per creare, attivare e disattivare gli account utente.

Prima di iniziare

Questo argomento presuppone che tu abbia familiarità con i seguenti concetti di autenticazione e OpenID:
Google Cloud CLI deve essere installata sulla macchina locale di ogni sviluppatore.
I sistemi headless non sono supportati. Per l'autenticazione, devi aprire un browser sulla macchina locale che esegue gcloud CLI. Il browser ti chiede quindi di autorizzare il tuo account utente.
Per eseguire l'autenticazione 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 buyer persona:

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 dell'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.

Scegliere un provider OpenID

Questa sezione è rivolta agli amministratori dell'organizzazione.

Puoi utilizzare qualsiasi provider OpenID a tua scelta. Per un elenco dei fornitori certificati, vedi Certificazione OpenID.

Creare URL di reindirizzamento

Questa sezione è rivolta agli amministratori dell'organizzazione.

Il provider OpenID utilizza gli URL di reindirizzamento per restituire i token ID. Devi creare URL di reindirizzamento sia per gcloud CLI sia per la consoleGoogle Cloud .

Imposta l'URL di reindirizzamento di gcloud CLI

Quando configuri il provider OpenID, specifica l'URL di reindirizzamento della CLI come http://localhost:PORT/callback

Sostituisci PORT con il numero di porta maggiore di 1024.

Imposta l'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 provider OIDC, specifica https://console.cloud.google.com/kubernetes/oidc come uno degli URL di reindirizzamento.

Registra le tue applicazioni client con il provider OpenID

Questa sezione è rivolta agli amministratori dell'organizzazione.

Prima che gli sviluppatori possano utilizzare Google Cloud CLI o la console Google Cloud con il tuo provider OpenID, devi registrare questi due client con il provider OpenID. La registrazione include i seguenti passaggi:

Scopri l'URI dell'emittente del tuo provider. gcloud CLI o la consoleGoogle Cloud inviano richieste di autenticazione a questo URI.
Configura il tuo provider con l'URL di reindirizzamento, incluso il numero di porta, per gcloud CLI.
Configura il tuo provider con l'URL di reindirizzamento per la console Google Cloud , https://console.cloud.google.com/kubernetes/oidc.
Crea un singolo ID client che il tuo provider utilizza per identificare sia Google Cloud CLI sia la consoleGoogle Cloud .
Crea un singolo secret client che gcloud CLI e la console Google Cloud utilizzano per l'autenticazione al provider OpenID.
Crea un ambito personalizzato che gcloud CLI o la console Google Cloud possono utilizzare per richiedere i gruppi di sicurezza dell'utente.
Crea un nome di attestazione personalizzato che il provider utilizza per restituire i gruppi di sicurezza dell'utente.

Configura il cluster

Questa sezione è rivolta agli amministratori del cluster.

Per configurare l'autenticazione OIDC, devi configurare la risorsa AWSCluster del cluster utente con i dettagli di autenticazione per un cluster. I dettagli di AWSCluster vengono utilizzati per configurare OIDC sia per la console Google Cloud che per il plug-in di autenticazione per GKE. La configurazione include le seguenti informazioni OIDC:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Campi di autenticazione

La tabella seguente descrive i campi dell'oggetto authentication.awsIAM.adminIdentityARNs.

La tabella seguente descrive i campi dell'oggetto `oidc`.

Campo	Obbligatorio	Descrizione	Formato
adminIdentityARNs	Sì, se configuri OIDC.	Amazon Resource Name (ARN) delle identità IAM AWS (utenti o ruoli) a cui GKE su AWS ha concesso l'accesso amministratore cluster. Esempio: `arn:aws:iam::123456789012:group/Developers`	Stringa

Campo	Obbligatorio	Descrizione	Formato
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 riga singola. Esempio: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	Stringa
clientID	Sì	ID per l'applicazione client che effettua richieste di autenticazione al provider OpenID.	Stringa
clientSecret	No	Secret condiviso tra applicazione client OIDC e provider OIDC.	Stringa
extraParams	No	Parametri coppia chiave-valore aggiuntivi da inviare al provider OpenID. Se stai autorizzando un gruppo, inserisci `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
groupsClaim	No	Attestazione JWT utilizzata dal provider per restituire i tuoi gruppi di sicurezza.	Stringa
groupPrefix	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-` in modo che il gruppo risultante sia `gid-foobar`.	Stringa
issuerURI	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 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
userClaim	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
userPrefix	No	Prefisso anteposto alle attestazioni dei nomi utente per evitare conflitti con i nomi esistenti.	Stringa

Esempio: autorizzazione di utenti e gruppi

Molti fornitori codificano le proprietà di identificazione dell'utente, come l'email e gli ID utente, in un token. Tuttavia, queste proprietà comportano rischi impliciti per le norme di autenticazione:

Gli ID utente possono rendere difficili da leggere e controllare i criteri.
L'utilizzo di indirizzi email può creare sia un rischio di disponibilità (se un utente modifica la sua email principale) sia un rischio per la sicurezza (se un'email può essere riassegnata).

Anziché assegnare ID utente, consigliamo le policy di gruppo, che possono essere sia persistenti sia più facili da controllare.

Supponiamo che il tuo provider crei token ID che includono i seguenti campi:

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

Dato questo formato del token, devi compilare la specifica oidc del file di configurazione nel seguente modo:

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

Dopo aver creato il cluster utente, utilizzi il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere l'accesso privilegiato agli utenti autenticati.

Nell'esempio seguente, crei un ClusterRole che concede ai suoi utenti l'accesso in sola lettura ai secret del cluster e crei una risorsa ClusterRoleBinding per associare il ruolo al gruppo autenticato.

Definisci un ClusterRole. Copia il seguente codice YAML in un file denominato secret-reader-role.yaml.

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"]

Definisci un ClusterRoleBinding. Copia il seguente codice YAML in un file denominato secret-reader-admins.yaml.

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

Applica secret-reader-role.yaml e secret-reader-admins.yaml al tuo cluster con kubectl.
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml
```
Gli utenti a cui è stato concesso l'accesso in read-secrets-admins ora possono leggere i secret nel tuo cluster.

Crea una configurazione di accesso

Questa sezione è rivolta agli amministratori del cluster.

Dopo aver creato un cluster utente, devi generare un file di configurazione per il cluster utilizzando gcloud anthos create-login-config.

Dalla directory anthos-aws, utilizza anthos-gke per passare al contesto del cluster utente.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
Sostituisci CLUSTER_NAME con il nome del cluster utente.
Crea la configurazione con gcloud anthos.
```
gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
```
Sostituisci usercluster-kubeconfig con il percorso del file kubeconfig del cluster utente. Su Linux e macOS, per impostazione predefinita questo file si trova in ~/.kube/config.

Questo comando genera un file (kubectl-anthos-config.yaml) contenente le informazioni di configurazione utilizzate dagli sviluppatori per l'autenticazione al cluster con gcloud CLI. Non modificare questo file.

Per saperne di più sui contenuti di kubectl-anthos-config.yaml, consulta l'appendice.

Distribuisci il file di configurazione agli utenti che devono autenticarsi ai tuoi cluster utente. Puoi distribuire la configurazione:

Posizionamento del file nella directory predefinita.
Distribuire il file in modo sicuro.
Ospitare il file su un server HTTPS.

Directory predefinite di configurazione dell'accesso

Le posizioni predefinite per l'archiviazione del file di configurazione per ogni sistema operativo sono le seguenti:

Linux: $HOME/.config/google/anthos/kubectl-anthos-config.yaml, dove $HOME è la home directory dell'utente.
macOS: $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, dove $HOME è la home directory dell'utente.
Windows: %APPDATA%/google/anthos/kubectl-anthos-config.yaml, dove %APPDATA% è la directory dei dati dell'applicazione dell'utente.

Una volta distribuita la configurazione di accesso, gli sviluppatori sono pronti a configurare gcloud CLI per accedere al cluster.

Modifica il cluster dopo l'upgrade a Kubernetes 1.21

Dopo aver eseguito l'upgrade del cluster a Kubernetes 1.21, devi configurare GKE Identity Service e rimuovere le informazioni OIDC dalla configurazione del cluster. Per aggiornare la configurazione, segui questi passaggi:

Segui i passaggi descritti in Esegui l'upgrade del cluster.
Dalla directory anthos-aws, utilizza anthos-gke per passare al contesto del cluster utente.
```
cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
```
Sostituisci CLUSTER_NAME con il nome del cluster utente.
Apri il manifest che contiene AWSCluster in un editor di testo. Tieni aperto il file e utilizza i valori dell'oggetto oidc per seguire i passaggi descritti in Configurazione dei cluster per GKE Identity Service.
Dalla directory anthos-aws, utilizza anthos-gke per passare al servizio di gestione.
```
cd anthos-aws
anthos-gke aws management get-credentials
```
Nota: anthos-gke utilizza le credenziali che hai specificato quando hai eseguito aws configure.
Apri il file YAML che ha creato il tuo AWSCluster in un editor di testo. Se non hai il file YAML iniziale, puoi utilizzare kubectl edit.
Modifica YAML
Se hai seguito le istruzioni riportate in Creazione di un cluster utente, il file YAML si chiama cluster-0.yaml. Apri questo file in un editor di testo.
kubectl edit
Per utilizzare kubectl edit per modificare il tuo AWSCluster, esegui il seguente comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name
```
Sostituisci cluster-name con il tuo AWSCluster. Ad esempio, per modificare il cluster predefinito, cluster-0, esegui questo comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0
```
Elimina l'oggetto oidc dal manifest del cluster.
Salva il file. Se utilizzi kubectl edit, kubectl applica le modifiche automaticamente. Se stai modificando il file YAML, applicalo al tuo servizio di gestione con il seguente comando:
```
env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml
```
Il servizio di gestione aggiorna quindi AWSCluster.

Configurazione di gcloud per accedere al cluster

Questa sezione è rivolta a sviluppatori o amministratori di cluster.

Prerequisiti

Per completare questa sezione, devi:

Una configurazione di accesso.

Una versione aggiornata di gcloud CLI con i componenti anthos-auth.

gcloud components update
gcloud components install anthos-auth

Verifica che gcloud CLI sia stata installata correttamente eseguendo il seguente comando, che dovrebbe rispondere con i dettagli sugli argomenti obbligatori e sulle opzioni disponibili.
```
gcloud anthos auth
```

Esegui l'autenticazione sul cluster

Puoi autenticarti al cluster nei seguenti modi:

Con la gcloud CLI sulla tua macchina locale.
Con gcloud CLI su una macchina remota utilizzando un tunnel SSH.
Connettiti alla console Google Cloud .

gcloud local

Utilizza gcloud anthos auth login per autenticarti al cluster con la configurazione di accesso.

Se hai inserito la configurazione di accesso nella posizione predefinita e hai configurato il nome del cluster, puoi utilizzare gcloud anthos auth login senza opzioni. Puoi anche configurare il cluster, l'utente e altri dettagli di autenticazione con parametri facoltativi.

Predefinito

gcloud anthos auth login --cluster CLUSTER_NAME

Sostituisci CLUSTER_NAME con un nome del cluster completo. Ad esempio, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

Parametri facoltativi

gcloud anthos auth login supporta i seguenti parametri facoltativi:

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

I parametri sono descritti nella tabella seguente.

Parametro	Descrizione
`cluster`	Il nome del cluster a cui eseguire l'autenticazione. Il valore predefinito è il cluster in `kubectl-anthos-config.yaml`.
`user`	Nome utente per le credenziali in `kubeconfig`. Il valore predefinito è `{cluster-name}-anthos-default-user`.
`login-config`	Il percorso del file di configurazione generato dall'amministratore del cluster per lo sviluppatore o un URL che ospita il file. Il valore predefinito è `kubectl-anthos-config.yaml`.
`login-config-cert`	Se utilizzi un URL per `login-config`, il percorso del file del certificato CA per stabilire connessioni HTTPS.
`kubeconfig`	Percorso del file kubeconfig contenente i token. Il valore predefinito è $HOME/.kube/config`.
dry-run	Testa le opzioni della riga di comando senza modificare la configurazione o il cluster.

Il comando gcloud anthos login avvia un browser che chiede all'utente di accedere con le proprie credenziali aziendali, esegue lo scambio di credenziali OIDC e acquisisce i token pertinenti. gcloud CLI scrive i token in un file kubeconfig. kubectl utilizza questo file per autenticarsi al cluster utente.

Per verificare che l'autenticazione sia andata a buon fine, esegui un comando kubectl con il file kubeconfig:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud tunnel

Se vuoi autenticarti in un cluster utente da una macchina remota, puoi eseguire l'autenticazione utilizzando un tunnel SSH. Per utilizzare un tunnel, il file di configurazione dell'autenticazione deve trovarsi sulla macchina remota e devi essere in grado di raggiungere il tuo provider OpenID dalla macchina locale.

Sulla tua macchina locale, esegui questo comando:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Sostituisci quanto segue:

USERNAME con un utente che ha accesso SSH alla macchina remota.
REMOTE_MACHINE con il nome host o l'indirizzo IP della macchina remota.
LOCAL_PORT è una porta disponibile sulla tua macchina locale che ssh utilizza per il tunneling alla macchina remota.
REMOTE_PORT è la porta che hai configurato per l'URL di reindirizzamento OIDC. Il numero di porta fa parte del campo kubectlRedirectURI del file di configurazione dell'autenticazione.

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

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Sostituisci AUTH_CONFIG_FILE con il percorso del file di configurazione dell'autenticazione sulla macchina remota. gcloud CLI esegue un server web sulla macchina remota.

Sulla tua macchina locale, in un browser, vai alla pagina http://localhost:LOCAL_PORT/login e segui il flusso di accesso OIDC.

Il file kubeconfig sulla macchina remota ora contiene il token per accedere al cluster utente.

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Console

Puoi eseguire l'autenticazione con la console Google Cloud , avviare il flusso di autenticazione dalla pagina dei cluster Kubernetes nella console Google Cloud :

Apri la console Google Cloud :

Vai alla pagina dei cluster Kubernetes
Individua il tuo cluster GKE su AWS nell'elenco e fai clic su Login.
Seleziona Esegui l'autenticazione con il provider di identità configurato per il cluster e poi fai clic su ACCEDI.

Viene visualizzato il tuo provider di identità, dove potresti dover accedere o acconsentire all'accesso della console Google Cloud al tuo account. Viene visualizzata di nuovo la pagina Cluster Kubernetes nella console Google Cloud .

Aggiornamento della configurazione OIDC

Per aggiornare la configurazione OIDC sul cluster, utilizza il comando kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

Lo strumento kubectl carica la risorsa ClientConfig nell'editor predefinito. Per aggiornare la configurazione, salva il file. Lo strumento kubectl aggiorna la risorsa ClientConfig sul cluster.

Per informazioni sui contenuti della risorsa ClientConfig, consulta la sezione seguente.

Appendice: Esempio di configurazione di accesso

Di seguito è riportato un esempio kubectl-anthos-config.yaml. Questo esempio è incluso per comprendere i suoi contenuti. Devi sempre generare il file con gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Per le spiegazioni dei contenuti dei campi, vedi Campi di autenticazione.

Passaggi successivi

Esegui il deployment del tuo primo workload su GKE su AWS.

Autenticazione con OpenID Connect (OIDC) Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica

Prima di iniziare

Utenti tipo

Scegliere un provider OpenID

Creare URL di reindirizzamento

Imposta l'URL di reindirizzamento di gcloud CLI

Imposta l'URL di reindirizzamento della console Google Cloud

Registra le tue applicazioni client con il provider OpenID

Configura il cluster

Campi di autenticazione

Esempio: autorizzazione di utenti e gruppi

Crea una configurazione di accesso

Distribuire la configurazione di accesso

Directory predefinite di configurazione dell'accesso

Modifica il cluster dopo l'upgrade a Kubernetes 1.21

Modifica YAML

kubectl edit

Configurazione di gcloud per accedere al cluster

Prerequisiti

Esegui l'autenticazione sul cluster

gcloud local

Predefinito

Parametri facoltativi

gcloud tunnel

Console

Aggiornamento della configurazione OIDC

Appendice: Esempio di configurazione di accesso

Passaggi successivi

Autenticazione con OpenID Connect (OIDC)