Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 :
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, resources et verbs 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 resources 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 verbs 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.
(Cette info a été tirée de la documentation)
HTTP verb | request verb |
---|---|
POST | create |
GET, HEAD | get (pour des ressources individuelles), list (pour des collections, y compris le contenu complet de l'objet), watch (pour surveiller une ressource individuelle ou une collection de ressources) |
PUT | update |
PATCH | patch |
DELETE | delete (pour des ressources individuelles), deletecollection (pour des collections) |
Kubernetes vérifie parfois l'autorisation pour des permissions supplémentaires en utilisant des verbes spécialisés. Par exemple :
verbe use
sur les ressources podsecuritypolicies
dans le groupe API policy
.
verbes bind
et escalate
sur les ressources roles
et clusterroles
dans le groupe API rbac.authorization.k8s.io
.
verbe impersonate
sur users
, groups
, et serviceaccounts
dans le groupe API de base, et le userextras
dans le groupe API authentication.k8s.io
.
Vous pouvez trouver tous les verbes que chaque ressource supporte en exécutant kubectl api-resources --sort-by name -o wide
Par exemple, vous pouvez utiliser un ClusterRole pour permettre à un utilisateur particulier d'exécuter :
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 autorisations 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 autorisations et spécifiez ce qui est AUTORISÉ, car tout est REFUSÉ par défaut.
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)