Configurazione di RBAC

Questo argomento spiega come configurare il controllo degli accessi basato sui ruoli (RBAC) in Tanzu Kubernetes Grid.

Informazioni sulla configurazione di RBAC

Se si intende utilizzare file kubeconfig standard non di amministrazione per l'accesso al cluster, è necessario configurare l'autorizzazione RBAC dopo aver abilitato e configurato la gestione delle identità. Per ulteriori informazioni sui file kubeconfig, vedere File kubeconfig di amministrazione e non di seguito.

Per configurare l'autorizzazione RBAC, creare uno o più binding dei ruoli per ogni cluster di gestione e del carico di lavoro in cui si desidera utilizzare file kubeconfig standard non di amministrazione:

Dopo aver abilitato e configurato la gestione delle identità come indicato in Configurazione della gestione delle identità, creare uno o più binding dei ruoli per il cluster di gestione. Per istruzioni, vedere Configurazione di RBAC per un cluster di gestione di seguito.
Creare uno o più binding dei ruoli per ogni cluster del carico di lavoro. Per istruzioni, vedere Configurazione di RBAC per un cluster del carico di lavoro di seguito.

Per ulteriori informazioni sui binding dei ruoli, vedere Ruoli e binding dei ruoli di seguito.

File `kubeconfig` di amministrazione e non

Per consentire agli utenti di accedere a un cluster di gestione oppure a un cluster del carico di lavoro, generare un file kubeconfig e quindi condividerlo con tali utenti. Se si fornisce loro il file kubeconfig di amministrazione per il cluster, disporranno dell'accesso completo al cluster e non dovranno eseguire l'autenticazione. Tuttavia, se si fornisce agli utenti il file kubeconfig standard non di amministrazione, devono disporre di un account utente nel provider di identità OIDC o LDAP ed è necessario configurare RBAC nel cluster per concedere le autorizzazioni di accesso agli utenti designati.

Per generare un file kubeconfig per un cluster di gestione o del carico di lavoro, eseguire tanzu mc kubeconfig get per il cluster di gestione o tanzu cluster kubeconfig get per il cluster del carico di lavoro. Quando si esegue uno di questi comandi con o senza l'opzione --admin, il comando funziona nel modo seguente:

Con --admin, il comando genera un file kubeconfig di amministrazione contenente credenziali incorporate. Con questa versione admin del file kubeconfig, tutti gli utenti con cui lo si condivide disporranno dell'accesso completo al cluster e l'autenticazione del provider di identità (IdP) verrà ignorata.
Senza --admin, il comando genera un file kubeconfig standard non di amministrazione che richiede agli utenti di eseguire l'autenticazione in un provider di identità esterno. Il provider di identità verifica quindi l'identità dell'utente prima che possa accedere alle risorse del cluster.

Per ulteriori informazioni su questi comandi, vedere:

Ruoli e binding dei ruoli

Un ruolo definisce un set di autorizzazioni. È possibile definire un ruolo in uno spazio dei nomi specifico creando un Role o un ruolo a livello di cluster tramite un ClusterRole. Per concedere le autorizzazioni definite in tale ruolo a un utente oppure a un gruppo di utenti, è necessario creare un binding del ruolo.

Risorsa	Ambito	Descrizione
`Role`	Spazio dei nomi	Definisce le autorizzazioni che possono essere utilizzate in un `RoleBinding` specifico dello spazio dei nomi.
`ClusterRole`	Cluster	Definisce le autorizzazioni che possono essere utilizzate in un `ClusterRoleBinding` o in un `RoleBinding` specifico dello spazio dei nomi.
`RoleBinding`	Spazio dei nomi	Concede le autorizzazioni in uno spazio dei nomi specifico. Può fare riferimento a `Role` o `ClusterRole`.
`ClusterRoleBinding`	Cluster	Concede le autorizzazioni in tutti gli spazi dei nomi nel cluster. Può fare riferimento solo a un `ClusterRole`.

