Configura i cluster per GKE Identity Service con OIDC
Questo documento è rivolto agli amministratori di cluster o agli operatori di applicazioni che vogliono configurare GKE Identity Service su singoli cluster, consentendo agli sviluppatori e ad altri utenti di accedere ai cluster utilizzando i dettagli dell'identità esistenti da un provider OpenID Connect (OIDC). La guida presuppone che tu abbia letto la Panoramica di GKE Identity Service.
- Per scoprire come configurare GKE Identity Service per un cluster con un provider LDAP, vedi Configurare GKE Identity Service con LDAP.
- Per scoprire come configurare GKE Identity Service a livello di parco risorse per i tipi di cluster supportati, con la configurazione dell'autenticazione gestita da Google Cloud, consulta Configurare GKE Identity Service per un parco risorse.
Le istruzioni riportate in questo documento presuppongono che GKE Identity Service sia già stato registrato con il tuo provider di identità come applicazione client.
Panoramica della configurazione
La configurazione di GKE Identity Service per un singolo cluster prevede i seguenti utenti e passaggi:
- L'amministratore della piattaforma registra GKE Identity Service come applicazione client con il suo provider di identità preferito e ottiene un ID client e un secret. Per farlo, segui le istruzioni in Configurare i provider per il servizio di identità GKE.
- L'amministratore del cluster configura i cluster per l'utilizzo del servizio seguendo le istruzioni riportate in questa pagina.
- L'amministratore del cluster configura l'accesso degli utenti e, facoltativamente, configura il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per gli utenti nei cluster. Per farlo, segui le istruzioni riportate in Configurare l'accesso degli utenti per GKE Identity Service.
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 GKE.
- Per eseguire l'autenticazione tramite la console Google Cloud, ogni cluster che vuoi configurare per l'autenticazione OIDC deve essere registrato nel parco risorse di progetti.
Prima di iniziare
- Prima di iniziare la configurazione, assicurati che l'amministratore della piattaforma ti abbia fornito tutte le informazioni necessarie indicate in 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:
- La versione più recente 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 eseguire comandi sui cluster Kubernetes. Se devi installarekubectl
, segui queste instructions.
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti sono installati automaticamente.
- La versione più recente di Google Cloud CLI, che include
Assicurati di aver inizializzato gcloud CLI per utilizzarlo con il progetto in cui sono registrati i cluster.
Se devi connetterti al piano di controllo di un cluster AWS o Azure GKE che si trova all'esterno del VPC attuale tramite un bastion host, assicurati di aver creato il bastion host e avviato un tunnel SSH sulla porta 8118 prima di questa configurazione. Poi anteponi i comandi
kubectl
al comandoHTTPS_PROXY=http://localhost:8118
quando segui questa guida. Se hai utilizzato una porta diversa quando hai avviato il tunnel SSH, sostituisci8118
con la porta selezionata.
Configura i cluster
Per configurare i cluster in modo che utilizzino il provider scelto, GKE Identity Service richiede che tu specifichi i dettagli sul provider di identità, le informazioni nei token JWT che fornisce per l'identificazione degli utenti e altre informazioni fornite quando registri il servizio GKE Identity 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 tua configurazione avrà i seguenti campi corrispondenti:
issuerURI: 'https://server.example.com' userClaim: 'sub' groupsClaim: 'groupList' ...
L'amministratore della piattaforma, o chiunque gestisca l'identità all'interno della tua organizzazione, dovrebbe fornirti la maggior parte delle informazioni necessarie per creare la configurazione.
GKE Identity Service utilizza un tipo di risorsa personalizzata (CRD) Kubernetes denominata 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 della configurazione, seguendo le istruzioni riportate di seguito.
Puoi vedere alcune configurazioni di esempio specifiche per i provider più utilizzati in Configurazioni specifiche per i provider.
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 tuo 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.
...
La tabella seguente descrive i campi dell'oggetto oidc
ClientConfig. La maggior parte dei campi è facoltativa. I campi che devi aggiungere dipendono dal 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 |
---|---|---|---|
name | 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 singola riga. |
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 viene 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. Il valore predefinito è false . |
Booleano |
extraParams | No | Parametri chiave=valore aggiuntivi da inviare al provider 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) che il provider utilizza per restituire i gruppi di sicurezza di un account. | Stringa |
groupPrefix | No | Il prefisso che vuoi 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 in cui vengono effettuate le richieste di autorizzazione al tuo provider di identità. L'URI deve utilizzare HTTPS. | 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, generalmente 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) che il tuo provider utilizza per identificare un account utente. Se non specifichi alcun valore qui, GKE Identity Service utilizza "sub ", ovvero l'attestazione dello User-ID utilizzata da molti provider. Puoi scegliere altre attestazioni, ad esempio "email" o "nome", a seconda del provider OpenID. Le rivendicazioni diverse da "email" sono precedute dal prefisso dell'URL dell'emittente per evitare conflitti di denominazione. | Stringa |
userPrefix | No | Il prefisso che vuoi anteporre alle rivendicazioni degli utenti 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. In questo modo puoi utilizzare i gruppi di sicurezza per l'autorizzazione se hai un provider (come Okta) che fornisce attestazioni di gruppi da questo endpoint. Se non viene configurato, viene considerato false . |
Booleano |
proxy | No | Indirizzo del server proxy da utilizzare per connettersi al provider di identità, se applicabile. Potrebbe essere necessario impostare questa opzione se, ad esempio, il 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 provider
Questa sezione fornisce indicazioni sulla configurazione per alcuni provider OIDC più diffusi, 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 sulle iscrizioni a utenti e gruppi da Azure AD e consente di configurare il controllo degli controllo dell'accesso basato sui ruoli di Kubernetes (RBAC) in base ai gruppi. Tuttavia, l'uso di questa configurazione limita il recupero di circa 200 gruppi per utente.
Se devi recuperare più di 200 gruppi per utente, consulta le istruzioni per Azure AD (Advanced).
...
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 del tenant per gli account che appartengono a un tenant specifico. Il nome del tenant è anche noto come dominio principale. Per maggiori dettagli 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 tua 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 della 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. Potrebbe essere necessario impostare questa opzione se, ad esempio, il 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 del tenant per gli account che appartengono a un tenant specifico. Il nome del tenant è anche noto come dominio principale. Per maggiori dettagli 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 tua piattaforma al momento della registrazione.
- GROUP_FORMAT: il formato in cui vuoi recuperare le informazioni del gruppo. Questo campo può assumere valori corrispondenti a
ID
oNAME
dei gruppi di utenti. Tieni presente che questa impostazione è attualmente disponibile solo per i cluster Google Distributed Cloud Virtual for Bare Metal. - USER_CLAIM (facoltativo): la rivendicazione JWT (nome del campo) che il tuo fornitore utilizza per identificare un account. Se non specifichi alcun valore qui, GKE Identity Service utilizza un valore dell'ordine "email", "preferred_username" o "sub" per recuperare i dettagli dell'utente. Questo attributo può essere utilizzato da GKE Enterprise versione 1.28.
Okta
Di seguito viene mostrato come configurare l'autenticazione utilizzando sia utenti che gruppi con Okta come provider di identità. Questa configurazione consente al servizio Anthos Identity di recuperare le rivendicazioni 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 per i gruppi
Per gli utenti Okta, Anthos Identity Service può recuperare informazioni sui gruppi per gli utenti i cui nomi di gruppi, se concatenati, hanno una lunghezza inferiore a 170.000 caratteri. Ciò corrisponde a un'appartenenza di circa 650 gruppi data la lunghezza massima del gruppo di Okta. Se l'utente è membro di troppi gruppi, la chiamata di autenticazione non va a buon fine.
Che cosa succede dopo?
Dopo aver applicato la configurazione, continua a configurare l'accesso degli utenti ai cluster.