Kubernetes Role-Based Access Control(RBAC)

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

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

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)

Verbo HTTPverbo di richiesta
POSTcreate
GET, HEADget (per risorse individuali), list (per collezioni, incluso il contenuto completo dell’oggetto), watch (per monitorare una risorsa individuale o una collezione di risorse)
PUTupdate
PATCHpatch
DELETEdelete (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 ed escalate su risorse roles e clusterroles nel gruppo API rbac.authorization.k8s.io.
  • Autenticazione
  • 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

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

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 uno specifico namespace, 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

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

# 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

Tip

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) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks