Chapitre 8. Utilisation de RBAC pour définir et appliquer des autorisations
8.1. Vue d'ensemble de RBAC
Les objets de contrôle d'accès basé sur les rôles (RBAC) déterminent si un utilisateur est autorisé à effectuer une action donnée au sein d'un projet.
Les administrateurs de cluster peuvent utiliser les rôles de cluster et les bindings pour contrôler qui a différents niveaux d'accès à la plateforme OpenShift Container Platform elle-même et à tous les projets.
Les développeurs peuvent utiliser des rôles et des liens locaux pour contrôler qui a accès à leurs projets. Notez que l'autorisation est une étape distincte de l'authentification, qui consiste plutôt à déterminer l'identité de la personne qui effectue l'action.
L'autorisation est gérée à l'aide de :
| Objet d'autorisation | Description |
|---|---|
| Règles |
Ensemble de verbes autorisés sur un ensemble d'objets. Par exemple, si un compte d'utilisateur ou de service peut |
| Rôles | Collections de règles. Vous pouvez associer, ou lier, des utilisateurs et des groupes à plusieurs rôles. |
| Fixations | Associations entre des utilisateurs et/ou des groupes ayant un rôle. |
Il existe deux niveaux de rôles et de liaisons RBAC qui contrôlent l'autorisation :
| Niveau RBAC | Description |
|---|---|
| Cluster RBAC | Rôles et liaisons applicables à tous les projets. Cluster roles existe à l'échelle du cluster, et cluster role bindings ne peut faire référence qu'à des rôles du cluster. |
| RBAC local | Rôles et liaisons qui sont liés à un projet donné. Alors que local roles n'existe que dans un seul projet, les liaisons de rôles locaux peuvent faire référence à both et aux rôles locaux. |
Un lien de rôle de cluster est un lien qui existe au niveau du cluster. Un lien de rôle existe au niveau du projet. Le rôle de cluster view doit être lié à un utilisateur à l'aide d'une liaison de rôle locale pour que cet utilisateur puisse consulter le projet. Ne créez des rôles locaux que si un rôle de cluster ne fournit pas l'ensemble des autorisations nécessaires dans une situation particulière.
Cette hiérarchie à deux niveaux permet la réutilisation dans plusieurs projets grâce aux rôles de groupe, tout en permettant la personnalisation au sein des projets individuels grâce aux rôles locaux.
Lors de l'évaluation, on utilise à la fois les liaisons de rôles de la grappe et les liaisons de rôles locales. Par exemple :
- Les règles d'autorisation à l'échelle du groupe sont vérifiées.
- Les règles locales d'autorisation sont vérifiées.
- Refusé par défaut.
8.1.1. Rôles par défaut des clusters
OpenShift Container Platform inclut un ensemble de rôles de cluster par défaut que vous pouvez lier à des utilisateurs et des groupes à l'échelle du cluster ou localement.
Il n'est pas recommandé de modifier manuellement les rôles par défaut des clusters. La modification de ces rôles système peut empêcher le bon fonctionnement d'un cluster.
| Rôle de la grappe par défaut | Description |
|---|---|
|
|
Un chef de projet. S'il est utilisé dans un lien local, un |
|
| Un utilisateur qui peut obtenir des informations de base sur les projets et les utilisateurs. |
|
| Un super-utilisateur qui peut effectuer n'importe quelle action dans n'importe quel projet. Lorsqu'il est lié à un utilisateur avec un lien local, il a le contrôle total des quotas et de toutes les actions sur toutes les ressources du projet. |
|
| Un utilisateur qui peut obtenir des informations de base sur l'état de la grappe. |
|
| Un utilisateur qui peut obtenir ou visualiser la plupart des objets mais ne peut pas les modifier. |
|
| Un utilisateur qui peut modifier la plupart des objets d'un projet mais qui n'a pas le pouvoir de visualiser ou de modifier les rôles ou les liaisons. |
|
| Un utilisateur qui peut créer ses propres projets. |
|
| Un utilisateur qui ne peut effectuer aucune modification, mais qui peut voir la plupart des objets d'un projet. Il ne peut pas voir ou modifier les rôles ou les liaisons. |
Soyez attentif à la différence entre les liaisons locales et les liaisons de grappe. Par exemple, si vous liez le rôle cluster-admin à un utilisateur à l'aide d'une liaison de rôle locale, il peut sembler que cet utilisateur dispose des privilèges d'un administrateur de cluster. Ce n'est pas le cas. La liaison du rôle cluster-admin à un utilisateur dans un projet accorde à l'utilisateur des privilèges de super administrateur pour ce projet uniquement. Cet utilisateur dispose des autorisations du rôle de cluster admin, ainsi que de quelques autorisations supplémentaires, comme la possibilité de modifier les limites de taux, pour ce projet. Cette liaison peut être déroutante via l'interface utilisateur de la console Web, qui ne répertorie pas les liaisons de rôles de cluster qui sont liées à de véritables administrateurs de cluster. Cependant, elle répertorie les liaisons de rôles locaux que vous pouvez utiliser pour lier localement cluster-admin.
Les relations entre les rôles de grappe, les rôles locaux, les liaisons de rôles de grappe, les liaisons de rôles locaux, les utilisateurs, les groupes et les comptes de service sont illustrées ci-dessous.
Les règles get pods/exec, get pods/* et get * accordent des privilèges d'exécution lorsqu'elles sont appliquées à un rôle. Appliquez le principe du moindre privilège et n'attribuez que les droits RBAC minimaux requis pour les utilisateurs et les agents. Pour plus d'informations, voir Règles RBAC autorisant les privilèges d'exécution.
8.1.2. Évaluation de l'autorisation
OpenShift Container Platform évalue l'autorisation en utilisant :
- Identité
- Le nom de l'utilisateur et la liste des groupes auxquels il appartient.
- Action
L'action que vous effectuez. Dans la plupart des cas, il s'agit de
- Project: Le projet auquel vous accédez. Un projet est un espace de noms Kubernetes avec des annotations supplémentaires qui permet à une communauté d'utilisateurs d'organiser et de gérer leur contenu de manière isolée par rapport à d'autres communautés.
-
Verb: L'action elle-même :
get,list,create,update,delete,deletecollection, ouwatch. - Resource name: Le point de terminaison de l'API auquel vous accédez.
- Fixations
- La liste complète des liens, les associations entre les utilisateurs ou les groupes avec un rôle.
OpenShift Container Platform évalue l'autorisation en utilisant les étapes suivantes :
- L'identité et l'action à l'échelle du projet sont utilisées pour trouver toutes les liaisons qui s'appliquent à l'utilisateur ou à ses groupes.
- Les liaisons sont utilisées pour localiser tous les rôles qui s'appliquent.
- Les rôles sont utilisés pour trouver toutes les règles qui s'appliquent.
- L'action est comparée à chaque règle pour trouver une correspondance.
- Si aucune règle correspondante n'est trouvée, l'action est alors refusée par défaut.
N'oubliez pas que les utilisateurs et les groupes peuvent être associés ou liés à plusieurs rôles à la fois.
Les administrateurs de projet peuvent utiliser l'interface de programmation pour visualiser les rôles locaux et les liaisons, y compris une matrice des verbes et des ressources associés à chacun d'entre eux.
Le rôle de cluster lié à l'administrateur de projet est limité dans un projet par un lien local. Il n'est pas lié à l'ensemble du cluster comme les rôles de cluster accordés à cluster-admin ou system:admin.
Les rôles de cluster sont des rôles définis au niveau du cluster, mais qui peuvent être liés soit au niveau du cluster, soit au niveau du projet.
8.1.2.1. Agrégation des rôles des clusters
Les rôles de cluster par défaut admin, edit, view et cluster-reader prennent en charge l'agrégation des rôles de cluster, où les règles de cluster pour chaque rôle sont mises à jour dynamiquement au fur et à mesure que de nouvelles règles sont créées. Cette fonctionnalité n'est pertinente que si vous étendez l'API Kubernetes en créant des ressources personnalisées.
