Kubernetes Role-Based Access Control(RBAC)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Role-Based Access Control (RBAC)

Kubernetes ha un modulo di autorizzazione chiamato Role-Based Access Control (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 e verbi. Il verbo è l'azione che verrà applicata alla risorsa.

2. Soggetto (Utente, Gruppo o ServiceAccount) – L'oggetto che riceverà i permessi.

3. RoleBinding\ClusterRoleBinding – La connessione tra Role\ClusterRole e il soggetto.

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 a livello di cluster (come i nodi).

• endpoint non risorsa (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

Templates

Nel template di un Role 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.

Rules Verbs

(Queste informazioni sono state prese da the docs)

HTTP verb	request verb
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

• verbo use su risorse podsecuritypolicies nel gruppo API policy.

• RBAC

• verbi bind e escalate su risorse roles e clusterroles nel gruppo API rbac.authorization.k8s.io.

• Authentication

• verbo impersonate su users, groups e serviceaccounts nel gruppo API core, e il userextras nel gruppo API authentication.k8s.io.

Puoi trovare tutti i verbi che ogni risorsa supporta eseguendo kubectl api-resources --sort-by name -o wide

Examples

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

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: 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 un namespace specifico, mentre un ClusterRoleBinding concede quell'accesso a livello di 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

I permessi sono additivi quindi se hai un clusterRole con “list” e “delete” segreti puoi aggiungerlo con 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

# 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

Abusing Roles/ClusterRoles in Kubernetes

Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.

• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.