Red Hat SummitChapitre 7. En utilisant RBAC pour définir et appliquer des autorisations
7.1. Aperçu du RBAC
Les objets de contrôle d’accès basés sur les rôles (RBAC) déterminent si un utilisateur est autorisé à effectuer une action donnée au sein d’un projet.
Les administrateurs dotés du rôle d’administrateur dédié peuvent utiliser les rôles de cluster et les liaisons pour contrôler qui a différents niveaux d’accès à la plate-forme OpenShift Dedicated 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. À noter que l’autorisation est une étape distincte de l’authentification, qui consiste davantage à déterminer l’identité de qui prend l’action.
L’autorisation est gérée en utilisant:
| L’objet d’autorisation | Description |
|---|---|
| Les règles | Ensembles de verbes autorisés sur un ensemble d’objets. À titre d’exemple, si un compte d’utilisateur ou de service peut créer des pods. |
| Les rôles | Collections de règles. Il est possible d’associer ou de lier des utilisateurs et des groupes à plusieurs rôles. |
| Fixations | Associations entre utilisateurs et/ou groupes ayant un rôle. |
Il y a deux niveaux de rôles et de liaisons RBAC qui contrôlent l’autorisation:
| Le niveau RBAC | Description |
|---|---|
| Cluster RBAC | Les rôles et les liens qui s’appliquent à tous les projets. Les rôles de cluster existent à l’échelle du groupe, et les liens de rôle de cluster ne peuvent référencer que les rôles de cluster. |
| Local RBAC | Les rôles et les liens qui s’appliquent à un projet donné. Bien que les rôles locaux n’existent que dans un seul projet, les liens de rôle locaux peuvent référencer à la fois les rôles de cluster et les rôles locaux. |
La liaison entre les rôles de cluster est une obligation qui existe au niveau des clusters. Il existe un rôle contraignant au niveau du projet. La vue de rôle de cluster doit être liée à un utilisateur en utilisant une liaison de rôle locale pour que cet utilisateur puisse voir le projet. Créer des rôles locaux uniquement si un rôle de cluster ne fournit pas l’ensemble des autorisations nécessaires à une situation particulière.
Cette hiérarchie à deux niveaux permet de réutiliser plusieurs projets via les rôles de cluster tout en permettant la personnalisation à l’intérieur des projets individuels via des rôles locaux.
Au cours de l’évaluation, on utilise à la fois les liaisons de rôle de groupe et les liaisons locales pour les rôles. À titre d’exemple:
- Les règles «permis» à l’échelle du cluster sont vérifiées.
- Les règles "d’autorisation" locales sont vérifiées.
- Déni par défaut.
7.1.1. Les rôles de cluster par défaut
Le programme OpenShift Dedicated inclut un ensemble de rôles de cluster par défaut que vous pouvez lier aux utilisateurs et aux groupes à l’échelle du cluster ou localement.
Il n’est pas recommandé de modifier manuellement les rôles de cluster par défaut. Les modifications apportées à ces rôles du système peuvent empêcher un cluster de fonctionner correctement.
| Le rôle du cluster par défaut | Description |
|---|---|
|
| Chef de projet. En cas d’utilisation dans une liaison locale, un administrateur a le droit de visualiser toute ressource dans le projet et de modifier toute ressource dans le projet, à l’exception du quota. |
|
| D’un utilisateur qui peut obtenir des informations de base sur les projets et les utilisateurs. |
|
| C’est un super-utilisateur qui peut effectuer n’importe quelle action dans n’importe quel projet. Lorsqu’ils sont liés à un utilisateur avec une liaison locale, ils ont un contrôle total sur le quota et chaque action sur chaque ressource du projet. |
|
| D’un utilisateur qui peut obtenir des informations de base sur l’état du cluster. |
|
| D’un utilisateur qui peut obtenir ou visualiser la plupart des objets, mais qui ne peut pas les modifier. |
|
| L’utilisateur qui peut modifier la plupart des objets d’un projet mais qui n’a pas le pouvoir d’afficher ou de modifier des rôles ou des liaisons. |
|
| L’utilisateur qui peut créer ses propres projets. |
|
| L’utilisateur qui ne peut apporter aucune modification, mais qui peut voir la plupart des objets dans un projet. Ils ne peuvent pas voir ou modifier les rôles ou les liaisons. |
Gardez à l’esprit la différence entre les liaisons locales et les regroupements. À titre d’exemple, si vous liez le rôle cluster-admin à un utilisateur en utilisant une liaison de rôle locale, il peut sembler que cet utilisateur a les privilèges d’un administrateur de cluster. Ce n’est pas le cas. Lier le cluster-admin à un utilisateur dans un projet accorde des privilèges de super administrateur pour seulement ce projet à l’utilisateur. Cet utilisateur a les autorisations de l’administrateur de rôle de cluster, plus quelques permissions 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ôle de cluster qui sont liées à de vrais administrateurs de clusters. Cependant, il répertorie les liaisons de rôle locales que vous pouvez utiliser pour lier localement cluster-admin.
Les relations entre les rôles de cluster, les rôles locaux, les liens de rôle de cluster, les liens locaux de rôle, les utilisateurs, les groupes et les comptes de services sont illustrés ci-dessous.
Les get pods/exec, get pods/*, et obtenir * règles accordent des privilèges d’exécution lorsqu’ils sont appliqués à un rôle. Appliquez le principe du moindre privilège et n’attribuez que les droits minimaux RBAC requis pour les utilisateurs et les agents. Les règles RBAC autorisent les privilèges d’exécution.
7.1.2. Évaluation de l’autorisation
La société OpenShift Dedicated évalue l’autorisation en utilisant:
- Identité
- Le nom d’utilisateur et la liste des groupes auxquels l’utilisateur appartient.
- À l’action
L’action que vous effectuez. Dans la plupart des cas, il s’agit de:
- Le projet auquel vous accédez. Il s’agit d’un espace de noms Kubernetes avec des annotations supplémentaires qui permet à une communauté d’utilisateurs d’organiser et de gérer leur contenu indépendamment des autres communautés.
- L’action elle-même : obtenir, répertorier, créer, mettre à jour, supprimer, supprimer, supprimer ou regarder.
- Le nom de la ressource : le point de terminaison API auquel vous accédez.
- Fixations
- La liste complète des liens, les associations entre utilisateurs ou groupes ayant un rôle.
La société OpenShift Dedicated évalue l’autorisation en utilisant les étapes suivantes:
- L’identité et l’action à portée de 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 vérifiée par rapport à chaque règle pour trouver un match.
- En cas d’absence de règle de correspondance, l’action est alors refusée par défaut.
Gardez à l’esprit que les utilisateurs et les groupes peuvent être associés ou liés à plusieurs rôles en même temps.
Les administrateurs de projet peuvent utiliser le CLI pour afficher les rôles et les liens locaux, y compris une matrice des verbes et des ressources auxquels chacun est associé.
Le rôle de cluster lié à l’administrateur du projet est limité dans un projet par le biais d’une liaison locale. Il n’est pas lié à l’ensemble du cluster comme les rôles de cluster attribués au cluster-admin ou system:admin.
Les rôles de cluster sont des rôles définis au niveau du cluster, mais peuvent être liés soit au niveau du cluster, soit au niveau du projet.
7.1.2.1. Agrégation des rôles de cluster
L’administrateur, l’édition, la vue et les rôles de cluster par défaut 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 à 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.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}