I ruoli utente predefiniti includono:

cluster-admin: accesso completo al cluster. Quando viene utilizzato in un RoleBinding, questo ruolo fornisce l'accesso completo a qualsiasi risorsa nello spazio dei nomi specificato nel binding.
admin: accesso amministrativo alla maggior parte delle risorse in uno spazio dei nomi. Può creare e modificare ruoli e binding dei ruoli nello spazio dei nomi.
edit: accesso in lettura e scrittura alla maggior parte degli oggetti in uno spazio dei nomi, ad esempio distribuzioni, servizi e pod. Non può visualizzare, creare o modificare ruoli e binding dei ruoli.
view: accesso in sola lettura alla maggior parte degli oggetti in uno spazio dei nomi. Non può visualizzare, creare o modificare ruoli e binding dei ruoli.

Per ulteriori informazioni su questi ruoli, vedere Utilizzo delle autorizzazioni RBAC nella documentazione di Kubernetes.

Configurazione di RBAC per un cluster di gestione

Questa sezione spiega come eseguire le operazioni seguenti:

Generazione e test di un file kubeconfig non di amministrazione per il cluster di gestione
Creazione di un binding del ruolo nel cluster di gestione

Generazione e test di un file `kubeconfig` non di amministrazione per il cluster di gestione

Questa procedura consente di testare il passaggio di accesso del processo di autenticazione se nella macchina in cui si eseguono i comandi tanzu e kubectl è presente un browser. Se la macchina non dispone di un browser, vedere Autenticazione degli utenti in una macchina senza browser.

Esportare il file kubeconfig standard per il cluster di gestione in un file locale, ad esempio /tmp/id_mgmt_test_kubeconfig. Si tenga presente che il comando non include l'opzione --admin, quindi il file kubeconfig esportato è il file kubeconfig standard, non la versione admin.
```
tanzu mc kubeconfig get --export-file /tmp/id_mgmt_test_kubeconfig
```
Viene visualizzata la conferma You can now access the cluster by specifying '--kubeconfig /tmp/id_mgmt_test_kubeconfig' flag when using 'kubectl' command.
Connettersi al cluster di gestione utilizzando il file kubeconfig appena creato:
```
kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
```
Il processo di autenticazione richiede la presenza di un browser nella macchina da cui gli utenti si connettono ai cluster perché l'esecuzione dei comandi kubectl apre automaticamente la pagina di accesso del provider di identità in modo che gli utenti possano accedere al cluster. Il browser deve aprire e visualizzare la pagina di accesso del provider OIDC o la pagina di accesso di un LDAPS.

LDAPS:

OIDC:

Immettere le credenziali di un account utente esistente nel server OIDC o LDAP. Dopo aver eseguito correttamente l'accesso, nel browser viene visualizzato il messaggio seguente:
Tornare al terminale in cui sono stati eseguiti i comandi tanzu e kubectl:
- Se è già stato configurato un binding del ruolo nel cluster per l'utente autenticato, viene visualizzato l'output di kubectl get pods -A che include le informazioni sul pod.
- Se non è stato configurato un binding del ruolo nel cluster, viene visualizzato un messaggio che nega l'accesso dell'account utente ai pod: Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope. Questo errore si verifica perché l'utente è stato autenticato correttamente, ma non è ancora autorizzato ad accedere alle risorse nel cluster. Per autorizzare l'utente ad accedere alle risorse del cluster, è necessario eseguire la Creazione di un binding del ruolo nel cluster di gestione come descritto di seguito.

Creazione di un binding del ruolo nel cluster di gestione

Per consentire agli utenti non amministratori di accedere a un cluster di gestione, generare e distribuire un file kubeconfig come descritto nella sezione precedente Generazione e test di un file kubeconfig non di amministrazione per il cluster di gestione. Per fare in modo che questo file kubeconfig funzioni, è innanzitutto necessario configurare RBAC creando un binding del ruolo nel cluster di gestione. Questo binding del ruolo assegna autorizzazioni basate sui ruoli a singoli utenti o gruppi di utenti autenticati.

