Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizzare provider di identità esterni per l'autenticazione in GKE

Autopilota Standard

Questa pagina mostra come configurare l'autenticazione ai cluster Google Kubernetes Engine (GKE) da provider di identità esterni (IdP).

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma, nonché agli amministratori di identità e account che utilizzano un provider di identità esterno che supporta OpenID Connect (OIDC) o Security Assertion Markup Language (SAML) 2.0.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti di autenticazione e OpenID:

Metodi di autenticazione di IdP esterni in GKE

Consigliato: Federazione delle identità per la forza lavoro

La federazione delle identità della forza lavoro è una funzionalità IAM che ti consente di autenticarti in Google Cloud da qualsiasi provider di identità esterno che supporta OIDC o SAML 2.0. La federazione delle identità della forza lavoro non richiede alcuna installazione all'interno del cluster, funziona con i cluster Autopilot e i cluster standard ed è integrata in Google Cloud. Per maggiori dettagli, consulta la documentazione di IAM sulla federazione delle identità per la forza lavoro.

Non consigliato: Identity Service for GKE

Solo nei cluster GKE Standard, GKE supporta anche Identity Service for GKE. Identity Service per GKE è limitato ai provider di identità OIDC e installa componenti aggiuntivi nel cluster. GKE consiglia vivamente di utilizzare la federazione delle identità della forza lavoro anziché Identity Service for GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Considerazioni

I sistemi headless non sono supportati sia con Workforce Identity Federation sia con Identity Service for GKE. Un flusso di autenticazione basato su browser ti chiede di fornire il consenso e di autorizzare il tuo account utente.

Utilizzare la federazione delle identità per la forza lavoro in GKE

Per utilizzare la federazione delle identità per la forza lavoro nei tuoi cluster GKE, svolgi quanto segue:

Configura la federazione delle identità per la forza lavoro per la tua organizzazione e per l'IdP esterno. Per le istruzioni, consulta Configurare la federazione delle identità per la forza lavoro.
Configura l'accesso dal tuo IdP esterno alla Google Cloud console Workforce Identity Federation. Per maggiori dettagli, consulta Configurare l'accesso degli utenti alla console (federata).
Configura l'accesso utente utilizzando uno dei seguenti meccanismi di autorizzazione:
- Kubernetes RBAC
- Criteri di autorizzazione IAM

Configurare l'accesso degli utenti ai cluster utilizzando RBAC

Google Cloud utilizza gli identificatori principali per identificare gli utenti nei pool di identità della forza lavoro. Puoi fare riferimento a questi identificatori delle entità nei criteri RBAC di Kubernetes o nei criteri IAM. Puoi assegnare autorizzazioni a singoli utenti o gruppi di utenti, ad esempio nei seguenti esempi:

Identità Identificatore entità

Utente singolo

Identità	Identificatore entità
Utente singolo	principal://iam.googleapis.com/locations/global/workforcePools/`WORKFORCE_IDENTITY_POOL`/subject/`SUBJECT_ATTRIBUTE_VALUE` Sostituisci quanto segue: `WORKFORCE_IDENTITY_POOL`: il nome del pool di identità della forza lavoro. `SUBJECT_ATTRIBUTE_VALUE`: il valore di un attributo nell'affermazione sull'oggetto del token di identità. Ad esempio, potrebbe essere il valore del campo `NameID` in un'affermazione SAML 2.0. Ad esempio: principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
Tutti gli utenti di un gruppo	principalSet://iam.googleapis.com/locations/global/workforcePools/`WORKFORCE_IDENTITY_POOL`/group/`GROUP_NAME` Sostituisci quanto segue: `WORKFORCE_IDENTITY_POOL`: il nome del pool di identità della forza lavoro. `GROUP_NAME`: il nome di un gruppo di cui fa parte l'utente che esegue l'autenticazione. L'affermazione nel token IdP deve avere una mappatura degli attributi all'attributo Google Cloud `google.groups`. Ad esempio: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Sostituisci quanto segue:

