Questa pagina è stata tradotta dall'API Cloud Translation.

Configura i cluster per GKE Identity Service con OIDC

Questo documento è destinato agli amministratori dei cluster o agli operatori delle applicazioni che vogliono configurare GKE Identity Service su singoli cluster, consentendo a sviluppatori e altri utenti di accedere ai cluster utilizzando i dettagli dell'identità esistenti di un provider OpenID Connect (OIDC).

Prerequisiti

Il cluster deve essere un cluster GKE on-premise (VMware o bare metal), su AWS o su Azure. La configurazione OIDC per cluster non è supportata per i cluster collegati o i cluster GKE.
Per l'autenticazione tramite la console Google Cloud , ogni cluster che vuoi configurare per l'autenticazione OIDC deve essere registrato nel parco risorse del tuo progetto.

Prima di iniziare

Prima di iniziare la configurazione, assicurati che l'amministratore della piattaforma ti abbia fornito tutte le informazioni necessarie da Registra GKE Identity Service con il tuo provider, inclusi l'ID client e il secret per GKE Identity Service.
Assicurati di aver installato i seguenti strumenti a riga di comando:
- L'ultima versione di Google Cloud CLI, che include gcloud, lo strumento a riga di comando per interagire con Google Cloud. Se devi installare Google Cloud CLI, consulta la guida all'installazione.
- kubectl per l'esecuzione di comandi sui cluster Kubernetes. Se devi installare kubectl, segui queste istruzioni.
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati automaticamente.
Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il progetto in cui sono registrati i cluster.
Se devi connetterti al control plane di un cluster GKE AWS o Azure che si trova al di fuori del tuo VPC attuale tramite un bastion host, assicurati di aver creato il bastion host e di aver avviato un tunnel SSH sulla porta 8118 prima di questa configurazione. Quindi, anteponi HTTPS_PROXY=http://localhost:8118 ai comandi kubectl quando segui questa guida. Se hai utilizzato una porta diversa all'avvio del tunnel SSH, sostituisci 8118 con la porta selezionata.

Configura i cluster

Per configurare i cluster in modo che utilizzino il provider scelto, GKE Identity Service richiede di specificare i dettagli sul provider di identità, le informazioni nei token JWT che fornisce per l'identificazione dell'utente e altre informazioni fornite quando registri GKE Identity Service come applicazione client.

Ad esempio, se il tuo provider crea token di identità con i seguenti campi (tra gli altri), dove iss è l'URI del provider di identità, sub identifica l'utente e groupList elenca i gruppi di sicurezza a cui appartiene l'utente:

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

...la configurazione avrà i seguenti campi corrispondenti:

issuerURI: 'https://server.example.com'
userClaim: 'sub'
groupsClaim: 'groupList'
...

L'amministratore della piattaforma o chiunque gestisca l'identità nella tua organizzazione dovrebbe fornirti la maggior parte delle informazioni necessarie per creare la configurazione.

GKE Identity Service utilizza un tipo di risorsa personalizzata Kubernetes (CRD) denominato ClientConfig per la configurazione del cluster, con campi per tutte le informazioni necessarie a GKE Identity Service per interagire con il provider di identità. Ogni cluster GKE ha una risorsa ClientConfig denominata default nello spazio dei nomi kube-public che aggiorni con i dettagli di configurazione, seguendo le istruzioni riportate di seguito.

Puoi visualizzare alcune configurazioni di esempio specifiche per i fornitori più comuni in Configurazioni specifiche per il fornitore.

kubectl

Per modificare il ClientConfig predefinito, assicurati di poterti connettere al cluster tramite kubectl ed esegui questo comando:

kubectl --kubeconfig=KUBECONFIG_PATH edit ClientConfigs default -n kube-public

Sostituisci KUBECONFIG_PATH con il percorso del file kubeconfig del cluster, ad esempio $HOME/.kube/config.

Un editor di testo carica la risorsa ClientConfig del cluster. Aggiungi l'oggetto spec.authentication.oidc come mostrato di seguito. Non modificare i dati predefiniti già scritti.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
      enableAccessToken: ENABLE_ACCESS_TOKEN
    proxy: PROXY_URL

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Puoi configurare più provider di identità in ClientConfig in base ai tuoi requisiti. Ciò semplifica la gestione e offre flessibilità, consentendoti di configurare diversi metodi di autenticazione all'interno di una risorsa di configurazione unificata. L'esempio seguente ClientConfig definisce più provider di identità nell'ordine richiesto di precedenza dell'autenticazione.

apiVersion: v1
items:
- apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
...
  spec:
    authentication:
    - aws:
        region: us-west-2
      name: AWS Login
    - ldap:
    ...
    - saml:
      ...
    - azureAD:
      ...
    - oidc:
      name: Okta OIDC
      ...
    -oidc:
      name: Google OIDC
      ...

La tabella seguente descrive i campi dell'oggetto ClientConfig oidc. La maggior parte dei campi è facoltativa. I campi da aggiungere dipendono dal tuo provider di identità e dalle opzioni di configurazione scelte dall'amministratore della piattaforma durante la configurazione del provider per GKE Identity Service.

