Kubernetes Role-Based Access Control(RBAC)

Apprenez et pratiquez le piratage AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le piratage GCP : Formation HackTricks GCP Red Team Expert (GRTE)

Soutenez HackTricks

• Consultez les plans d'abonnement!

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.

• Partagez des 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 aide à définir les autorisations d'utilisation du serveur API.

Le modèle d'autorisation de RBAC est construit à partir de trois parties individuelles :

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 sera appliquée sur la ressource.

2. Sujet (Utilisateur, Groupe ou Compte de service) – L'objet qui recevra les autorisations.

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

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 :

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 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 :

• Politique de sécurité des pods

• 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.

• Authentification

• Verbe impersonate sur les utilisateurs, groupes et comptes de service dans le groupe API principal, et les userextras dans le groupe API authentication.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

Rôle

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Par exemple, vous pouvez utiliser un ClusterRole pour permettre à un utilisateur particulier d'exécuter :

kubectl get pods --all-namespaces

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.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

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

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Abus des rôles/ClusterRoles pour l'escalade de privilèges

Abusing Roles/ClusterRoles in Kubernetes

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)

Soutenez HackTricks

• Consultez les plans d'abonnement!

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.

• Partagez des astuces de hacking en soumettant des PR aux HackTricks et HackTricks Cloud github repos.