Scopri come configurare i cluster Anthos su AWS (GKE su AWS) per utilizzare OpenID Connect (OIDC) per l'autenticazione nei cluster utente. Questo argomento illustra la procedura per configurare cluster Anthos su AWS (GKE su AWS) con qualsiasi provider OpenID.
Per eseguire l'upgrade di un cluster che utilizza l'autenticazione OIDC a Kubernetes 1.21, vedi Eseguire l'upgrade alla versione 1.21.
Per una panoramica dei cluster di Anthos sul flusso di autenticazione AWS, vedi Autenticazione.
Panoramica
I cluster Anthos su AWS supportano OIDC come uno dei meccanismi di autenticazione per interagire con un server API Kubernetes del cluster utente. Con OIDC, puoi gestire l'accesso ai cluster Kubernetes utilizzando le procedure standard nella 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:
È necessario installare Google Cloud CLI su ogni macchina locale dello sviluppatore.
I sistemi headless non sono supportati. Per eseguire l'autenticazione, devi aprire un browser sulla macchina locale che esegue l'interfaccia a riga di comando gcloud. Il browser ti chiede poi di autorizzare l'account utente.
Per autenticarti 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 organizzazione: questa persona sceglie un provider OpenID e registra le applicazioni client con il provider.
Amministratore cluster: questa persona crea uno o più cluster utente e crea file di configurazione di 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 di tua scelta. Per un elenco dei provider certificati, consulta la sezione 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 l'interfaccia a riga di comando gcloud sia per Google Cloud Console.
Imposta l'URL di reindirizzamento dell'interfaccia a riga di comando gcloud
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 superiore a 1024.
Imposta l'URL di reindirizzamento di Google Cloud Console
L'URL di reindirizzamento per la console Google Cloud è:
https://console.cloud.google.com/kubernetes/oidc
Quando configuri il provider OIDC, specifica https://console.cloud.google.com/kubernetes/oidc
come uno degli URL di reindirizzamento.
Registrare le applicazioni client con il provider OpenID
Questa sezione è rivolta agli amministratori dell'organizzazione.
Prima che gli sviluppatori possano utilizzare Google Cloud CLI o Google Cloud Console con il tuo provider OpenID, devi registrare questi due client presso il provider OpenID. La registrazione prevede questi passaggi:
Scopri l'URI dell'emittente del tuo provider. L'interfaccia a riga di comando gcloud o Google Cloud Console invia le richieste di autenticazione a questo URI.
Configura il tuo provider con l'URL di reindirizzamento, incluso il numero di porta, per l'interfaccia a riga di comando gcloud.
Configura il tuo provider con l'URL di reindirizzamento per Google Cloud Console,
https://console.cloud.google.com/kubernetes/oidc
.Crea un singolo ID client che il provider utilizza per identificare sia Google Cloud CLI che Google Cloud Console.
Crea un singolo client secret che l'interfaccia a riga di comando gcloud e Google Cloud Console utilizzano per l'autenticazione nel provider OpenID.
Crea un ambito personalizzato che l'interfaccia a riga di comando gcloud o Google Cloud Console possa utilizzare per richiedere i gruppi di sicurezza degli utenti.
Crea un nome di rivendicazione personalizzato 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 che per il plug-in di autenticazione per Anthos. 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 seguente tabella descrive i campi dell'oggetto authentication.awsIAM.adminIdentityARNs
.
Campo | Obbligatoria | Descrizione | Formato |
---|---|---|---|
adminIdentityARN | Sì, se configuri OIDC. | Il nome risorsa Amazon (ARN) delle identità (utenti o ruoli) AWS IAM ha concesso l'accesso come amministratore del cluster ai cluster Anthos su AWS.
Esempio: arn:aws:iam::123456789012:group/Developers |
Stringa |
Campo | Obbligatoria | Descrizione | Formato |
---|---|---|---|
CertificateAuthorityData | No | Un
certificato con codifica PEM base64 per il provider OIDC. Per creare la stringa codifica il certificato, incluse le intestazioni, in base64. Includi la stringa risultante in certificateAuthorityData come riga singola. Esempio:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== |
Stringa |
ID cliente | Sì | ID dell'applicazione client che invia le richieste di autenticazione al provider OpenID. | Stringa |
clientSecret | No | Secret condiviso tra applicazione client OIDC e provider OIDC. | Stringa |
parametri aggiuntivi | No |
Parametri coppia chiave-valore aggiuntivi da inviare al provider OpenID. Se autorizzi
un gruppo, supera resource=token-groups-claim .
Se il server di autorizzazione richiede il consenso, per l'autenticazione con Microsoft Azure e Okta, imposta |
Elenco delimitato da virgole |
Rivendicazione di gruppi | No | JWT che il provider utilizza per restituire i tuoi gruppi di sicurezza. | Stringa |
Prefisso gruppo | 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 di risultati è gid-foobar . |
Stringa |
emittenteURI | Sì | URL a cui vengono inviate le richieste di autorizzazione al tuo OpenID, ad esempio https://example.com/adfs . Il server API di Kubernetes utilizza questo URL per rilevare le chiavi pubbliche per la verifica dei token. L'URI deve utilizzare HTTPS. |
Stringa URL |
kubectlReindirizzamentoURI | 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 |
RivendicazioneUtente | 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 |
Prefisso utente | No | Prefisso anteposto alle attestazioni dei nomi utente per evitare conflitti con i nomi esistenti. | Stringa |
Esempio: autorizzare utenti e gruppi
Molti provider codificano le proprietà di identificazione degli utenti, come email e User-ID, in un token. Tuttavia, queste proprietà presentano rischi impliciti per i criteri di autenticazione:
- Gli ID utente possono rendere i criteri difficili da leggere e controllare.
- L'uso degli indirizzi email può creare sia un rischio di disponibilità (se un utente cambia l'email principale) sia un rischio per la sicurezza (se un'email può essere riassegnata).
Invece di assegnare gli ID utente, consigliamo criteri di gruppo, che possono essere sia permanenti sia più facili da controllare.
Supponiamo che il tuo provider crei token di identità che includano i seguenti campi:
{ 'iss': 'https://server.example.com' 'sub': 'u98523-4509823' 'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp'] ... }
Considerato il formato del token, dovrai completare la specifica del file di configurazione oidc
, ad esempio:
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 sui ruoli (RBAC) per concedere l'accesso con privilegi agli utenti autenticati.
Nell'esempio seguente, crei un ClusterRole
che concede agli utenti l'accesso in 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.io
Applica
secret-reader-role.yaml
esecret-reader-admins.yaml
al 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 hanno accesso ai letture dei secret nel 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-gke
per cambiare il contesto del 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-kubeconfig
Sostituisci usercluster-kubeconfig con il percorso del file
kubeconfig
del cluster utente. Su Linux e macOS, per impostazione predefinita questo file si trova all'indirizzo~/.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 l'interfaccia a riga di comando gcloud. Non modificare il file.
Per ulteriori informazioni sui contenuti di kubectl-anthos-config.yaml
, consulta
l'appendice.
Distribuisci la configurazione di accesso
Distribuisci il file di configurazione agli utenti che devono eseguire l'autenticazione nei cluster utente. Puoi distribuire la configurazione tramite:
- Il file viene inserito nella directory predefinita.
- Distribuzione del file sicura.
- Ospitare il file su un server HTTPS.
Directory predefinite configurazione di accesso
Di seguito sono riportate le posizioni predefinite per l'archiviazione del file di configurazione per ogni sistema operativo:
- 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.
Una volta distribuita la configurazione di accesso, gli sviluppatori sono pronti per configurare l'interfaccia a riga di comando gcloud 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 Anthos Identity Service e rimuovere le informazioni OIDC dalla configurazione del cluster. Per aggiornare la configurazione:
Segui i passaggi descritti in Eseguire l'upgrade del cluster.
Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del 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 AWSCluster in un editor di testo. Tieni aperto il file e utilizza i valori dell'oggetto
oidc
per seguire i passaggi descritti in Configurazione dei cluster per Anthos Identity Service.Dalla directory
anthos-aws
, utilizzaanthos-gke
per cambiare il contesto del 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 nella sezione Creazione di un cluster utente, il file YAML è denominato
cluster-0.yaml
. Apri questo file in un editor di testo.Modifica kubectl
Per utilizzare
kubectl edit
per modificare il tuo AWSCluster, esegui questo 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 comando seguente:env HTTPS_PROXY=http://localhost:8118 \ kubectl edit awscluster cluster-0
Elimina l'oggetto
oidc
dal manifest del cluster.Salva il file. Se utilizzi
kubectl edit
,kubectl
applica automaticamente le modifiche. Se modifichi il file YAML, applicalo al tuo servizio di gestione con questo comando:env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f cluster-0.yaml
Il servizio di gestione aggiorna il tuo AWSCluster.
Configurazione di gcloud per accedere al cluster
Questa sezione è rivolta agli sviluppatori o agli amministratori di cluster.
Prerequisiti
Per completare questa sezione, devi completare quanto segue:
- Una configurazione di accesso.
Una versione aggiornata dell'interfaccia a riga di comando gcloud con i componenti
anthos-auth
.gcloud components update gcloud components install anthos-auth
Verifica che l'interfaccia a riga di comando gcloud sia stata installata correttamente eseguendo il comando seguente, che dovrebbe rispondere con dettagli sugli argomenti richiesti e sulle opzioni disponibili.
gcloud anthos auth
Autentica nel cluster
Puoi eseguire l'autenticazione nel cluster nei seguenti modi:
- Con l'interfaccia a riga di comando gcloud sulla tua macchina locale.
- Con l'interfaccia a riga di comando gcloud su una macchina remota utilizzando un tunnel SSH.
Con Connect su Google Cloud Console.
gcloud locale
Utilizza gcloud anthos auth login
per eseguire l'autenticazione nel cluster con la configurazione di accesso.
Se hai inserito 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.
Impostazione predefinita
gcloud anthos auth login --cluster CLUSTER_NAME
Sostituisci CLUSTER_NAME con un nome del 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 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 | Il percorso del file di configurazione generato dall'amministratore del cluster per lo sviluppatore oppure l'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 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 proprie credenziali aziendali, esegue lo scambio di credenziali OIDC e acquisisce i token pertinenti. L'interfaccia a riga di comando gcloud scrive quindi i token in un file kubeconfig
. kubectl
utilizza questo file per
autenticarsi nel cluster utente.
Per verificare che l'autenticazione sia riuscita, esegui un qualsiasi comando kubectl
con il 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 trovarsi sul computer remoto e devi essere in grado di contattare il provider Open ID dalla tua macchina locale.
Sulla macchina locale, esegui il comando seguente:
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 macchina locale che
ssh
utilizza per il tunneling alla 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 comando seguente 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. L'interfaccia a riga di comando gcloud 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.
Ora il file kubeconfig
sul computer remoto dispone del 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 Google Cloud Console, avviare il flusso di autenticazione dalla pagina Cluster Kubernetes in Google Cloud Console:
-
Apri Google Cloud Console:
-
Individua i cluster Anthos su cluster AWS nell'elenco, quindi fai clic su Accedi.
-
Seleziona Autentica con il provider di identità configurato per il cluster, quindi fai clic su ACCEDI.
Si aprirà il tuo provider di identità, dove potresti dover accedere o dare il tuo consenso alla console Google Cloud che accede al tuo account. Verrai quindi reindirizzato alla pagina Cluster Kubernetes di Google Cloud Console.
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 nel tuo 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
Segue un esempio di kubectl-anthos-config.yaml
. Questo esempio è incluso per comprendere i propri 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 le spiegazioni dei contenuti dei campi, consulta la sezione Campi di autenticazione.
Passaggi successivi
Esegui il deployment del tuo primo carico di lavoro nei cluster Anthos su AWS.