hacktricks-cloud/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md

Kubernetes Role-Based Access Control(RBAC)

{{#include ../../banners/hacktricks-training.md}}

Role-Based Access Control (RBAC)

Kubernetes a un module d'autorisation nommé Role-Based Access Control (RBAC) qui aide à définir des permissions d'utilisation pour le API server.

Le modèle de permissions de RBAC est construit à partir de trois parties distinctes :

1. Role\ClusterRole – La permission elle-même. Elle contient des rules qui représentent un ensemble de permissions. Chaque règle contient des resources et des verbs. Le verb est l'action qui sera appliquée à la resource.
2. Subject (User, Group or ServiceAccount) – L'objet qui recevra les permissions.
3. RoleBinding\ClusterRoleBinding – La connexion entre Role\ClusterRole et le subject.

La différence entre “Roles” et “ClusterRoles” se situe uniquement dans l'endroit où le role sera appliqué – un “Role” accordera l'accès à un seul namespace spécifique, tandis qu'un “ClusterRole” peut être utilisé dans tous les namespaces du cluster. De plus, les ClusterRoles peuvent aussi accorder l'accès à :

• des ressources cluster-scoped (comme nodes).
• des endpoints non-resource (comme /healthz).
• des ressources namespaced (comme 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 :

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

Les clusters modernes peuvent aussi configurer la chaîne d’authorizer du API server avec --authorization-config, qui pointe vers un fichier AuthorizationConfiguration. Ce fichier peut définir des authorizers ordonnés, plusieurs webhook authorizers, des timeouts de webhook, failurePolicy, des paramètres de cache, et des matchConditions CEL qui décident quelles requests sont envoyées à un webhook. Lors d’un security review, ne vous arrêtez pas à --authorization-mode si --authorization-config est présent : lisez le fichier référencé et vérifiez si un webhook peut fail open avec NoOpinion, si les match conditions sautent des ressources sensibles, et si toutes les réplicas du API server utilisent une configuration d’authorization équivalente.

Vérifiez aussi la configuration d’authentication lors de l’examen de l’exposition anonyme de l’API. --authentication-config peut limiter l’anonymous authenticator à des paths spécifiques comme /livez, /readyz, et /healthz. L’accès anonyme aux endpoints de santé n’est pas la même chose que l’accès anonyme aux ressources Kubernetes ; la condition dangereuse est un chemin RBAC ou authorizer qui permet à system:anonymous ou system:unauthenticated de lire ou modifier de vrais objets API.

Enfin, considérez l’appartenance à system:masters comme équivalente à cluster-admin. Les users ou certificates dans ce groupe ont un accès API sans restriction qui contourne les limites normales de RBAC et d’authorization webhook, donc les mappings d’identité qui ajoutent ce groupe peuvent être plus importants que la sortie ordinaire de RoleBinding.

Templates

Dans le template d’un Role ou d’un ClusterRole, vous devrez indiquer le name du role, le namespace (dans les roles), puis les apiGroups, resources et verbs du role :

• Les apiGroups sont un tableau qui contient les différents API namespaces auxquels cette règle s’applique. Par exemple, une définition de Pod utilise apiVersion: v1. Il peut avoir des valeurs comme rbac.authorization.k8s.io ou [*].
• Les resources sont un tableau qui définit à quelles resources cette règle s’applique. Vous pouvez trouver toutes les resources avec : kubectl api-resources --namespaced=true
• Les verbs sont un tableau qui contient les verbs autorisés. Le verb dans Kubernetes définit le type d’action que vous devez appliquer à la resource. Par exemple, le verb list est utilisé sur des collections tandis que "get" est utilisé sur une seule resource.

Rules Verbs

(Cette info a été prise de the docs)

HTTP verb	request verb
POST	create
GET, HEAD	get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUT	update
PATCH	patch
DELETE	delete (for individual resources), deletecollection (for collections)

Kubernetes vérifie parfois l’authorization pour des permissions supplémentaires en utilisant des verbs spécialisés. Par exemple :

• PodSecurityPolicy
• verb use sur les resources podsecuritypolicies dans le groupe API policy.
• RBAC
• verbs bind et escalate sur les resources roles et clusterroles dans le groupe API rbac.authorization.k8s.io.
• Authentication
• verb impersonate sur users, groups, et serviceaccounts dans le core API group, et les userextras dans le groupe API authentication.k8s.io.

Kubernetes v1.36 inclut aussi constrained impersonation comme fonctionnalité beta. Au lieu d’accorder seulement le vieux verb impersonate tout ou rien, les clusters peuvent accorder des verbs spécifiques au mode comme impersonate:user-info, impersonate:serviceaccount, impersonate:arbitrary-node, ou impersonate:associated-node, plus des verbs spécifiques à l’action comme impersonate-on:user-info:list sur la resource cible. Examinez les deux moitiés : l’identité que le subject peut impersonate et les actions qu’il peut effectuer pendant l’impersonation. Les règles impersonate héritées peuvent encore permettre un accès plus large, donc n’assumez pas que des verbs qui semblent contraints sont appliqués sauf si la version du API server et les preuves d’access-review le confirment.

Warning

Vous pouvez trouver tous les verbs supportés par chaque resource en exécutant kubectl api-resources --sort-by name -o wide

Examples

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"]

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 autoriser un utilisateur particulier à exécuter :

kubectl get pods --all-namespaces

RoleBinding et ClusterRoleBinding

From the docs: Un role binding octroie les permissions définies dans un role à un user ou à un ensemble de users. Il contient une liste de subjects (users, groups, ou service accounts), et une référence au role accordé. Un RoleBinding octroie des permissions dans un namespace spécifique, tandis qu'un ClusterRoleBinding octroie cet accès à l'échelle du cluster.

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

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 permissions sont additives donc si vous avez un clusterRole avec “list” et “delete” secrets, vous pouvez l’ajouter avec un Role avec “get”. Soyez donc vigilant et testez toujours vos roles et permissions et spécifiez ce qui est AUTORISÉ, car tout est REFUSÉ par défaut.

Détails à vérifier

RBAC utilise les noms de resources tels qu’ils apparaissent dans les URL API, pas le YAML kind. Un Pod est pods, un Deployment est deployments, et les subresources sont écrites avec une barre oblique telle que pods/log, pods/exec, pods/portforward, pods/ephemeralcontainers, deployments/scale, serviceaccounts/token, nodes/proxy ou services/proxy. Une permission sur pods n’accorde pas automatiquement l’accès à pods/exec ou pods/log.

resourceNames peut restreindre certaines requêtes à des noms d’objet spécifiques :

rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["app-config"]
verbs: ["get", "update"]

Cela ne restreint pas create ou deletecollection au niveau supérieur par nom. Pour list et watch, le client doit inclure un sélecteur de champ metadata.name correspondant, sinon la requête n’est pas autorisée par cette règle :

kubectl get configmaps -n default --field-selector=metadata.name=app-config

Utilisez des access reviews exactes pour les contrôles à fort impact:

kubectl auth can-i create pods/exec -n default
kubectl auth can-i create serviceaccounts/token -n default
kubectl auth can-i impersonate users
kubectl auth can-i bind clusterroles.rbac.authorization.k8s.io
kubectl auth can-i escalate clusterroles.rbac.authorization.k8s.io
kubectl auth can-i impersonate-on:user-info:list pods -n default

Énumérer 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 Role/ClusterRoles pour l’escalade de privilèges

{{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}}

{{#include ../../banners/hacktricks-training.md}}