Questa pagina è stata tradotta dall'API Cloud Translation.

Configura l'accesso degli utenti per GKE Identity Service

Questo documento è rivolto agli amministratori di cluster che hanno già configurato i cluster per GKE Identity Service seguendo le istruzioni in Configurare i cluster per il servizio GKE Identity a livello di parco risorse o Configurare i cluster per il servizio identità GKE con OIDC. Spiega come configurare (e limitare) l'accesso al cluster configurato per gli sviluppatori e gli altri utenti del cluster dell'organizzazione.

Configurare l'accesso degli utenti

Dopo aver configurato un cluster, devi generare un file di configurazione dell'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 di 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 generarlo:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

dove KUBECONFIG è il percorso del file kubeconfig per il cluster. Se in kubeconfig sono presenti più contesti, viene utilizzato quello corrente. Potrebbe essere necessario reimpostare il contesto attuale sul cluster corretto prima di eseguire il comando.

Puoi vedere i dettagli di riferimento completi per questo comando, inclusi i parametri facoltativi aggiuntivi, nella guida di riferimento di Google Cloud CLI.

Il nome predefinito per il file di configurazione dell'accesso è kubectl-anthos-config.yaml, ovvero il nome che Google Cloud CLI prevede quando utilizzi il file per accedere. Se vuoi cambiarlo con un nome non predefinito, consulta la sezione pertinente in Distribuzione della configurazione dell'accesso di seguito.

Per informazioni sulla risoluzione dei problemi di accesso degli utenti, vedi Risolvere i problemi di accesso degli utenti.

Distribuisci la configurazione dell'accesso

Ecco alcuni possibili approcci per la distribuzione del file di configurazione:

Ospita il file in un URL accessibile. Gli utenti possono specificare questa posizione con il flag --login-config durante l'esecuzione di gcloud anthos auth login, consentendo a Google Cloud CLI di ottenere il file.

Prendi in considerazione l'hosting del file su un host sicuro. Consulta il flag --login-config-cert di gcloud CLI per ulteriori informazioni sull'uso dei certificati PEM per l'accesso HTTPS sicuro.
Fornisci manualmente il file a ciascun utente, con informazioni su dove salvarlo sulla macchina locale: Google Cloud CLI prevede di trovare il file in una posizione predefinita specifica del sistema operativo. Se il file ha un nome o una posizione non predefiniti, gli utenti devono utilizzare il flag --login-config per specificare la posizione del file di configurazione quando eseguono 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 sulla macchina 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
```

Configura un accesso utente tramite un processo di autenticazione alternativo

Anziché distribuire il file di configurazione a tutti gli utenti, puoi impostare un accesso utente utilizzando un processo di autenticazione alternativo. 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 degli utenti mediante accesso è supportato solo attraverso questo processo di autenticazione alternativo.

Condividi 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 usare questo nome di dominio completo per accedere al cluster. L'URL del server del servizio GKE Identity è fornito in uno dei seguenti formati:

https://CLUSTER-SERVER-NAME.com
CLUSTER-SERVER-NAME.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. In qualità di 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 è archiviato il token dopo l'autenticazione riuscita.

Prima di eseguire il comando seguente, assicurati che il certificato utilizzato dal server GKE Identity Service sia considerato attendibile dal dispositivo su cui viene eseguita 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 file kubeconfig si trova in una posizione diversa da quella predefinita. Se questo flag viene omesso, i token di autenticazione vengono aggiunti al file kubeconfig nel percorso predefinito. Ad esempio: --kubeconfig /path/to/custom.kubeconfig.

Accesso utente utilizzando i certificati emessi 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

Configurare controllo dell'accesso basato su ruoli (RBAC)

L'autenticazione è spesso combinata con il controllo controllo dell'accesso basato su ruoli (RBAC) di Kubernetes per fornire controllo dell'accesso dell'accesso più granulare ai cluster per gli utenti e gli account di servizio autenticati. Quando possibile, ti consigliamo di creare criteri RBAC che utilizzano i nomi dei gruppi anziché gli identificatori utente. Se colleghi esplicitamente i tuoi criteri RBAC ai gruppi, puoi gestire interamente i privilegi di accesso degli utenti con il tuo provider di identità, quindi non è necessario aggiornare il cluster 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 GKE Identity Service sia configurato in modo da supportare il recupero delle informazioni sulle iscrizioni ai gruppi dal provider di identità.

Ad esempio, se vuoi che determinati utenti autenticati abbiano accesso ai pod del cluster, crea un ClusterRole che concede 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"]

Successivamente, creerai un ClusterRoleBinding corrispondente per concedere le autorizzazioni nella 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, ClusterRoleBinding concede le autorizzazioni nella 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 Google Distributed Cloud Virtual for Bare Metal.

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 saperne di più sull'utilizzo di RBAC, consulta Configurare il controllo dell'accesso basato su ruoli e Utilizzo dell'autorizzazione RBAC.

Creare un ruolo RBAC per l'accesso alla console Google Cloud

Gli utenti autenticati tramite 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 per farlo. Se non vuoi concedere a questi utenti autorizzazioni più estese, come quelle di un 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 insieme di autorizzazioni creando una risorsa ClusterRole RBAC, cloud-console-reader, nel cluster.

cloud-console-reader concede agli utenti le autorizzazioni get, list e watch su nodi, volumi permanenti, pod e classi di archiviazione del cluster, che consentono loro di visualizzare i dettagli di queste risorse.

kubectl

Per creare l'ClusterRole cloud-console-reader 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 quando configuri i criteri di autorizzazione, come descritto nella sezione precedente. Tieni presente che gli utenti devono disporre anche delle autorizzazioni IAM per visualizzare i cluster nella console Google Cloud.