WORKFORCE_IDENTITY_POOL: il nome del pool di identità della forza lavoro.
SUBJECT_ATTRIBUTE_VALUE: il valore di un attributo nell'affermazione sull'oggetto del token di identità. Ad esempio, potrebbe essere il valore del campo NameID in un'affermazione SAML 2.0.

Ad esempio:

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com

Tutti gli utenti di un gruppo

principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

Sostituisci quanto segue:

WORKFORCE_IDENTITY_POOL: il nome del pool di identità della forza lavoro.
GROUP_NAME: il nome di un gruppo di cui fa parte l'utente che esegue l'autenticazione. L'affermazione nel token IdP deve avere una mappatura degli attributi all'attributo Google Cloud google.groups.

Ad esempio:

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Per ogni identificatore principale supportato da Workforce Identity Federation, consulta Rappresentare gli utenti del pool della forza lavoro nei criteri IAM.

L'esempio seguente mostra come concedere l'accesso in sola lettura a livello di cluster ai segreti per tutte le entità del pool di forza lavoro full-time-employees che hanno l'attributo access_level="sensitive" nel token IdP.

Salva il seguente manifest ClusterRole come secret-viewer-cluster-role.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Qualsiasi entità principale a cui leghi questo ClusterRole può visualizzare i secret.

Salva il seguente manifest ClusterRoleBinding come secret-viewer-cluster-role-binding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  users-view-secrets
subjects:
- kind: Group
  name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/attribute.access_level/sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

Questo ClusterRoleBinding concede il ClusterRole secret-viewer a qualsiasi utente che dispone dell'attributo access_level="sensitive".

Esegui il deployment di ClusterRole e ClusterRoleBinding:

kubectl apply -f secret-viewer-cluster-role.yaml
kubectl apply -f secret-viewer-cluster-role-binding.yaml

Esegui la migrazione dei cluster Identity Service for GKE a Workforce Identity Federation

Se utilizzi Identity Service for GKE nei cluster GKE esistenti, esegui la migrazione a Workforce Identity Federation. Questi metodi utilizzano sintassi diverse per fare riferimento agli stessi principali, come mostrato nella seguente tabella:

Sintassi di Identity Service for GKE	Sintassi della federazione delle identità per la forza lavoro
`amal@example.com`	`principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com`
`sre-group`	`principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group`

Per eseguire la migrazione di un cluster in modo che utilizzi la federazione delle identità della forza lavoro:

Configura la federazione delle identità per la forza lavoro per la tua organizzazione e per l'IdP esterno. Per le istruzioni, consulta Configurare la federazione delle identità per la forza lavoro.
Aggiorna i manifest per eventuali RoleBinding e ClusterRoleBindings nei tuoi cluster in modo da utilizzare la sintassi dell'identificatore della federazione delle identità per la forza lavoro. Utilizza una delle seguenti opzioni:
- Aggiornamenti programmatici: installa ed esegui l'utilitàgke-identity-service-migrator. Per istruzioni, consulta il file GoogleCloudPlatform/gke-utilities README del repository.
  
  Questa utility trova le associazioni RBAC esistenti che utilizzano la sintassi del servizio di identità per GKE e crea nuovi manifest che utilizzano gli identificatori principali della federazione delle identità della forza lavoro corrispondenti.
- Aggiornamenti manuali: per ogni associazione che fa riferimento a un utente o un gruppo autenticato, crea una copia separata del file manifest dell'oggetto che utilizza la sintassi dell'identificatore di Workforce Identity Federation.
Applica i manifest aggiornati per RoleBinding e ClusterRoleBindings al tuo cluster.
Verifica che gli utenti possano accedere alle stesse risorse quando si autenticano utilizzando la federazione delle identità della forza lavoro.
Rimuovi le associazioni RBAC obsolete dal cluster.
Disattiva Identity Service for GKE.

Utilizzare Identity Service for GKE