Campo	Obbligatorio	Descrizione	Formato
nome	sì	Il nome che vuoi utilizzare per identificare questa configurazione, in genere il nome del provider di identità. Il nome di una configurazione deve iniziare con una lettera seguita da un massimo di 39 lettere minuscole, numeri o trattini e non può terminare con un trattino.	Stringa
certificateAuthorityData	No	Se fornita dall'amministratore della piattaforma, una stringa di certificato con codifica PEM per il provider di identità. Includi la stringa risultante in `certificateAuthorityData` come riga singola.	Stringa
clientID	Sì	L'ID client restituito durante la registrazione di GKE Identity Service con il tuo provider OIDC.	Stringa
clientSecret	No	Secret condiviso tra l'applicazione client OIDC e il provider OIDC.	Stringa
deployCloudConsoleProxy	No	Specifica se è stato eseguito il deployment di un proxy che consente alla console Google Cloud di connettersi a un provider di identità on-premise non accessibile pubblicamente su internet. Per impostazione predefinita, questo valore è impostato su `false`.	Booleano
extraParams	No	Parametri chiave=valore aggiuntivi da inviare al fornitore di identità, specificati come elenco separato da virgole, ad esempio `prompt=consent,access_type=offline`.	Elenco delimitato da virgole
groupsClaim	No	L'attestazione JWT (nome del campo) utilizzata dal provider per restituire i gruppi di sicurezza di un account.	Stringa
groupPrefix	No	Il prefisso da anteporre ai nomi dei gruppi di sicurezza per evitare conflitti con i nomi esistenti nelle regole di controllo dell'accesso#39;accesso se hai configurazioni per più provider di identità (in genere il nome del provider).	Stringa
issuerURI	Sì	L'URI a cui vengono effettuate le richieste di autorizzazione al tuo provider di identità. L'URI deve utilizzare HTTPS e non deve terminare con una barra finale.	Stringa URL
kubectlRedirectURI	Sì	L'URL di reindirizzamento e la porta utilizzati da gcloud CLI e specificati dall'amministratore della piattaforma al momento della registrazione, in genere nel formato `http://localhost:PORT/callback`.	Stringa URL
ambiti	Sì	Ambiti aggiuntivi da inviare al provider OpenID. Ad esempio, Microsoft Azure e Okta richiedono l'ambito `offline_access`.	Elenco delimitato da virgole
userClaim	No	L'attestazione JWT (nome del campo) utilizzata dal provider per identificare un account utente. Se non specifichi un valore qui, GKE Identity Service utilizza "sub", ovvero l'attestazione dell'ID utente utilizzata da molti provider. Puoi scegliere altre attestazioni, ad esempio "email" o "nome", a seconda del provider OpenID. Alle attestazioni diverse da "email" viene aggiunto come prefisso l'URL dell'emittente per evitare conflitti di denominazione.	Stringa
userPrefix	No	Il prefisso da anteporre alle attestazioni utente per evitare conflitti con i nomi esistenti, se non vuoi utilizzare il prefisso predefinito.	Stringa
enableAccessToken	No	Se abilitato, GKE Identity Service può utilizzare l'endpoint userinfo del provider di identità per ottenere informazioni sui gruppi quando un utente accede dalla riga di comando. Ciò ti consente di utilizzare i gruppi di sicurezza per l'autorizzazione se hai un provider (come Okta) che fornisce rivendicazioni di gruppi da questo endpoint. Se non è impostato, viene considerato `false`.	Booleano
proxy	No	Indirizzo del server proxy da utilizzare per connettersi al provider di identità, se applicabile. Potresti dover impostare questo valore se, ad esempio, il tuo cluster si trova in una rete privata e deve connettersi a un provider di identità pubblico. Ad esempio: `http://user:password@10.10.10.10:8888`.	Stringa

Dopo aver completato ClientConfig, salva il file, che aggiorna ClientConfig sul cluster. Se commetti errori di sintassi, ti viene chiesto di modificare nuovamente la configurazione per correggerli.

Configurazioni specifiche del fornitore

Questa sezione fornisce indicazioni sulla configurazione per alcuni provider OIDC popolari, incluse configurazioni di esempio che puoi copiare e modificare con i tuoi dettagli.

Azure AD

Questa è la configurazione predefinita per configurare GKE Identity Service con Azure AD. L'utilizzo di questa configurazione consente a GKE Identity Service di ottenere informazioni sull'appartenenza a utenti e gruppi da Azure AD e di configurare il controllo degli controllo dell'accesso basato su ruoli (RBAC) di Kubernetes in base ai gruppi. Tuttavia, l'utilizzo di questa configurazione ti consente di recuperare circa 200 gruppi per utente.

Se devi recuperare più di 200 gruppi per utente, consulta le istruzioni per Azure AD (avanzato).

...
spec:
  authentication:
  - name: oidc-azuread
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      extraParams: prompt=consent, access_type=offline
      issuerURI: https://login.microsoftonline.com/TENANT_ID/v2.0
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: openid,email,offline_access
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Sostituisci quanto segue:

