Kubernetes Role-Based Access Control(RBAC)

Soutenez HackTricks et bénéficiez d'avantages !

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou si vous souhaitez accéder à la dernière version de PEASS ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez The PEASS Family, notre collection d'NFTs exclusifs

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦 @carlospolopm.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts Github.

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 permet de définir les autorisations d'utilisation du serveur API.

Le modèle d'autorisation de RBAC est constitué de trois parties distinctes :

1. 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 s'appliquera sur la ressource.

2. Sujet (utilisateur, groupe ou compte de service) - L'objet qui recevra les autorisations.

3. RoleBinding/ClusterRoleBinding - La connexion entre Rôle/ClusterRole et le sujet.

La différence entre les "Rôles" et les "ClusterRoles" réside simplement 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 à :

• des ressources à portée de cluster (comme les nœuds).

• des points de terminaison sans ressource (comme /healthz).

• des ressources à portée de 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 :

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

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 sont un tableau qui contient les différentes 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 sont un tableau qui définit les ressources auxquelles cette règle s'applique. Vous pouvez trouver toutes les ressources avec : kubectl api-resources --namespaced=true

• Les verbs sont 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 les collections tandis que "get" est utilisé contre une seule ressource.

Verbes de règles

(Ces informations ont été prises ici)

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 regarder une ressource individuelle ou une collection de ressources)
PUT	update
PATCH	patch
DELETE	delete (pour les ressources individuelles), deletecollection (pour les collections)

Kubernetes vérifie parfois l'autorisation pour des autorisations supplémentaires en utilisant des verbes spécialisés. Par exemple :

• PodSecurityPolicy

  • verbe use sur les ressources podsecuritypolicies dans le groupe API policy.

• RBAC

  • verbes bind et escalate sur les ressources roles et clusterroles dans le groupe API rbac.authorization.k8s.io.

• Authentication

  • verbe impersonate sur les utilisateurs, groupes et comptes de service dans le groupe API de base, et les userextras dans le groupe API authentication.k8s.io.

Vous pouvez trouver **t