Kubernetes Role-Based Access Control(RBAC)
Contrôle d'accès basé sur les rôles (RBAC)
Kubernetes dispose d'un module d'autorisation nommé Contrôle d'accès basé sur les rôles (RBAC) qui aide à définir les autorisations d'utilisation du serveur API.
Le modèle d'autorisation de RBAC est construit à partir de trois parties individuelles :
Rôle/ClusterRole – La permission réelle. Il contient des règles qui représentent un ensemble d'autorisations. Chaque règle contient des ressources et des verbes. Le verbe est l'action qui sera appliquée sur la ressource.
Sujet (Utilisateur, Groupe ou Compte de service) – L'objet qui recevra les autorisations.
RoleBinding/ClusterRoleBinding – La connexion entre le Rôle/ClusterRole et le sujet.
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fwww.cyberark.com%2Fwp-content%2Fuploads%2F2018%2F12%2Frolebiding_serviceaccount_and_role-1024x551.png&width=768&dpr=4&quality=100&sign=8a74ea80&sv=1)
La différence entre les "Rôles" et les "ClusterRoles" réside uniquement dans l'endroit où le rôle sera appliqué - un "Rôle" accordera l'accès à un seul espace de noms spécifique, tandis qu'un "ClusterRole" peut être utilisé dans tous les espaces de noms du cluster. De plus, les ClusterRoles peuvent également accorder l'accès à :
ressources de portée cluster (comme les nœuds).
points de terminaison non liés aux ressources (comme /healthz).
ressources de portée namespace (comme les Pods), dans tous les espaces de noms.
À 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 Rôle ou d'un ClusterRole, vous devrez indiquer le nom du rôle, l'espace de noms (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 ressource unique.
Verbes des règles
(Ces informations ont été extraites de la documentation)
Verbe HTTP | verbe de requête |
---|---|
POST | create |
GET, HEAD | get (pour les ressources individuelles), list (pour les 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 les ressources individuelles), deletecollection (pour les collections) |
Parfois, Kubernetes vérifie l'autorisation pour des autorisations 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
sur lesutilisateurs
,groupes
etcomptes de service
dans le groupe API principal, et lesuserextras
dans le groupe APIauthentication.k8s.io
.
Vous pouvez trouver tous les verbes que chaque ressource prend en charge 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
Depuis la documentation: Un role binding accorde les autorisations 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 autorisations dans un espace de noms spécifique tandis qu'un ClusterRoleBinding accorde cet accès à l'ensemble du cluster.
Les autorisations sont additives donc si vous avez un clusterRole avec les autorisations "list" et "delete" pour les secrets, vous pouvez l'ajouter avec un Role avec l'autorisation "get". Soyez conscient et testez toujours vos rôles et autorisations et spécifiez ce qui est AUTORISÉ, car tout est REFUSÉ par défaut.
Énumération de RBAC
Abus des rôles/ClusterRoles pour l'escalade de privilèges
Abusing Roles/ClusterRoles in KubernetesLast updated