CLIENT_ID: l'ID client restituito durante la registrazione di GKE Identity Service con il tuo provider.
CLIENT_SECRET: secret condiviso tra l'applicazione client OIDC e il provider OIDC.
TENANT: Il tipo di account Azure AD da autenticare. I valori supportati sono l'ID tenant o il nome tenant per gli account che appartengono a un tenant specifico. Il nome del tenant è noto anche come dominio principale. Per informazioni dettagliate su come trovare questi valori, vedi Trovare l'ID tenant e il nome di dominio principale di Microsoft Azure AD.
PORT: il numero di porta scelto per l'URL di reindirizzamento utilizzato da gcloud CLI, specificato dall'amministratore della piattaforma al momento della registrazione.

Azure AD (avanzato)

Questa configurazione facoltativa per Azure AD consente a GKE Identity Service di recuperare le informazioni su utenti e gruppi senza limiti al numero di gruppi per utente, utilizzando l'API Microsoft Graph.

Per informazioni sulle piattaforme che supportano questa configurazione, vedi Configurazione avanzata per Azure AD.

Se devi recuperare meno di 200 gruppi per utente, ti consigliamo di utilizzare la configurazione predefinita con un ancoraggio oidc in ClientConfig. Per ulteriori informazioni, consulta le istruzioni per Azure AD.

Tutti i campi nella seguente configurazione di esempio sono obbligatori.

...
spec:
  authentication:
  - name: NAME
    proxy: PROXY_URL
    azureAD:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      tenant: TENANT_ID
      kubectlRedirectURI: http://localhost:PORT/callback
      groupFormat: GROUP_FORMAT
      userClaim: USER_CLAIM

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Sostituisci quanto segue:

NAME: il nome che vuoi utilizzare per identificare questa configurazione, in genere il nome del provider di identità. Il nome di una configurazione deve iniziare con una lettera seguita da un massimo di 39 lettere minuscole, numeri o trattini e non può terminare con un trattino.
PROXY_URL: Indirizzo del server proxy da utilizzare per connettersi al provider di identità, se applicabile. Potresti dover impostare questo valore se, ad esempio, il tuo cluster si trova in una rete privata e deve connettersi a un provider di identità pubblico. Ad esempio: http://user:password@10.10.10.10:8888.
CLIENT_ID: l'ID client restituito durante la registrazione di GKE Identity Service con il tuo provider.
CLIENT_SECRET: secret condiviso tra l'applicazione client OIDC e il provider OIDC.
TENANT: Il tipo di account Azure AD da autenticare. I valori supportati sono l'ID tenant o il nome tenant per gli account che appartengono a un tenant specifico. Il nome del tenant è noto anche come dominio principale. Per informazioni dettagliate su come trovare questi valori, vedi Trovare l'ID tenant e il nome di dominio principale di Microsoft Azure AD.
PORT: il numero di porta scelto per l'URL di reindirizzamento utilizzato da gcloud CLI, specificato dall'amministratore della piattaforma al momento della registrazione.
GROUP_FORMAT: il formato in cui vuoi recuperare le informazioni sul gruppo. Questo campo può assumere valori corrispondenti a ID o NAME dei gruppi di utenti. Tieni presente che questa impostazione è attualmente disponibile solo per i cluster nelle implementazioni Google Distributed Cloud bare metal.
(Facoltativo) USER_CLAIM: l'attestazione JWT (nome del campo) utilizzata dal tuo fornitore per identificare un account. Se non specifichi un valore qui, GKE Identity Service utilizza un valore nell'ordine di "email", "preferred_username" o "sub" per recuperare i dettagli dell'utente. Questo attributo può essere utilizzato a partire dalla versione 1.28 di GKE Enterprise.

Okta

Di seguito viene illustrato come configurare l'autenticazione utilizzando sia utenti che gruppi con Okta come provider di identità. Questa configurazione consente ad Anthos Identity Service di recuperare le attestazioni di utenti e gruppi utilizzando un token di accesso e l'endpoint userinfo di Okta.

...
spec:
  authentication:
  - name: okta
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      enableAccessToken: true
      extraParams: prompt=consent
      groupsClaim: groups
      issuerURI: https://OKTA_ISSUER_URI/
      kubectlRedirectURI: http://localhost:PORT/callback
      scopes: offline_access,email,profile,groups
      userClaim: email

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Limiti di accesso al gruppo

Per gli utenti Okta, Anthos Identity Service può recuperare le informazioni sui gruppi per gli utenti i cui nomi di gruppo, se concatenati, hanno una lunghezza inferiore a 170.000 caratteri. Ciò corrisponde a un'appartenenza a circa 650 gruppi, data la lunghezza massima dei gruppi di Okta. Se l'utente è membro di troppi gruppi, la chiamata di autenticazione non va a buon fine.

Passaggi successivi

Una volta applicata la configurazione, continua a configurare l'accesso degli utenti ai cluster.