Configurer RBAC

Cette rubrique explique comment configurer le contrôle d'accès basé sur les rôles (RBAC) dans Tanzu Kubernetes Grid.

À propos de la configuration de RBAC

Si vous prévoyez d'utiliser des fichiers kubeconfig standard non-administrateurs pour l'accès au cluster, vous devez configurer l'autorisation RBAC après avoir activé et configuré la gestion des identités. Pour plus d'informations sur les fichiers kubeconfig, reportez-vous à la section Fichiers kubeconfig administrateurs et non-administrateurs ci-dessous.

Pour configurer l'autorisation RBAC, vous créez une ou plusieurs liaisons de rôle pour chaque cluster de gestion et de charge de travail sur lequel vous souhaitez utiliser des fichiers kubeconfig standard non-administrateurs :

Après avoir activé et configuré la gestion des identités comme décrit dans la section Configurer la gestion des identités, créez une ou plusieurs liaisons de rôle pour le cluster de gestion. Pour obtenir des instructions, reportez-vous à la section Configurer RBAC pour un cluster de gestion ci-dessous.
Créez une ou plusieurs liaisons de rôle pour chaque cluster de charge de travail. Pour obtenir des instructions, reportez-vous à la section Configurer RBAC pour un cluster de charge de travail ci-dessous.

Pour plus d'informations sur les liaisons de rôle, reportez-vous à la section Rôles et liaisons de rôle ci-dessous.

Fichiers `kubeconfig` administrateurs et non-administrateurs

Pour accorder aux utilisateurs l'accès à un cluster de gestion ou à un cluster de charge de travail, générez un fichier kubeconfig, puis partagez le fichier avec ces utilisateurs. Si vous leur fournissez le fichier kubeconfig administrateur pour le cluster, les utilisateurs disposent d'un accès complet au cluster et n'ont pas besoin d'être authentifiés. Cependant, si vous fournissez aux utilisateurs le fichier kubeconfig standard non-administrateur, ils doivent disposer d'un compte d'utilisateur dans votre fournisseur d'identité OIDC ou LDAP et vous devez configurer RBAC sur le cluster pour accorder des autorisations d'accès à l'utilisateur désigné.

Pour générer un fichier kubeconfig pour un cluster de gestion ou de charge de travail, exécutez tanzu mc kubeconfig get sur le cluster de gestion ou tanzu cluster kubeconfig get sur le cluster de charge de travail. Lors de l'exécution de l'une de ces commandes avec ou sans l'option --admin, la commande fonctionne comme suit :

Avec --admin, la commande génère un fichier kubeconfig administrateur qui contient des informations d'identification intégrées. Avec cette version admin du fichier kubeconfig, tous les utilisateurs avec lesquels vous le partagez disposent d'un accès complet au cluster et l'authentification du fournisseur d'identité (IdP) est contournée.
Sans --admin, la commande génère un fichier kubeconfig qui invite les utilisateurs à s'authentifier auprès d'un fournisseur d'identité externe. Le fournisseur d'identité vérifie ensuite l'identité de l'utilisateur avant que celui-ci puisse accéder aux ressources du cluster.

Pour plus d'informations sur ces commandes, reportez-vous à la section :

Rôles et liaisons de rôle

Un rôle définit un ensemble d'autorisations. Vous pouvez définir un rôle dans un espace de noms spécifique en créant un Role ou un rôle à l'échelle du cluster en créant un ClusterRole. Pour accorder les autorisations définies dans ce rôle à un utilisateur ou à un groupe d'utilisateurs, vous devez créer une liaison de rôle.

Ressource	Portée	Description
`Role`	Espace de noms	Définit les autorisations qui peuvent être utilisées dans une `RoleBinding`.
`ClusterRole`	Cluster	Définit les autorisations qui peuvent être utilisées dans une `ClusterRoleBinding` ou une `RoleBinding` spécifique à l'espace de noms.
`RoleBinding`	Espace de noms	Accorde des autorisations dans un espace de noms spécifique. Peut faire référence à un `Role` ou un `ClusterRole`.
`ClusterRoleBinding`	Cluster	Accorde des autorisations sur tous les espaces de noms du cluster. Ne peut faire référence qu'à un `ClusterRole`.

