Utilizzare provider di identità esterni per autenticarsi in GKE


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

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

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti di autenticazione e OpenID:

Metodi di autenticazione IdP esterni in GKE

Consigliato: federazione delle identità della forza lavoro

La federazione delle identità della forza lavoro è una funzionalità IAM che consente di autenticarsi su Google Cloud da qualsiasi IdP esterno che supporti OIDC o SAML 2.0. La federazione delle identità per la forza lavoro non richiede alcuna installazione nel cluster, funziona con i cluster Autopilot e standard ed è integrata in Google Cloud. Per maggiori dettagli, consulta la documentazione di IAM sulla federazione delle identità per la forza lavoro.

Sconsigliato: 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à, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Considerazioni

I sistemi headless non sono supportati sia con la federazione delle identità per la forza lavoro che con Identity Service for GKE. Un flusso di autenticazione basato sul browser ti chiede 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 cluster GKE, procedi nel seguente modo:

  1. Configura la federazione delle identità per la forza lavoro per la tua organizzazione e l'IdP esterno. Per istruzioni, vedi Configurare la federazione delle identità per la forza lavoro.
  2. Configura l'accesso dal tuo IdP esterno alla Google Cloud console della federazione delle identità della forza lavoro. Per maggiori dettagli, consulta Configurare l'accesso utente alla console (federato).
  3. Configura l'accesso utente utilizzando uno dei seguenti meccanismi di autorizzazione:

  4. Chiedi ai tuoi utenti di accedere ai cluster completando i seguenti passaggi:

    1. Accedi a gcloud CLI con l'identità federata.
    2. Configura kubectl per l'autenticazione a un cluster specifico eseguendo gcloud container clusters get-credentials.

Configurare l'accesso degli utenti ai cluster utilizzando RBAC

Google Cloud utilizza gli identificatori principal per identificare gli utenti nei tuoi pool di identità della forza lavoro. Puoi fare riferimento a questi identificatori delle entità nelle tue policy RBAC di Kubernetes o nelle policy IAM. Puoi concedere autorizzazioni a singoli utenti o gruppi di utenti, come nei seguenti esempi:

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'asserzione del soggetto del token di identità. Ad esempio, potrebbe essere il valore del campo NameID in un'asserzione 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 l'utente che esegue l'autenticazione è membro. L'asserzione 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 dalla federazione delle identità per la forza lavoro, consulta Rappresentare gli utenti del pool di forza lavoro nei criteri IAM.

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

  1. 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à a cui associ questo ClusterRole può visualizzare i secret.

  2. 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".

  3. Esegui il deployment di ClusterRole e ClusterRoleBinding:

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

Accedi al cluster e autenticati

  1. Chiedi all'utente di accedere utilizzando Google Cloud CLI per Google Cloud.
  2. L'utente può configurare kubectl per l'autenticazione al cluster utilizzando quanto segue:

    gcloud container clusters get-credentials
    

Esegui la migrazione dei cluster Identity Service for GKE alla federazione delle identità per la forza lavoro

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 tabella seguente:

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:

  1. Configura la federazione delle identità per la forza lavoro per la tua organizzazione e l'IdP esterno. Per istruzioni, vedi Configurare la federazione delle identità per la forza lavoro.

  2. Aggiorna i manifest per qualsiasi RoleBinding e ClusterRoleBinding nei tuoi cluster in modo che utilizzino 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 README del repository GoogleCloudPlatform/gke-utilities.

      Questa utilità trova i binding RBAC esistenti che utilizzano la sintassi di Identity Service per GKE e crea nuovi manifest che utilizzano gli identificatori delle entità della federazione delle identità della forza lavoro corrispondenti.

    • Aggiornamenti manuali: per ogni binding 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.

  3. Applica i manifest aggiornati per RoleBinding e ClusterRoleBinding al tuo cluster.

  4. Verifica che gli utenti possano accedere alle stesse risorse quando eseguono l'autenticazione utilizzando la federazione delle identità per la forza lavoro.

  5. Rimuovi i binding RBAC obsoleti dal cluster.

  6. Disabilita Identity Service for GKE.

Utilizzare Identity Service for GKE

Per configurare e utilizzare Identity Service per GKE sul cluster in modalità GKE Standard, gli amministratori del cluster procedono nel seguente modo:

  1. Abilita Identity Service per GKE su un cluster.
  2. Configura Identity Service for GKE.
  3. Crea una policy RBAC per il cluster.

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

Oggetti Kubernetes creati da Identity Service for GKE

