Configura l'accesso utente per GKE Identity Service
Questo documento è rivolto agli amministratori di cluster che hanno già configurato cluster per GKE Identity Service seguendo le istruzioni in Configurare i cluster per GKE Identity Service a livello di parco risorse o Configurare i cluster per GKE Identity Service con OIDC. Ti spiega come configurare (e limitare) l'accesso al cluster configurato per gli sviluppatori della tua organizzazione e altri utenti del cluster.
Esegui l'autenticazione utilizzando l'accesso ai file
Dopo aver configurato un cluster, devi generare un file di configurazione di accesso e distribuirlo agli utenti del cluster. Questo file consente agli utenti di accedere al cluster dalla riga di comando con il provider scelto, come descritto in Accedere ai cluster con GKE Identity Service.
Solo con i provider OIDC, gli utenti possono accedere al cluster anche dalla console Google Cloud senza un file di accesso, come descritto in Utilizzare i cluster dalla console Google Cloud.
Genera la configurazione dell'accesso
Console
(solo configurazione a livello di parco risorse)
Copia il comando gcloud
visualizzato ed eseguilo per generare il file.
gcloud
Se hai configurato il cluster utilizzando l'interfaccia a riga di comando gcloud
o se devi generare di nuovo il file, esegui questo comando per generare il file:
gcloud anthos create-login-config --kubeconfig=KUBECONFIG
dove KUBECONFIG
è il percorso del file kubeconfig per il cluster. Se sono presenti più contesti in kubeconfig, viene utilizzato quello attuale. Potresti dover reimpostare il contesto attuale nel cluster corretto prima di eseguire il comando.
Puoi visualizzare i dettagli di riferimento completi per questo comando, inclusi altri parametri facoltativi, nella guida di riferimento per l'interfaccia a riga di comando di Google Cloud.
Il nome predefinito per il file di configurazione dell'accesso è kubectl-anthos-config.yaml
, ovvero il nome che Google Cloud CLI prevede quando utilizza il file per accedere. Se vuoi cambiarlo con un nome non predefinito, consulta la sezione pertinente in Distribuire la configurazione dell'accesso.
Per informazioni sulla risoluzione dei problemi relativi all'accesso degli utenti, vedi Risolvere i problemi di accesso degli utenti.
Distribuisci la configurazione dell'accesso
Di seguito sono riportati alcuni possibili approcci alla distribuzione del file di configurazione:
Ospita il file su un URL accessibile. Gli utenti possono specificare questa località con il flag
--login-config
quando eseguonogcloud anthos auth login
, consentendo a Google Cloud CLI di recuperare il file.Valuta la possibilità di ospitare il file su un host sicuro. Consulta il flag
--login-config-cert
di gcloud CLI per ulteriori informazioni sull'utilizzo dei certificati PEM per l'accesso HTTPS sicuro.Fornisci manualmente il file a ciascun utente, con informazioni su dove salvarlo sul computer locale: Google Cloud CLI prevede di trovarlo in una posizione predefinita specifica del sistema operativo. Se il nome o la posizione del file non sono predefiniti, gli utenti devono utilizzare il flag
--login-config
per specificare la posizione del file di configurazione quando eseguono i comandi sul cluster. Le istruzioni per gli utenti per salvare il file sono disponibili in Accedere ai cluster con GKE Identity Service.Utilizza i tuoi strumenti interni per eseguire il push del file di configurazione dell'autenticazione sul computer di ogni utente. Google Cloud CLI prevede di trovare il file nelle seguenti posizioni, a seconda del sistema operativo dell'utente:
Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
Windows
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
Esegui l'autenticazione utilizzando l'accesso FQDN (consigliato)
Anziché distribuire il file di configurazione a tutti gli utenti, puoi impostare l'accesso tramite l'accesso FQDN. Gli utenti possono eseguire l'autenticazione direttamente sul server GKE Identity Service con un nome di dominio completo (FQDN). Per i provider SAML, l'accesso utente è supportato solo attraverso questo processo di autenticazione.
Condividi il nome di dominio completo con gli utenti
Anziché un file di configurazione, gli amministratori del cluster possono condividere con gli utenti il nome di dominio completo del server GKE Identity Service. Gli utenti possono utilizzare questo FQDN per accedere al cluster. Il formato dell'URL per l'accesso è APISERVER-URL, dove l'URL contiene il nome di dominio completo del server cluster.
Un formato di esempio di APISERVER-URL è https://cluster.company.com
.
Accesso utente mediante certificati SNI attendibili
I certificati SNI semplificano l'accesso ai cluster sfruttando i certificati attendibili già presenti sui dispositivi aziendali. Gli amministratori utilizzano questo certificato al momento della creazione del cluster. Come utente, devi utilizzare il nome di dominio completo fornito dall'amministratore per accedere al cluster. In alternativa, puoi utilizzare un file kubeconfig
sicuro in cui il token viene archiviato dopo l'autenticazione riuscita.
Prima di eseguire questo comando, assicurati che il certificato utilizzato dal server di GKE Identity Service sia considerato attendibile dal dispositivo su cui viene svolta l'attività di accesso dell'utente.
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE
Sostituisci quanto segue:
- APISERVER-URL: nome di dominio completo del server GKE Identity Service.
- OUTPUT_FILE: utilizza questo flag se il tuo file
kubeconfig
si trova in una posizione diversa da quella predefinita. Se questo flag viene omesso, i token di autenticazione vengono aggiunti al filekubeconfig
nella posizione predefinita. Ad esempio:--kubeconfig /path/to/custom.kubeconfig
.
Accesso utente mediante certificati rilasciati da CA del cluster
Come utente, se non utilizzi un certificato SNI attendibile a livello di cluster, il certificato utilizzato dal servizio di identità viene emesso dall'autorità di certificazione (CA) del cluster. Gli amministratori distribuiscono questo certificato CA agli utenti. Esegui questo comando utilizzando il certificato CA del cluster per accedere al cluster:
gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE
Configura le opzioni di Identity Service
Con questo approccio all'autenticazione, puoi scegliere di configurare la durata
del token. Nella RP ClientConfig, viene introdotta una nuova sezione IdentityServiceOptions
con un nuovo parametro sessionDuration
. Ciò consente agli utenti di configurare la durata del token (in minuti). Il parametro sessionDuration
ha un limite inferiore di 15 minuti e un limite massimo di 1440 minuti (24 ore).
Ecco un esempio di come si presenta nella RP ClientConfig:
spec:
IdentityServiceOptions:
sessionDuration: INT
dove INT è la durata della sessione in minuti.
Configurare controllo dell'accesso basato sui ruoli (RBAC)
L'autenticazione viene spesso combinata con il controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per fornire controllo dell'accesso più granulare ai cluster per utenti e account di servizio autenticati. Quando possibile, consigliamo di creare criteri RBAC che utilizzino nomi di gruppo anziché identificatori utente. Se colleghi esplicitamente i criteri RBAC ai gruppi, puoi gestire i privilegi di accesso degli utenti interamente con il tuo provider di identità, in modo che il cluster non debba essere aggiornato ogni volta che i privilegi utente cambiano. Tieni presente che per configurare controllo dell'accesso dell'accesso in base all'appartenenza ai gruppi di sicurezza con OIDC, devi assicurarti che il servizio di identità GKE sia configurato per supportare la ricezione delle informazioni sulle iscrizioni ai gruppi dal tuo provider di identità.
Ad esempio, se vuoi che determinati utenti autenticati possano accedere ai pod del cluster, crea un ClusterRole
che conceda l'accesso a queste risorse, come nell'esempio seguente:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-reader rules: - apiGroups: [""] # The resource type for which access is granted resources: ["pods"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
Crea quindi un elemento ClusterRoleBinding
corrispondente per concedere le autorizzazioni di ClusterRole
agli utenti pertinenti, in questo caso i membri del gruppo di sicurezza us-east1-cluster-admins
e l'utente con ID u98523-4509823
:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-pods-admins subjects: # Grants anyone in the "us-east1-cluster-admins" group # read access to Pods in any namespace within this cluster. - kind: Group name: gid-us-east1-cluster-admins # Name is case-sensitive apiGroup: rbac.authorization.k8s.io # Grants this specific user read access to Pods in any # namespace within this cluster - kind: User name: uid-u98523-4509823 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Nell'esempio seguente, l'ClusterRoleBinding
concede le autorizzazioni nell'elemento ClusterRole
al gruppo pertinente con ID 12345678-BBBb-cCCCC-0000-123456789012
. Tieni presente che questa impostazione è pertinente solo per i provider Azure AD ed è disponibile per i cluster nei deployment bare metal di Google Distributed Cloud.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-reader-binding subjects: # Retrieves group information for the group ID mentioned - kind: Group name: 12345678-BBBb-cCCCC-0000-123456789012 apiGroup: rbac.authorization.k8s.io
Per ulteriori informazioni sull'utilizzo di RBAC, consulta gli articoli Configurare il controllo degli accessi basato su ruoli e Utilizzo dell'autorizzazione RBAC.
Creare un ruolo RBAC per l'accesso alla console Google Cloud
Gli utenti autenticati mediante provider OIDC possono accedere ai cluster dalla console Google Cloud e dalla riga di comando.
Gli utenti autenticati che vogliono accedere alle risorse di un cluster nella console Google Cloud devono disporre delle autorizzazioni Kubernetes pertinenti. Se non vuoi concedere a questi utenti autorizzazioni più estese, ad esempio quelle di amministratore del cluster, puoi creare un ruolo RBAC personalizzato che includa le autorizzazioni minime per visualizzare nodi, volumi permanenti, pod e classi di archiviazione del cluster. Puoi definire questo set di autorizzazioni creando una risorsa RBAC ClusterRole
, cloud-console-reader
, nel cluster.
cloud-console-reader
concede agli utenti le autorizzazioni get
, list
e watch
per nodi, volumi permanenti, pod e classi di archiviazione del cluster,
che consentono loro di visualizzare i dettagli su queste risorse.
kubectl
Per creare l'elemento cloud-console-reader
ClusterRole
e applicarlo al cluster, esegui questo comando:
cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cloud-console-reader
rules:
- apiGroups: [""]
resources: ["nodes", "persistentvolumes", "pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml
Puoi quindi concedere questo ClusterRole
agli utenti durante la configurazione dei criteri di autorizzazione, come descritto nella sezione precedente. Tieni presente che gli utenti devono anche autorizzazioni IAM per visualizzare i cluster nella console Google Cloud.