# Kubernetes Role-Based Access Control(RBAC)

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

## Contrôle d'accès basé sur les rôles (RBAC)

Kubernetes a un **module d'autorisation nommé Contrôle d'accès basé sur les rôles** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/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** :

1. **Role\ClusterRole ­–** La permission réelle. Elle contient des _**règles**_ qui représentent un ensemble de permissions. Chaque règle contient [ressources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) et [verbes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Le verbe est l'action qui sera appliquée à la ressource.
2. **Sujet (Utilisateur, Groupe ou ServiceAccount) –** L'objet qui recevra les permissions.
3. **RoleBinding\ClusterRoleBinding –** La connexion entre Role\ClusterRole et le sujet.

![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png)

La différence entre “**Roles**” et “**ClusterRoles**” est juste l'endroit 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 :
```
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
```
## Modèles

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.

### Verbes des Règles

(_Cette info a été tirée de_ [_**la documentation**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))

| Verbe HTTP | verbe de requête                                                                                                                                                  |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 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 :

- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
- verbe `use` sur les ressources `podsecuritypolicies` dans le groupe API `policy`.
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
- verbes `bind` et `escalate` sur les ressources `roles` et `clusterroles` dans le groupe API `rbac.authorization.k8s.io`.
- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
- verbe `impersonate` sur `users`, `groups`, et `serviceaccounts` dans le groupe API principal, et le `userextras` dans le groupe API `authentication.k8s.io`.

> [!WARNING]
> Vous pouvez trouver **tous les verbes que chaque ressource supporte** en exécutant `kubectl api-resources --sort-by name -o wide`

### Exemples
```yaml:Role
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"]
```

```yaml: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**

[**D'après la documentation :**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) 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**.
```yaml:RoleBinding
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
```

```yaml: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 “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.**

## **Énumération de RBAC**
```bash
# 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 de Role/ClusterRoles pour l'Escalade de Privilèges

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

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