Per creare un binding del ruolo:

Assicurarsi di utilizzare il contesto admin del cluster di gestione:
```
kubectl config current-context
```
Se il contesto non è il contesto admin del cluster di gestione, impostare kubectl in modo che utilizzi tale contesto. Ad esempio:
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```
Visualizzare i ruoli esistenti:
- Per visualizzare l'elenco completo dei ruoli con lo spazio dei nomi come ambito, eseguire:
```
kubectl get roles --all-namespaces
```
- Per visualizzare l'elenco completo dei ruoli con il cluster come ambito, eseguire:
```
kubectl get clusterroles
```
Per associare un determinato utente a un ruolo, creare un binding del ruolo.
- Un RoleBinding può fare riferimento a un Role o un ClusterRole.
- Un ClusterRoleBinding può fare riferimento solo a un ClusterRole.
Nell'esempio seguente viene creato un binding del ruolo del cluster denominato id-mgmt-test-rb che associa il ruolo del cluster cluster-admin all'utente [email protected]:
```
kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --user [email protected]
```
Per --user, specificare il nome utente OIDC o LDAP dell'utente. L'attributo nome utente e altri dettagli del provider di identità sono stati configurati nella sezione Gestione identità (Identity Managemen) dell'interfaccia del programma di installazione di Tanzu Kubernetes Grid oppure impostando le variabili LDAP_* o OIDC_*:
- OIDC: l'attributo nome utente viene impostato nel campo Richiesta nome utente (Username Claim) in Origine gestione identità OIDC (OIDC Identity Management Source) nell'interfaccia del programma di installazione o nella variabile di configurazione OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM.
- LDAPS: l'attributo nome utente viene impostato nel campo Nome utente (Username) in Origine gestione identità LDAPS (LDAPS Identity Management Source) –> Attributi ricerca utente (User Search Attributes) nell'interfaccia del programma di installazione o nella variabile di configurazione LDAP_USER_SEARCH_NAME_ATTRIBUTE.
Ad esempio, per OIDC il nome utente è spesso l'indirizzo e-mail dell'utente. Per LDAPS, è il nome utente LDAP, non l'indirizzo e-mail.
Tentare di connettersi nuovamente al cluster di gestione utilizzando il file kubeconfig creato nella procedura precedente:
```
kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
```
Questa volta, poiché l'utente è associato al ruolo cluster-admin in questo cluster di gestione, viene visualizzato l'elenco dei pod. È possibile condividere il file kubeconfig generato con tutti gli utenti per cui si configurano i binding dei ruoli nel cluster di gestione.

Configurazione di RBAC per un cluster del carico di lavoro

Questa sezione spiega come eseguire le operazioni seguenti:

Generazione e test di un file kubeconfig non di amministrazione per un cluster del carico di lavoro
Creazione di un binding del ruolo in un cluster del carico di lavoro

Generazione e test di un file `kubeconfig` non di amministrazione per un cluster del carico di lavoro

Per l'autenticazione degli utenti in un cluster del carico di lavoro, eseguire i passaggi seguenti:

Recuperare il file kubeconfig standard non di amministrazione per il cluster del carico di lavoro ed esportarlo in un file. Nell'esempio seguente il file kubeconfig per il cluster my-cluster viene esportato nel file my-cluster-kubeconfig.
```
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
```
Utilizzare il file generato per tentare di eseguire un'operazione nel cluster. Ad esempio, eseguire:
```
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
```
Si verrà reindirizzati alla pagina di accesso per il provider di identità. Dopo aver effettuato correttamente l'accesso con un account utente del provider di identità, se è già stato configurato un binding del ruolo nel cluster per l'utente autenticato, l'output mostra le informazioni sul pod.

Se non è stato configurato un binding del ruolo nel cluster, viene visualizzato il messaggio Error from server (Forbidden): pods is forbidden: User "<user>" cannot list resource "pods" in API group "" at the cluster scope. Questo errore si verifica perché l'utente non dispone ancora di alcuna autorizzazione per il cluster. Per autorizzare l'utente ad accedere alle risorse del cluster, è necessario eseguire la Creazione di un binding del ruolo in un cluster del carico di lavoro.

Creazione di un binding del ruolo in un cluster del carico di lavoro

Per completare la configurazione della gestione delle identità del cluster del carico di lavoro, è necessario creare binding dei ruoli per gli utenti che utilizzano il file kubeconfig generato nel passaggio precedente.

Impostare il contesto di kubectl sul kubeconfig admin del cluster del carico di lavoro. È necessario passare al contesto admin del cluster del carico di lavoro in modo da poter creare un binding del ruolo. Ad esempio, eseguire i due comandi seguenti per passare al contesto admin:
1. Recuperare il file kubeconfig:
```
tanzu cluster kubeconfig get my-cluster --admin
```
2. Cambiare il contesto:
```
kubectl config use-context my-cluster-admin@my-cluster
```
Per visualizzare i ruoli esistenti:
- Per visualizzare l'elenco completo dei ruoli con lo spazio dei nomi come ambito, eseguire:
```
kubectl get roles --all-namespaces
```
- Per visualizzare l'elenco completo dei ruoli con il cluster come ambito, eseguire:
```
kubectl get clusterroles
```
Per associare un determinato utente a un ruolo, creare un binding del ruolo.
- Un RoleBinding può fare riferimento a un Role o un ClusterRole.
- Un ClusterRoleBinding può fare riferimento solo a un ClusterRole.
Nell'esempio seguente viene creato un binding del ruolo del cluster denominato workload-test-rb che associa il ruolo del cluster cluster-admin all'utente [email protected]:
```
kubectl create clusterrolebinding workload-test-rb --clusterrole cluster-admin --user [email protected]
```
Per --user, specificare il nome utente OIDC o LDAP dell'utente. L'attributo nome utente e altri dettagli del provider di identità sono stati configurati nella sezione Gestione identità (Identity Managemen) dell'interfaccia del programma di installazione di Tanzu Kubernetes Grid oppure impostando le variabili LDAP_* o OIDC_*:
- OIDC: l'attributo nome utente viene impostato nel campo Richiesta nome utente (Username Claim) in Origine gestione identità OIDC (OIDC Identity Management Source) nell'interfaccia del programma di installazione o nella variabile di configurazione OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM.
- LDAPS: l'attributo nome utente viene impostato nel campo Nome utente (Username) in Origine gestione identità LDAPS (LDAPS Identity Management Source) –> Attributi ricerca utente (User Search Attributes) nell'interfaccia del programma di installazione o nella variabile di configurazione LDAP_USER_SEARCH_NAME_ATTRIBUTE.
Ad esempio, per OIDC il nome utente è spesso l'indirizzo e-mail dell'utente. Per LDAPS, è il nome utente LDAP, non l'indirizzo e-mail.
Utilizzare il file kubeconfig standard generato in precedenza per tentare di eseguire nuovamente un'operazione nel cluster. Ad esempio, eseguire:
```
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
```
Questa volta verrà visualizzato l'elenco dei pod in esecuzione nel cluster del carico di lavoro perché l'utente del file my-cluster-kubeconfig è stato autenticato dal provider di identità e dispone delle autorizzazioni necessarie per il cluster. È possibile condividere il file my-cluster-kubeconfig con tutti gli utenti per cui si configurano i binding dei ruoli nel cluster.

Passaggi successivi

Condividere i file kubeconfig generati con altri utenti per consentire loro di accedere ai cluster.