# Kubernetes Role-Based Access Control(RBAC)

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

## Role-Based Access Control (RBAC)

Kubernetes ha un **modulo di autorizzazione chiamato Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) che aiuta a impostare i permessi di utilizzo per il server API.

Il modello di permessi di RBAC è costruito da **tre parti individuali**:

1. **Role\ClusterRole ­–** Il permesso effettivo. Contiene _**regole**_ che rappresentano un insieme di permessi. Ogni regola contiene [risorse](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) e [verbi](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb). Il verbo è l'azione che verrà applicata sulla risorsa.
2. **Soggetto (Utente, Gruppo o ServiceAccount) –** L'oggetto che riceverà i permessi.
3. **RoleBinding\ClusterRoleBinding –** La connessione tra Role\ClusterRole e il soggetto.

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

La differenza tra “**Roles**” e “**ClusterRoles**” è solo dove il ruolo sarà applicato – un “**Role**” concederà accesso a **un** **specifico** **namespace**, mentre un “**ClusterRole**” può essere utilizzato in **tutti i namespace** nel cluster. Inoltre, **ClusterRoles** possono anche concedere accesso a:

- risorse **cluster-scoped** (come i nodi).
- endpoint **non-resource** (come /healthz).
- risorse namespaced (come i Pods), **attraverso tutti i namespace**.

A partire da **Kubernetes** 1.6, le politiche **RBAC** sono **abilitate per impostazione predefinita**. Ma per abilitare RBAC puoi usare qualcosa come:
```
kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options
```
## Modelli

Nel modello di un **Ruolo** o di un **ClusterRole** è necessario indicare il **nome del ruolo**, il **namespace** (nei ruoli) e poi i **apiGroups**, **resources** e **verbs** del ruolo:

- Gli **apiGroups** sono un array che contiene i diversi **namespace API** a cui si applica questa regola. Ad esempio, una definizione di Pod utilizza apiVersion: v1. _Può avere valori come rbac.authorization.k8s.io o \[\*]_.
- Le **resources** sono un array che definisce **a quali risorse si applica questa regola**. Puoi trovare tutte le risorse con: `kubectl api-resources --namespaced=true`
- I **verbs** sono un array che contiene i **verbi consentiti**. Il verbo in Kubernetes definisce il **tipo di azione** che devi applicare alla risorsa. Ad esempio, il verbo list è usato contro collezioni mentre "get" è usato contro una singola risorsa.

### Verbi delle Regole

(_Queste informazioni sono state tratte da_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb))

| Verbo HTTP | verbo di richiesta                                                                                                                                                  |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST       | create                                                                                                                                                             |
| GET, HEAD  | get (per risorse individuali), list (per collezioni, incluso il contenuto completo dell'oggetto), watch (per monitorare una risorsa individuale o una collezione di risorse) |
| PUT        | update                                                                                                                                                             |
| PATCH      | patch                                                                                                                                                              |
| DELETE     | delete (per risorse individuali), deletecollection (per collezioni)                                                                                              |

Kubernetes a volte controlla l'autorizzazione per permessi aggiuntivi utilizzando verbi specializzati. Ad esempio:

- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
- verbo `use` su risorse `podsecuritypolicies` nel gruppo API `policy`.
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
- verbi `bind` ed `escalate` su risorse `roles` e `clusterroles` nel gruppo API `rbac.authorization.k8s.io`.
- [Autenticazione](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
- verbo `impersonate` su `users`, `groups` e `serviceaccounts` nel gruppo API core, e `userextras` nel gruppo API `authentication.k8s.io`.

> [!WARNING]
> Puoi trovare **tutti i verbi che ciascuna risorsa supporta** eseguendo `kubectl api-resources --sort-by name -o wide`

### Esempi
```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"]
```
Ad esempio, puoi utilizzare un **ClusterRole** per consentire a un particolare utente di eseguire:
```
kubectl get pods --all-namespaces
```
### **RoleBinding e ClusterRoleBinding**

[**Dalla documentazione:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) Un **role binding concede i permessi definiti in un ruolo a un utente o a un insieme di utenti**. Contiene un elenco di soggetti (utenti, gruppi o account di servizio) e un riferimento al ruolo concesso. Un **RoleBinding** concede permessi all'interno di uno specifico **namespace**, mentre un **ClusterRoleBinding** concede quell'accesso **a livello di 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
```
**I permessi sono additivi** quindi se hai un clusterRole con “list” e “delete” segreti puoi aggiungerlo a un Role con “get”. Quindi fai attenzione e testa sempre i tuoi ruoli e permessi e **specifica cosa è CONSENTITO, perché tutto è NEGATO per impostazione predefinita.**

## **Enumerare 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
```
### Abuso di Role/ClusterRoles per l'Escalation dei Privilegi

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

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