Scopri come configurare GKE su AWS per utilizzare OpenID Connect (OIDC) per l'autenticazione sui cluster utente. Questo argomento illustra il processo per configurare GKE su AWS con qualsiasi provider OpenID.
Per eseguire l'upgrade a Kubernetes 1.21 di un cluster che utilizza l'autenticazione OIDC, consulta Eseguire l'upgrade alla versione 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 l'interazione 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, abilitare e disabilitare gli account utente.
Prima di iniziare
Questo argomento presuppone che tu abbia familiarità con i seguenti concetti di autenticazione e OpenID:
Google Cloud CLI deve essere installata sulla macchina locale di ogni sviluppatore.
I sistemi headless non sono supportati. Per l'autenticazione, devi aprire un browser sulla macchina locale che esegue gcloud CLI. Il browser ti chiede quindi di autorizzare l'account utente.
Per eseguire l'autenticazione tramite la console Google Cloud, ogni cluster che vuoi configurare per l'autenticazione OIDC deve essere registrato con Google Cloud.
Utenti tipo
Questo argomento si riferisce a tre utenti tipo:
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 i 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 di tua scelta. Per un elenco dei fornitori certificati, consulta la pagina relativa alla certificazione OpenID.
Crea 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 che per la console Google Cloud.
Imposta l'URL di reindirizzamento dell'interfaccia a riga di comando gcloud CLI
Quando configuri il tuo provider OpenID, specifica l'URL di reindirizzamento dell'interfaccia a riga di comando come http://localhost:PORT/callback
Sostituisci PORT con un numero di porta maggiore di 1024.
Imposta l'URL di reindirizzamento della console Google Cloud
L'URL di reindirizzamento per la console Google Cloud è:
https://console.cloud.google.com/kubernetes/oidc
Quando configuri il tuo provider OIDC, specifica https://console.cloud.google.com/kubernetes/oidc come uno degli URL di reindirizzamento.
Registra le tue applicazioni client con il provider OpenID
Questa sezione è rivolta agli amministratori dell'organizzazione.
Prima che i tuoi sviluppatori possano utilizzare Google Cloud CLI o la console Google Cloud con il tuo provider OpenID, devi registrare questi due client con il provider OpenID. La registrazione prevede i seguenti passaggi:
Scopri l'URI dell'emittente del tuo provider. gcloud CLI o la console Google Cloud invia le 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 console Google Cloud,
https://console.cloud.google.com/kubernetes/oidc.Crea un singolo ID client utilizzato dal tuo provider per identificare sia Google Cloud CLI sia la console Google Cloud.
Crea un singolo client secret utilizzato da gcloud CLI e dalla console Google Cloud per l'autenticazione al provider OpenID.
Crea un ambito personalizzato che può essere utilizzato da gcloud CLI o dalla console Google Cloud per richiedere i gruppi di sicurezza dell'utente.
Crea un nome di attestazione personalizzata che il provider utilizza per restituire i gruppi di sicurezza dell'utente.
Configura il cluster
Questa sezione è rivolta agli amministratori del 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 console Google Cloud 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. | Amazon Resource Name (ARN) delle identità (utenti o ruoli) AWS IAM a cui è stato concesso l'accesso come amministratore del cluster da GKE su AWS.
Esempio: arn:aws:iam::123456789012:group/Developers |
String |
| 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 formato base64. Includi la stringa risultante in certificateAuthorityData come singola riga. Esempio:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== |
String |
| clientID | Sì | ID per l'applicazione client che invia le richieste di autenticazione al provider OpenID. | String |
| clientSecret | No | Secret condiviso tra applicazione client OIDC e provider OIDC. | String |
| extraParams | No |
Parametri 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, imposta |
Elenco delimitato da virgole |
| groupsClaim | No | JWT dichiara che il provider utilizza per restituire i gruppi di sicurezza. | String |
| 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 prefisso
gid-, il gruppo risultato è gid-foobar. |
String |
| 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 individuare 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 delimitato da virgole |
| userClaim | No | Attestazione JWT da utilizzare come nome utente. Puoi scegliere altre attestazioni, ad esempio indirizzo email o nome, a seconda del provider OpenID. Tuttavia, le attestazioni diverse dall'email sono precedute dal prefisso dell'URL dell'emittente per evitare conflitti di denominazione. | String |
| userPrefix | No | Prefisso anteposto alle attestazioni dei nomi utente per evitare conflitti con i nomi esistenti. | String |
Esempio: autorizzare utenti e gruppi
Molti provider codificano le proprietà di identificazione degli utenti, come email e ID utente, in un token. Tuttavia, queste proprietà presentano rischi impliciti per i criteri di autenticazione:
- Gli ID utente possono complicare la lettura e il controllo dei criteri.
- L'utilizzo degli indirizzi email può creare sia un rischio di disponibilità (se un utente cambia l'indirizzo email principale) sia un rischio per la sicurezza (se un'email può essere riassegnata).
Anziché assegnare gli ID utente, ti consigliamo di utilizzare criteri di gruppo, che possono essere permanenti e più semplici 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, dovresti compilare la specifica oidc del file di configurazione in questo 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, puoi utilizzare il controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per concedere l'accesso con privilegi agli utenti autenticati.
Nell'esempio seguente, crei un ClusterRole che concede ai suoi utenti l'accesso di sola lettura ai secret del cluster e crei una risorsa ClusterRoleBinding per associare il ruolo al gruppo autenticato.
Definisci un
ClusterRole. Copia il seguente 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 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.ioApplica
secret-reader-role.yamlesecret-reader-admins.yamlal cluster conkubectl.env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f secret-reader-role.yaml && \ kubectl apply -f secret-reader-admins.yamlGli utenti autorizzati ad accedere in
read-secrets-adminsora hanno accesso in lettura ai secret nel tuo cluster.
Crea una configurazione di accesso
Questa sezione è rivolta agli amministratori del 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-gkeper cambiare contesto al cluster utente.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster utente.Crea la configurazione con
gcloud anthos.gcloud anthos create-login-config --kubeconfig usercluster-kubeconfigSostituisci usercluster-kubeconfig con il percorso del file
kubeconfigdel cluster utente. Su Linux e macOS, per impostazione predefinita questo file si trova nel percorso~/.kube/config.
Questo comando genera un file (kubectl-anthos-config.yaml) contenente le informazioni di configurazione utilizzate dagli sviluppatori per l'autenticazione nel cluster con gcloud CLI. Non modificare questo file.
Per saperne di più sui contenuti di kubectl-anthos-config.yaml, consulta
l'appendice.
Distribuisci la configurazione dell'accesso
Distribuisci il file di configurazione agli utenti che devono eseguire l'autenticazione nei tuoi cluster utente. Puoi distribuire la configurazione in uno dei seguenti modi:
- Posizionare il file nella directory predefinita.
- Distribuzione sicura del file.
- Hosting del file su un server HTTPS.
Directory predefinite della configurazione dell'accesso
Le posizioni predefinite per l'archiviazione del file di configurazione per ciascun sistema operativo sono le seguenti:
- 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.- Windows
%APPDATA%/google/anthos/kubectl-anthos-config.yaml, dove%APPDATA%è la directory dei dati dell'applicazione dell'utente.
Dopo aver distribuito la configurazione di accesso, i tuoi sviluppatori sono pronti a configurare gcloud CLI per accedere al cluster.
Modifica 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, segui questi passaggi:
Segui la procedura descritta in Esegui l'upgrade del cluster.
Dalla directory
anthos-aws, utilizzaanthos-gkeper cambiare contesto al cluster utente.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster utente.Apri il manifest che contiene l'AWSCluster in un editor di testo. Tieni il file aperto e utilizza i valori dell'oggetto
oidcper seguire i passaggi descritti in Configurare i cluster per GKE Identity Service.Dalla directory
anthos-aws, utilizzaanthos-gkeper cambiare contesto 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 disponi del file YAML iniziale, puoi usare
kubectl edit.Modifica YAML
Se hai seguito le istruzioni riportate in Creazione di un cluster utente, il file YAML sarà denominato
cluster-0.yaml. Apri il file in un editor di testo.Modifica kubectl
Per utilizzare
kubectl editper modificare il cluster AWS, esegui questo comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-nameSostituisci cluster-name con il tuo AWSCluster. Ad esempio, per modificare il cluster predefinito,
cluster-0, esegui questo comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-0Elimina l'oggetto
oidcdal manifest del cluster.Salva il file. Se utilizzi
kubectl edit,kubectlapplica le modifiche automaticamente. Se stai modificando il file YAML, applicalo al tuo servizio di gestione con il seguente comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f cluster-0.yamlIl servizio di gestione aggiorna quindi AWSCluster.
Configurazione di gcloud per accedere al cluster
Questa sezione è rivolta agli sviluppatori o amministratori del cluster.
Prerequisiti
Per completare questa sezione, devi completare le seguenti operazioni:
- Una configurazione di accesso.
Una versione aggiornata di gcloud CLI con i componenti
anthos-auth.gcloud components update gcloud components install anthos-authVerifica che gcloud CLI sia stato installato correttamente eseguendo questo comando, che dovrebbe rispondere con i dettagli sugli argomenti richiesti e sulle opzioni disponibili.
gcloud anthos auth
Autentica sul cluster
Puoi autenticarti nel tuo cluster nei seguenti modi:
- Con gcloud CLI sulla tua macchina locale.
- Con gcloud CLI su una macchina remota che utilizza un tunnel SSH.
Con Connect nella console Google Cloud.
gcloud local
Usa gcloud anthos auth login per l'autenticazione nel cluster con la configurazione dell'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 completo del cluster. 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 in 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 | Indica 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 al file del certificato CA per le connessioni HTTPS. |
| kubeconfig | Percorso del file kubeconfig che contiene i token. Il valore predefinito è $HOME/.kube/config`. |
| prova | Testa 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 scrive quindi i token in un file kubeconfig. kubectl utilizza questo file per l'autenticazione nel cluster utente.
Per verificare che l'autenticazione sia riuscita, esegui qualsiasi comando kubectl con il tuo file kubeconfig:
env HTTPS_PROXY=http://localhost:8118 \
kubectl get nodes --kubeconfig my.kubeconfig
Tunnel gcloud
Se vuoi eseguire l'autenticazione in un cluster utente 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 poter raggiungere il tuo provider Open ID dalla macchina locale.
Sulla tua macchina locale, esegui questo comando:
ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT
Sostituisci quanto segue:
USERNAME con un utente con accesso SSH alla macchina remota.
REMOTE_MACHINE con il nome host o l'indirizzo IP della macchina remota.
LOCAL_PORT è una porta disponibile sulla macchina locale utilizzata da
sshper il tunneling alla macchina remota.REMOTE_PORT è la porta configurata per l'URL di reindirizzamento OIDC. Il numero di porta fa parte del campo
kubectlRedirectURIdel file di configurazione dell'autenticazione.
Nella shell SSH, esegui questo 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.
Sulla macchina locale, in un browser, vai a http://localhost:LOCAL_PORT/login e segui il flusso di accesso OIDC.
Il file kubeconfig sulla tua macchina remota ora contiene il token per accedere al cluster utente.
Nella shell SSH, verifica di avere accesso al cluster utente:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Console
Puoi eseguire l'autenticazione con la console Google Cloud e avviare il flusso di autenticazione dalla pagina dei cluster Kubernetes nella console Google Cloud:
-
Apri la console Google Cloud:
-
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, quindi fai clic su Accedi.
Si aprirà la pagina del tuo provider di identità, dove potresti dover accedere o dare il consenso alla console Google Cloud che ha accesso al tuo account. Verrai quindi reindirizzato alla pagina Cluster Kubernetes nella console Google Cloud.
Aggiornamento della configurazione OIDC in corso...
Per aggiornare la configurazione OIDC sul 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 sul cluster.
Per informazioni sui contenuti della risorsa ClientConfig, consulta la sezione seguente.
Appendice: configurazione di accesso di esempio
Ecco un esempio di kubectl-anthos-config.yaml. Questo esempio è incluso per comprenderne
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 una spiegazione dei contenuti dei campi, consulta la sezione Campi di autenticazione.
Passaggi successivi
Esegui il deployment del tuo primo carico di lavoro in GKE su AWS.