Les rôles d'utilisateur par défaut sont les suivants :

cluster-admin : Accès complet au cluster. Lorsqu'il est utilisé dans une RoleBinding, ce rôle donne un accès complet à n'importe quelle ressource dans l'espace de noms spécifié dans la liaison.
admin : Accès administrateur à la plupart des ressources d'un espace de noms. Peut créer et modifier des rôles et des liaisons de rôle dans l'espace de noms.
edit : Accès en lecture-écriture à la plupart des objets d'un espace de noms, tels que les déploiements, les services et les espaces. Impossible d'afficher, de créer ou de modifier des rôles et des liaisons de rôle.
view : Accès en lecture seule à la plupart des objets d'un espace de noms. Impossible d'afficher, de créer ou de modifier des rôles et des liaisons de rôle.

Pour plus d'informations sur ces rôles, reportez-vous à la section Utilisation de l'autorisation RBAC dans la documentation de Kubernetes.

Configurer RBAC pour un cluster de gestion

Cette section explique comment :

Générer et tester un fichier kubeconfig non-administrateur pour le cluster de gestion
Créer une liaison de rôle sur le cluster de gestion

Générer et tester un fichier `kubeconfig` non-administrateur pour le cluster de gestion

Cette procédure vous permet de tester l'étape de connexion du processus d'authentification si un navigateur est présent sur la machine sur laquelle vous exécutez tanzu et kubectl. Si la machine ne dispose pas d'un navigateur, reportez-vous à la section Utilisateurs authentifiés sur une machine sans navigateur.

Exportez le fichier kubeconfig pour le cluster de gestion vers un emplacement local, par exemple, /tmp/id_mgmt_test_kubeconfig. Notez que la commande n'inclut pas l'option --admin, de sorte que le fichier kubeconfig qui est exporté est la version standard kubeconfig, pas la version admin.
```
tanzu mc kubeconfig get --export-file /tmp/id_mgmt_test_kubeconfig
```
Vous devez voir la confirmation You can now access the cluster by specifying '--kubeconfig /tmp/id_mgmt_test_kubeconfig' flag when using 'kubectl' command.
Connectez-vous au cluster de gestion à l'aide du fichier kubeconfig récemment créé :
```
kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
```
Le processus d'authentification nécessite la présence d'un navigateur sur la machine à partir de laquelle les utilisateurs se connectent aux clusters, car l'exécution des commandes kubectl ouvre automatiquement la page de connexion du fournisseur d'identité afin que les utilisateurs puissent se connecter au cluster. Votre navigateur doit ouvrir et afficher la page de connexion de votre fournisseur OIDC ou une page de connexion LDAPS.

LDAPS :

OIDC :

Entrez les informations d'identification d'un compte d'utilisateur qui existe dans votre serveur OIDC ou LDAP. Après une connexion réussie, le navigateur doit afficher les éléments suivants :
Revenez au terminal dans lequel vous exécutez les commandes tanzu et kubectl :
- Si vous avez déjà configuré une liaison de rôle sur le cluster pour l'utilisateur authentifié, la sortie de kubectl get pods -A s'affiche, incluant les informations sur l'espace.
- Si vous n'avez pas configuré de liaison de rôle sur le cluster, un message refusant l'accès du compte d'utilisateur aux espaces s'affiche : Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope. Cela se produit, car l'utilisateur a été authentifié, mais il n'est pas encore autorisé à accéder aux ressources sur le cluster. Pour autoriser l'utilisateur à accéder aux ressources du cluster, vous devez créer une liaison de rôle sur le cluster de gestion comme décrit ci-dessous.

Créer une liaison de rôle sur le cluster de gestion

Pour donner aux utilisateurs non-administrateurs l'accès à un cluster de gestion, générez et distribuez un fichier kubeconfig comme décrit dans la section Générer et tester un fichier kubeconfig non-administrateur pour le cluster de gestion ci-dessus. Pour que ce fichier kubeconfig fonctionne, vous devez d'abord configurer RBAC en créant une liaison de rôle sur le cluster de gestion. Cette liaison de rôle attribue des autorisations basées sur les rôles à des utilisateurs ou des groupes d'utilisateurs authentifiés individuels.