Per configurare e utilizzare Identity Service per GKE nel tuo cluster GKE in modalità standard, gli amministratori del cluster devono svolgere i seguenti passaggi:

Abilita Identity Service per GKE su un cluster.
Configura Identity Service for GKE.
Crea un criterio RBAC per il cluster.

Dopo che gli amministratori del cluster hanno configurato Identity Service per GKE, gli sviluppatori possono accedere e autenticarsi nel cluster.

Oggetti Kubernetes creati da Identity Service for GKE

La tabella seguente descrive gli oggetti Kubernetes creati quando attivi Identity Service per GKE in un cluster:

Oggetti Kubernetes
`anthos-identity-service`	`Namespace` Utilizzato per i deployment di Identity Service for GKE.
`kube-public`	`Namespace` Utilizzato per il file di configurazione del client `default`.
`gke-oidc-envoy`	`LoadBalancer` L'endpoint per le richieste OIDC. Esterno per impostazione predefinita. Se creato in un cluster senza endpoint IP esterno, l'endpoint è interno al Virtual Private Cloud del cluster. Creato nello spazio dei nomi `anthos-identity-service`.
`gke-oidc-service`	`ClusterIP` Facilita la comunicazione tra il deployment `gke-oidc-envoy` e il deployment `gke-oidc-service`. Creato nello spazio dei nomi `anthos-identity-service`.
`gke-oidc-envoy`	`Deployment` Esegue un proxy esposto al `gke-oidc-envoy` bilanciatore del carico. Comunica con `gke-oidc-service` per convalidare i token di identità. Agisce da proxy per il server API Kubernetes e ruba l'identità degli utenti quando inoltra le richieste al server API. Creato nello spazio dei nomi `anthos-identity-service`.
`gke-oidc-service`	`Deployment` Convalida i token di identità e fornisce un webhook di ammissione convalidante per le risorse `ClientConfig`. Creato nello spazio dei nomi `anthos-identity-service`.
`gke-oidc-operator`	`Deployment` Riconcilia la configurazione del client e il bilanciatore del carico `gke-oidc-envoy`. Creato nello spazio dei nomi `anthos-identity-service`.
`gke-oidc-certs`	`Secret` Contiene l'autorità di certificazione (CA) del cluster e i certificati TLS per il LoadBalancer. Creato nello spazio dei nomi `anthos-identity-service`
`default`	`ClientConfig CRD` Contiene i parametri OIDC, come il metodo di autenticazione preferito, la configurazione del provider di identità e le mappature delle attestazioni di utenti e gruppi. Utilizzato per la convalida del token di identità. Utilizzato dagli amministratori del cluster per configurare le impostazioni OIDC prima della distribuzione agli sviluppatori. Creato nello spazio dei nomi `kube-public`

Abilita Identity Service per GKE su un cluster

Per impostazione predefinita, Identity and Access Management (IAM) è configurato come provider di identità per l'autenticazione del cluster. Se vuoi utilizzare OIDC con provider di identità di terze parti, puoi attivare Identity Service per GKE su cluster nuovi o esistenti utilizzando il client Google Cloud.

Abilita Identity Service per GKE in un nuovo cluster

Per creare un cluster con Identity Service for GKE abilitato, esegui il seguente comando:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Sostituisci CLUSTER_NAME con il nome del nuovo cluster.

Abilita Identity Service per GKE su un cluster esistente

Per abilitare Identity Service per GKE in un cluster esistente, esegui il seguente comando:

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Sostituisci CLUSTER_NAME con il nome del cluster.

Configurare Identity Service for GKE

Puoi configurare i parametri di Identity Service for GKE scaricando e modificando default ClientConfig.

Scarica il file ClientConfig default:

kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

