Scopri come configurare GKE su AWS in modo da utilizzare OpenID Connect (OIDC) per l'autenticazione ai cluster utente. Questo argomento illustra 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, consulta Eseguire l'upgrade a 1.21.
Per una panoramica del flusso di autenticazione di GKE su AWS, consulta 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:
L'interfaccia a riga di comando Google Cloud deve essere installata sulla macchina locale di ogni sviluppatore.
I sistemi headless non sono supportati. Per autenticarti, devi aprire un browser sulla macchina locale su cui è in esecuzione gcloud CLI. Il browser ti chiede di autorizzare il tuo account utente.
Per eseguire l'autenticazione tramite la Google Cloud console, ogni cluster che vuoi configurare per l'autenticazione OIDC deve essere registrato in Google Cloud.
Utenti tipo
Questo argomento fa riferimento a tre persone:
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.
Scegli un provider OpenID
Questa sezione è rivolta agli amministratori dell'organizzazione.
Puoi utilizzare qualsiasi provider OpenID a tua scelta. Per un elenco dei fornitori certificati, consulta la 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 .
Impostare l'URL di reindirizzamento della gcloud CLI
Quando configuri il provider OpenID, specifica l'URL di reindirizzamento della CLI comehttp://localhost:PORT/callback
Sostituisci PORT con il numero di porta maggiore di 1024.
Imposta l' Google Cloud URL di reindirizzamento della console
L'URL di reindirizzamento per la Google Cloud console è:
https://console.cloud.google.com/kubernetes/oidc
Quando configuri il provider OIDC, specifica
https://console.cloud.google.com/kubernetes/oidc
come uno dei tuoi 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 Google Cloud console 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 fornitore. La gcloud CLI o la consoleGoogle Cloud invia 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 Google Cloud console,
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 client secret che l'gcloud CLI e la Google Cloud console utilizzano per effettuare l'autenticazione al provider OpenID.
Crea un ambito personalizzato che gcloud CLI o Google Cloud Console puoi utilizzare per richiedere i gruppi di sicurezza dell'utente.
Crea un nome di rivendicazione personalizzato utilizzato dal provider per restituire i gruppi di sicurezza dell'utente.
Configura il cluster
Questa sezione è rivolta agli amministratori di 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 Google Cloud console sia per il plug-in di autenticazione per GKE Enterprise. 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
.
Campo | Obbligatorio | Descrizione | Formato |
---|---|---|---|
adminIdentityARNs | Sì, se configuri OIDC. | Nome risorsa Amazon (ARN) delle identità AWS IAM (utenti o ruoli)
a cui GKE su AWS ha concesso l'accesso come amministratore del 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 singola riga. 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, passa resource=token-groups-claim .
Se il server di autorizzazione richiede il consenso, per l'autenticazione con
Microsoft Azure e Okta, imposta |
Elenco separato 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 prefissogid- 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 separato 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 provider codificano in un token le proprietà che consentono di identificare l'utente, ad esempio l'email e gli ID utente. Tuttavia, queste proprietà presentano rischi impliciti per le norme di autenticazione:
- Gli ID utente possono rendere i criteri difficili da leggere e controllare.
- L'utilizzo degli indirizzi email può comportare sia un rischio di disponibilità (se un utente cambia il proprio indirizzo email principale) sia un rischio per la sicurezza (se un indirizzo email può essere riassegnato).
Anziché assegnare ID utente, consigliamo i criteri di gruppo, che possono essere sia permanenti sia più facili da controllare.
Supponiamo che il tuo provider crei token di identità 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, compila 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, utilizza il controllo degli accessi basato su 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 di sola lettura ai secret del cluster e una risorsa ClusterRoleBinding
per associare il ruolo al gruppo autenticato.
Definisci un
ClusterRole
. Copia il seguente codice YAML in un file denominatosecret-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 denominatosecret-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
esecret-reader-admins.yaml
al tuo cluster conkubectl
.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 segreti nel tuo cluster.
Crea una configurazione di accesso
Questa sezione è rivolta agli amministratori di 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
, utilizzaanthos-gke
per cambiare contesto e passare al cluster di utenti. Sostituisci CLUSTER_NAME con il nome del cluster di utenti.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Crea la configurazione con
gcloud anthos
.gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
Sostituisci usercluster-kubeconfig con il percorso del file
kubeconfig
del tuo cluster di utenti. 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 autenticarsi nel cluster con gcloud CLI. Non modificare questo file.
Per saperne di più sui contenuti di kubectl-anthos-config.yaml
, consulta la appendice.
Distribuisci la configurazione di accesso
Distribuisci il file di configurazione agli utenti che devono autenticarsi nei tuoi cluster di utenti. Puoi distribuire la configurazione:
- Posiziona il file nella directory predefinita.
- Distribuzione sicura del file.
- Ospitare il file su un server HTTPS.
Directory predefinite della configurazione di accesso
Le posizioni predefinite per l'archiviazione del file di configurazione per ciascun sistema operativo sono:
- 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.- Finestre
%APPDATA%/google/anthos/kubectl-anthos-config.yaml
, dove%APPDATA%
è la directory dei dati dell'applicazione dell'utente.
Dopo aver distribuito la configurazione di accesso, gli sviluppatori possono configurare gcloud CLI per accedere al cluster.
Modificare 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, svolgi i seguenti passaggi:
Segui i passaggi descritti in Eseguire l'upgrade del cluster.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare contesto e passare al cluster di utenti. Sostituisci CLUSTER_NAME con il nome del cluster di utenti.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Apri il manifest che contiene AWSCluster in un editor di testo. Mantieni 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
, utilizzaanthos-gke
per cambiare contesto e passare al servizio di gestione.cd anthos-aws anthos-gke aws management get-credentials
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 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 il seguente comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-0
Elimina l'oggetto
oidc
dal file manifest del cluster.Salva il file. Se utilizzi
kubectl edit
,kubectl
applica le modifiche automaticamente. Se stai modificando il file YAML, applicalo al 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.
Configurare gcloud per accedere al cluster
Questa sezione è rivolta a sviluppatori o amministratori di cluster.
Prerequisiti
Per completare questa sezione, devi completare quanto segue:
- Una configurazione di accesso.
Una versione aggiornata dellgcloud 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 degli argomenti richiesti e le opzioni disponibili.
gcloud anthos auth
Esegui l'autenticazione al cluster
Puoi autenticarti nel cluster nei seguenti modi:
- Con lgcloud CLI sulla tua macchina locale.
- Con gcloud CLI su una macchina remota utilizzando un tunnel SSH.
Con Connect sulla Google Cloud console.
gcloud local
Utilizza gcloud anthos auth login
per autenticarti nel cluster con la tua configurazione di accesso.
Se hai posizionato 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 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 per 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 effettuare connessioni HTTPS. |
kubeconfig | Percorso del file kubeconfig contenente i token. Il valore predefinito è
$HOME/.kube/config` . |
dry-run | Prova 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 sue credenziali aziendali, esegue lo scambio di credenziali OIDC e acquisisce i token pertinenti. Gcloud CLI poi
scrive i token in un file kubeconfig
. kubectl
utilizza questo file per autenticarti nel cluster utente.
Per verificare che l'autenticazione sia andata a buon fine, esegui un comando kubectl
con il tuo file kubeconfig
:
env HTTPS_PROXY=http://localhost:8118 \
kubectl get nodes --kubeconfig my.kubeconfig
gcloud tunnel
Se vuoi autenticarti in un cluster di utenti da una macchina remota, puoi eseguire l'autenticazione utilizzando un tunnel SSH. Per utilizzare un tunnel, il file di configurazione dell'autenticazione deve essere sulla macchina remota e devi essere in grado di raggiungere il tuo provider OpenID dalla tua macchina locale.
Sulla tua macchina locale, esegui il seguente 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 creare un tunnel per la macchina remota.REMOTE_PORT è la porta configurata 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 il seguente 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.
Sul computer 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 di utenti.
Nella shell SSH, verifica di avere accesso al cluster di utenti:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Console
Puoi autenticarti con la Google Cloud console, avviare il flusso di autenticazione dalla pagina dei cluster Kubernetes nella Google Cloud console: Google Cloud
-
Apri la Google Cloud console:
-
Individua il tuo cluster GKE su AWS nell'elenco e fai clic su Accedi.
-
Seleziona Esegui l'autenticazione con il provider di identità configurato per il cluster e poi fai clic su ACCEDI.
Verrà visualizzato il tuo provider di identità, a cui potresti dover accedere o dare il consenso per consentire alla Google Cloud console di accedere al tuo account. Ti reindirizzeremo alla pagina Cluster Kubernetes nella Google Cloud console.
Aggiornamento della configurazione OIDC
Per aggiornare la configurazione OIDC nel 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 nel cluster.
Per informazioni sui contenuti della risorsa ClientConfig, consulta la sezione seguente.
Appendice: configurazione di accesso di esempio
Di seguito è riportato un esempio kubectl-anthos-config.yaml
. Questo esempio è incluso per comprendere i 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 spiegazioni dei contenuti dei campi, consulta Campi di autenticazione.
Passaggi successivi
Esegui il deployment del tuo primo carico di lavoro in GKE su AWS.