Pour créer une liaison de rôle :

Assurez-vous d'utiliser le contexte admin du cluster de gestion :
```
kubectl config current-context
```
Si le contexte n'est pas le contexte du cluster de gestion admin, définissez kubectl pour utiliser ce contexte. Par exemple :
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```
Répertoriez vos rôles existants :
- Pour afficher la liste complète des rôles à l'échelle de l'espace de noms, exécutez :
```
kubectl get roles --all-namespaces
```
- Pour afficher la liste complète des rôles à l'échelle du cluster, exécutez :
```
kubectl get clusterroles
```
Pour associer un utilisateur donné à un rôle, créez une liaison de rôle.
- Une RoleBinding peut faire référence à un Role ou à un ClusterRole.
- Une ClusterRoleBinding ne peut faire référence qu'à un ClusterRole.
L'exemple suivant crée une liaison de rôle de cluster nommée id-mgmt-test-rb qui lie le rôle de cluster cluster-admin à l'utilisateur [email protected] :
```
kubectl create clusterrolebinding id-mgmt-test-rb --clusterrole cluster-admin --user [email protected]
```
Pour --user, spécifiez le nom d'utilisateur OIDC ou LDAP de l'utilisateur. Vous avez configuré l'attribut de nom d'utilisateur et d'autres détails du fournisseur d'identité dans la section de gestion des identités de l'interface du programme d'installation de Tanzu Kubernetes Grid ou en définissant les variables LDAP_* ou OIDC_* :
- OIDC : l'attribut de nom d'utilisateur est défini dans le champ Réclamation du nom d'utilisateur (Username Claim) sous Source de gestion des identités OIDC (OIDC Identity Management Source) dans l'interface du programme d'installation de la variable de configuration OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM.
- LDAPS : l'attribut de nom d'utilisateur est défini dans le champ Nom d'utilisateur (Username) sous Source de gestion des identités LDAPS (LDAPS Identity Management Source) –> Attributs de recherche d'utilisateur (User Search Attributes) dans l'interface du programme d'installation ou la variable de configuration LDAP_USER_SEARCH_NAME_ATTRIBUTE.
Par exemple, pour OIDC, le nom d'utilisateur est souvent l'adresse e-mail de l'utilisateur. Pour LDAPS, il s'agit du nom d'utilisateur LDAP et non de l'adresse e-mail.
Réessayez de vous connecter au cluster de gestion à l'aide du fichier kubeconfig que vous avez créé lors de la procédure précédente :
```
kubectl get pods -A --kubeconfig /tmp/id_mgmt_test_kubeconfig
```
Cette fois, étant donné que l'utilisateur est lié au rôle cluster-admin sur ce cluster de gestion, la liste des espaces doit s'afficher. Vous pouvez partager le fichier kubeconfig généré avec tous les utilisateurs pour lesquels vous configurez des liaisons de rôle sur le cluster de gestion.

Configurer RBAC pour un cluster de charge de travail

Cette section explique comment :

Générer et tester un fichier kubeconfig non-administrateur pour un cluster de charge de travail
Créer une liaison de rôle sur un cluster de charge de travail

Générer et tester un fichier `kubeconfig` non-administrateur pour un cluster de charge de travail

Pour authentifier les utilisateurs sur un cluster de charge de travail, procédez comme suit :

Obtenez le fichier kubeconfig standard non-administrateur pour le cluster de charge de travail et exportez-le dans un fichier. L'exemple ci-dessous exporte le kubeconfig pour le cluster my-cluster dans le fichier my-cluster-kubeconfig.
```
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
```
Utilisez le fichier généré pour tenter d'exécuter une opération sur le cluster. Par exemple, exécutez :
```
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
```
Vous devez être redirigé vers la page de connexion de votre fournisseur d'identité. Après vous être connecté avec un compte d'utilisateur depuis votre fournisseur d'identité, si vous avez déjà configuré une liaison de rôle sur le cluster pour l'utilisateur authentifié, la sortie affiche les informations sur l'espace.

Si vous n'avez pas configuré de liaison de rôle sur le cluster, le message Error from server (Forbidden): pods is forbidden: User "<user>" cannot list resource "pods" in API group "" at the cluster scope s'affiche. Cela se produit, car cet utilisateur ne dispose pas encore d'autorisations sur le cluster. Pour autoriser l'utilisateur à accéder aux ressources du cluster, vous devez Créer une liaison de rôle sur un cluster de charge de travail.

Créer une liaison de rôle sur un cluster de charge de travail

Pour terminer la configuration de la gestion des identités du cluster de charge de travail, vous devez créer des liaisons de rôle pour les utilisateurs qui utilisent le kubeconfig que vous avez généré à l'étape précédente.

Définissez le contexte kubectl sur le fichier admin kubeconfig du cluster de charge de travail. Vous devez basculer vers le contexte admin du cluster de charge de travail afin de pouvoir créer une liaison de rôle. Par exemple, exécutez les deux commandes suivantes pour passer au contexte admin :
1. Obtenir le fichier kubeconfig :
```
tanzu cluster kubeconfig get my-cluster --admin
```
2. Changer de contexte :
```
kubectl config use-context my-cluster-admin@my-cluster
```
Pour afficher vos rôles existants :
- Pour afficher la liste complète des rôles à l'échelle de l'espace de noms, exécutez :
```
kubectl get roles --all-namespaces
```
- Pour afficher la liste complète des rôles à l'échelle du cluster, exécutez :
```
kubectl get clusterroles
```
Pour associer un utilisateur donné à un rôle, créez une liaison de rôle.
- Une RoleBinding peut faire référence à un Role ou à un ClusterRole.
- Une ClusterRoleBinding ne peut faire référence qu'à un ClusterRole.
L'exemple suivant crée une liaison de rôle de cluster nommée workload-test-rb qui lie le rôle de cluster cluster-admin à l'utilisateur [email protected] :
```
kubectl create clusterrolebinding workload-test-rb --clusterrole cluster-admin --user [email protected]
```
Pour --user, spécifiez le nom d'utilisateur OIDC ou LDAP de l'utilisateur. Vous avez configuré l'attribut de nom d'utilisateur et d'autres détails du fournisseur d'identité dans la section de gestion des identités de l'interface du programme d'installation de Tanzu Kubernetes Grid ou en définissant les variables LDAP_* ou OIDC_* :
- OIDC : l'attribut de nom d'utilisateur est défini dans le champ Réclamation du nom d'utilisateur (Username Claim) sous Source de gestion des identités OIDC (OIDC Identity Management Source) dans l'interface du programme d'installation de la variable de configuration OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM.
- LDAPS : l'attribut de nom d'utilisateur est défini dans le champ Nom d'utilisateur (Username) sous Source de gestion des identités LDAPS (LDAPS Identity Management Source) –> Attributs de recherche d'utilisateur (User Search Attributes) dans l'interface du programme d'installation ou la variable de configuration LDAP_USER_SEARCH_NAME_ATTRIBUTE.
Par exemple, pour OIDC, le nom d'utilisateur est souvent l'adresse e-mail de l'utilisateur. Pour LDAPS, il s'agit du nom d'utilisateur LDAP et non de l'adresse e-mail.
Utilisez le fichier kubeconfig standard que vous avez généré ci-dessus pour tenter à nouveau d'exécuter une opération sur le cluster. Par exemple, exécutez :
```
kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig
```
Cette fois, vous devez voir la liste des espaces qui s'exécutent dans le cluster de charge de travail. Cela est dû au fait que l'utilisateur du fichier my-cluster-kubeconfig a été authentifié par votre fournisseur d'identité et dispose des autorisations nécessaires sur le cluster. Vous pouvez partager le fichier my-cluster-kubeconfig avec tous les utilisateurs pour lesquels vous configurez des liaisons de rôle sur le cluster.

Tâches suivantes

Partagez les fichiers kubeconfig générés avec d'autres utilisateurs pour leur permettre d'accéder aux clusters.