Kubernetes Role-Based Access Control(RBAC)
Contrôle d'accès basé sur les rôles (RBAC)
Kubernetes a un module d'autorisation nommé Contrôle d'accès basé sur les rôles (RBAC) qui aide à définir les permissions d'utilisation pour le serveur API.
Le modèle de permission de RBAC est construit à partir de trois parties individuelles :
Role\ClusterRole – La permission réelle. Elle contient des règles qui représentent un ensemble de permissions. Chaque règle contient des ressources et des verbes. Le verbe est l'action qui sera appliquée à la ressource.
Sujet (Utilisateur, Groupe ou ServiceAccount) – L'objet qui recevra les permissions.
RoleBinding\ClusterRoleBinding – La connexion entre Role\ClusterRole et le sujet.
La différence entre “Roles” et “ClusterRoles” est simplement où le rôle sera appliqué – un “Role” accordera l'accès à un namespace spécifique, tandis qu'un “ClusterRole” peut être utilisé dans tous les namespaces du cluster. De plus, les ClusterRoles peuvent également accorder l'accès à :
des ressources à portée de cluster (comme les nœuds).
des points de terminaison non-ressources (comme /healthz).
des ressources nommées (comme les Pods), dans tous les namespaces.
À partir de Kubernetes 1.6, les politiques RBAC sont activées par défaut. Mais pour activer RBAC, vous pouvez utiliser quelque chose comme :
Modèles
Dans le modèle d'un Role ou d'un ClusterRole, vous devrez indiquer le nom du rôle, le namespace (dans les rôles) et ensuite les apiGroups, ressources et verbes du rôle :
Les apiGroups est un tableau qui contient les différents espaces de noms API auxquels cette règle s'applique. Par exemple, une définition de Pod utilise apiVersion: v1. Il peut avoir des valeurs telles que rbac.authorization.k8s.io ou [*].
Les ressources est un tableau qui définit quelles ressources cette règle s'applique. Vous pouvez trouver toutes les ressources avec :
kubectl api-resources --namespaced=true
Les verbes est un tableau qui contient les verbes autorisés. Le verbe dans Kubernetes définit le type d'action que vous devez appliquer à la ressource. Par exemple, le verbe list est utilisé contre des collections tandis que "get" est utilisé contre une seule ressource.
Verbes des Règles
(Cette info a été tirée de la documentation)
Kubernetes vérifie parfois l'autorisation pour des permissions supplémentaires en utilisant des verbes spécialisés. Par exemple :
verbe
use
sur les ressourcespodsecuritypolicies
dans le groupe APIpolicy
.verbes
bind
etescalate
sur les ressourcesroles
etclusterroles
dans le groupe APIrbac.authorization.k8s.io
.verbe
impersonate
surusers
,groups
, etserviceaccounts
dans le groupe API de base, et leuserextras
dans le groupe APIauthentication.k8s.io
.
Vous pouvez trouver tous les verbes que chaque ressource supporte en exécutant kubectl api-resources --sort-by name -o wide
Exemples
Par exemple, vous pouvez utiliser un ClusterRole pour permettre à un utilisateur particulier d'exécuter :
RoleBinding et ClusterRoleBinding
D'après la documentation : Un role binding accorde les permissions définies dans un rôle à un utilisateur ou à un ensemble d'utilisateurs. Il contient une liste de sujets (utilisateurs, groupes ou comptes de service) et une référence au rôle accordé. Un RoleBinding accorde des permissions dans un namespace spécifique tandis qu'un ClusterRoleBinding accorde cet accès à l'échelle du cluster.
Les permissions sont additives donc si vous avez un clusterRole avec “list” et “delete” secrets, vous pouvez l'ajouter avec un Role avec “get”. Donc soyez conscient et testez toujours vos rôles et permissions et spécifiez ce qui est AUTORISÉ, car tout est REFUSÉ par défaut.
Énumération de RBAC
Abuser des rôles/ClusterRoles pour l'escalade de privilèges
Last updated