La tabella seguente descrive gli oggetti Kubernetes creati quando abiliti Identity Service per GKE su 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 VPC 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 bilanciatore del carico gke-oidc-envoy. Comunica con gke-oidc-service per convalidare i token ID. Funge da proxy per il server API Kubernetes e rappresenta gli utenti quando trasmette 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 controllo dell'ammissione per le risorse ClientConfig.
Creato nello spazio dei nomi anthos-identity-service.
gke-oidc-operator Deployment
Riconcilia la configurazione del client e il gke-oidc-envoy bilanciatore del carico.
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 bilanciatore del carico.
Creato nello spazio dei nomi anthos-identity-service
default ClientConfig CRD
Contiene parametri OIDC come il metodo di autenticazione preferito, la configurazione del provider di identità e i mapping delle rivendicazioni di utenti e gruppi. Utilizzato per la convalida del token ID. 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 Google Cloud CLI.

Abilita Identity Service per GKE su 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.

Configura Identity Service for GKE

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

  1. Scarica il file ClientConfig:default

    kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
    
  2. 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 un insieme di radici pubbliche per impostazione predefinita.
    • 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 a cui inviare le richieste di autorizzazione OIDC, 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. Per Cloud Identity, utilizza https://accounts.google.com.
    • KUBECTL_REDIRECT_URL: l'URL di reindirizzamento che kubectl oidc login utilizza per l'autorizzazione. In genere ha il formato http://localhost:PORT/callback, dove PORT è una porta maggiore di 1024 che sarà disponibile sulle workstation degli sviluppatori, ad esempio http://localhost:10000/callback. Devi registrare l'URL con il tuo provider OIDC come URL di reindirizzamento autorizzato per l'applicazione client. Se utilizzi Google Identity come provider OIDC, leggi 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: la rivendicazione dell'utente dal token di identità.
    • GROUPS: l'attestazione del gruppo dal token di identità.
    • USER_PREFIX: prefisso anteposto alle attestazioni utente per evitare conflitti con i nomi esistenti. Per impostazione predefinita, al userID fornito al server API Kubernetes viene aggiunto un prefisso dell'emittente (a meno che l'attestazione 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.
  3. 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.

  4. Crea una copia del file di configurazione client-config.yaml:

    cp client-config.yaml login-config.yaml
    
  5. 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.

  6. Distribuisci il file login-config.yaml aggiornato agli sviluppatori.

Configura Identity Service for GKE sui cluster con criteri rigorosi

Per configurare Identity Service for GKE in modo che funzioni come previsto sui cluster che hanno policy di rete rigorose, procedi nel seguente modo:

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

La versione 0.2.20 e successive del componente Identity Service per GKE non utilizza la porta TCP 15000. Se la versione del componente è 0.2.20 o successiva, non è necessario aggiungere una regola firewall per la porta 15000. Per controllare la versione del componente, esegui questo 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 annotazioni e proprietà 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 dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere l'accesso agli utenti del cluster autenticati. Per configurare RBAC per il tuo cluster, devi concedere ruoli RBAC per ogni sviluppatore. Per concedere l'accesso alle risorse in uno spazio dei nomi specifico, crea un ruolo e un RoleBinding. Per concedere l'accesso alle risorse in un intero cluster, crea un ClusterRole e un ClusterRoleBinding.

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

  1. Salva il seguente manifest ClusterRole come secret-viewer-cluster-role.yaml. Una persona a cui viene concesso questo ruolo può ottenere, 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"]
    
  2. Applica il manifest ClusterRole:

    kubectl apply -f secret-viewer-cluster-role.yaml
    
  3. Salva il seguente manifest ClusterRoleBinding come secret-viewer-cluster-role-binding.yaml. Il binding concede il ruolo secret-viewer a un nome utente definito nel file di configurazione 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 dell'attestazione configurato in spec.authentication.oidc.userClaim nel file di configurazione del client.
  4. Applica il manifest ClusterRoleBinding:

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

Accedi al cluster e autenticati

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

  1. Scarica il file login-config.yaml fornito dal tuo amministratore.

  2. Installa l'SDK Google Cloud CLI, che offre un componente OIDC separato. Puoi installarlo eseguendo il seguente comando:

    gcloud components install kubectl-oidc
    
  3. 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.

  4. Una volta autenticato, puoi eseguire i comandi kubectl, ad esempio:

    kubectl get pods
    

Disabilita Identity Service per GKE

Puoi disabilitare Identity Service for GKE con gcloud CLI. Per disabilitare Identity Service per GKE, esegui questo comando:

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

Passaggi successivi