Aggiorna la sezione spec.authentication con le impostazioni che preferisci:
```
apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  name: cluster-name
  server: https://192.168.0.1:6443
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_ID
      certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
      extraParams: EXTRA_PARAMS
      issuerURI:  ISSUER_URI
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      kubectlRedirectURI: KUBECTL_REDIRECT_URL
      scopes: SCOPES
      userClaim: USER
      groupsClaim: GROUPS
      userPrefix: USER_PREFIX
      groupPrefix: GROUP_PREFIX
```
Sostituisci quanto segue:
- CLIENT_ID: l'ID dell'applicazione client che effettua richieste di autenticazione al provider OIDC.
- OIDC_PROVIDER_CERTIFICATE: (Facoltativo) un certificato PEM per il provider OIDC. Questo campo potrebbe essere utile se il tuo provider OIDC utilizza certificati autofirmati. Identity Service for GKE include per impostazione predefinita un insieme di radici pubbliche.
- EXTRA_PARAMS: parametri coppia chiave-valore aggiuntivi da inviare al provider OIDC.
  - Per autorizzare i gruppi, utilizza resource=token-groups-claim.
  - Per autenticare Microsoft Azure e Okta, utilizza prompt=consent.
  - Per Cloud Identity, utilizza prompt=consent,access_type=offline.
- ISSUER_URI: l'URL per inviare richieste di autorizzazione OIDC, ad esempio https://example.com/adfs. Il server API Kubernetes utilizza questo URL per scoprire le chiavi pubbliche per la verifica dei token. L'URI deve utilizzare HTTPS. Per Cloud Identity, utilizza https://accounts.google.com.
- KUBECTL_REDIRECT_URL: l'URL di reindirizzamento utilizzato da kubectl oidc login per l'autorizzazione. In genere è nel formato http://localhost:PORT/callback, dove PORT è qualsiasi porta maggiore di 1024 che sarà disponibile sulle workstation degli sviluppatori, ad esempio http://localhost:10000/callback. Devi registrare l'URL con il tuo fornitore OIDC come URL di reindirizzamento autorizzato per l'applicazione client. Se utilizzi l'identità Google come provider OIDC, consulta Impostare un URI di reindirizzamento per istruzioni.
- SCOPES: gli ambiti aggiuntivi da inviare al provider OIDC.
  - Microsoft Azure e Okta richiedono l'ambito offline_access.
  - Per Cloud Identity, utilizza openid, email per ottenere token ID che contengono l'indirizzo email nella rivendicazione email.
- USER: l'affermazione utente dal token di identità.
- GROUPS: l'affermazione del gruppo dal token di identità.
- USER_PREFIX: prefisso anteposto alle attestazioni degli utenti per evitare conflitti con i nomi esistenti. Per impostazione predefinita, un prefisso dell'emittente viene aggiunto al userID assegnato al server API Kubernetes (a meno che la rivendicazione utente non sia email). L'identificatore utente risultante è ISSUER_URI#USER. Ti consigliamo di utilizzare un prefisso, ma puoi disattivarlo impostando USER_PREFIX su -.
- GROUP_PREFIX: 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.
Applica la configurazione aggiornata:
```
kubectl apply -f client-config.yaml
```
Dopo aver applicato questa configurazione, Identity Service per GKE viene eseguito all'interno del cluster e gestisce le richieste dietro il bilanciatore del carico gke-oidc-envoy. L'indirizzo IP nel campo spec.server deve essere l'indirizzo IP del bilanciatore del carico. Se modifichi il campo spec.server, i comandi kubectl potrebbero non riuscire.
Crea una copia del file di configurazione client-config.yaml:
```
cp client-config.yaml login-config.yaml
```
Aggiorna il file di configurazione login-config.yaml con l'impostazione clientSecret nella sezione spec.authentication.oidc.
```
clientSecret: CLIENT_SECRET
```
Sostituisci CLIENT_SECRET con il secret condiviso tra l'applicazione client OIDC e il provider OIDC.
Distribuisci il file login-config.yaml aggiornato agli sviluppatori.

Configurare Identity Service for GKE su cluster con criteri rigidi

Per configurare Identity Service per GKE in modo che funzioni come previsto nei cluster con criteri di rete rigidi, segui questi passaggi:

Aggiungi una regola firewall per la porta TCP 15000 per consentire al tuo control plane di comunicare con il webhook di convalida ClientConfig.
Se gke-oidc-envoy viene creato come bilanciatore del carico interno, esponilo nel tuo VPC.
Se hai criteri che negano il traffico all'interno del cluster, aggiungi una regola firewall per la porta TCP 8443 per consentire al deployment gke-oidc-envoy di comunicare con il deployment gke-oidc-service.

Il componente Identity Service per GKE versione 0.2.20 e successive non utilizza la porta TCP 15000. Se la versione del componente è 0.2.20 o successiva, non è necessario aggiungere una regola del firewall per la porta 15000. Per controllare la versione del componente, esegui il seguente comando:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Aggiungere proprietà personalizzate al bilanciatore del carico

Dopo aver configurato Identity Service for GKE, puoi aggiungere proprietà e annotazioni personalizzate, ad esempio un indirizzo IP statico, al bilanciatore del carico gke-oidc-envoy. Per modificare il servizio gke-oidc-envoy, esegui questo comando:

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Consulta Parametri del servizio LoadBalancer per saperne di più sulla configurazione del bilanciamento del carico TCP/UDP per GKE.

Crea un criterio RBAC per il cluster

Gli amministratori possono utilizzare il controllo degli accessi basato su ruoli (RBAC) di Kubernetes per concedere l'accesso agli utenti del cluster autenticati. Per configurare il RBAC per il tuo cluster, devi concedere i ruoli RBAC a ogni sviluppatore. Per concedere accesso alle risorse in un determinato spazio dei nomi, crea un ruolo e un RoleBinding. Per concedere l'accesso alle risorse di un intero cluster, crea un ClusterRole e un ClusterRoleBinding.

Ad esempio, prendi in considerazione un utente che deve visualizzare tutti gli oggetti Secret nel cluster. I passaggi che seguono concedono a questo utente i ruoli RBAC richiesti.

Salva il seguente manifest ClusterRole come secret-viewer-cluster-role.yaml. Una persona a cui è stato concesso questo ruolo può recuperare, guardare ed elencare qualsiasi secret nel cluster.

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

Applica il manifest ClusterRole:

kubectl apply -f secret-viewer-cluster-role.yaml

Salva il seguente manifest ClusterRoleBinding come secret-viewer-cluster-role-binding.yaml. La definizione del vincolo assegna il ruolo secret-viewer a un nome utente definito nel file di configurazione del client.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  people-who-view-secrets
subjects:
- kind: User
  name: ISSUER_URI#USER
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io
```
Sostituisci quanto segue:
- ISSUER_URI: l'URI dell'emittente da spec.authentication.oidc.issuerURI nel file di configurazione del client.
- USER: l'identificatore utente nel token sotto il nome del claim configurato in spec.authentication.oidc.userClaim nel file di configurazione del client.

Applica il manifest ClusterRoleBinding:

kubectl apply -f secret-viewer-cluster-role-binding.yaml

Accedi e autenticati nel cluster

In qualità di sviluppatore che riceve il file di configurazione OIDC dall'amministratore, puoi autenticarti nei tuoi cluster.

Scarica il file login-config.yaml fornito dall'amministratore.
Installa l'SDK Google Cloud CLI, che offre un componente OIDC distinto. Per installarlo, esegui il seguente comando:
```
gcloud components install kubectl-oidc
```
Esegui l'autenticazione nel cluster:
```
kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
```
Si apre un browser web per completare la procedura di autenticazione.
Dopo l'autenticazione, puoi eseguire i comandi kubectl, ad esempio:
```
kubectl get pods
```

Disabilitare Identity Service per GKE

Puoi disattivare Identity Service for GKE con la CLI gcloud. Per disattivare Identity Service per GKE, esegui il seguente comando:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Passaggi successivi

Scopri di più sulla federazione delle identità per la forza lavoro.
Scopri di più sul deployment dei carichi di lavoro.