Kubernetes Role-Based Access Control(RBAC)

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF controlla i PACCHETTI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri The PEASS Family, la nostra collezione di NFT esclusivi

• Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguimi su Twitter 🐦 @carlospolopm.

• Condividi i tuoi trucchi di hacking inviando PR ai repository HackTricks e HackTricks Cloud github.

Controllo degli accessi basato sui ruoli (RBAC)

Kubernetes ha un modulo di autorizzazione chiamato Controllo degli Accessi Basato sui Ruoli (RBAC) che aiuta a impostare le autorizzazioni di utilizzo per il server API.

Il modello di autorizzazione di RBAC è composto da tre parti individuali:

1. Ruolo/Ruolo del Cluster ­– La vera autorizzazione. Contiene regole che rappresentano un insieme di autorizzazioni. 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à le autorizzazioni.

3. RoleBinding/ClusterRoleBinding – La connessione tra Ruolo/Ruolo del Cluster e il soggetto.

La differenza tra "Ruoli" e "Ruoli del Cluster" sta solo nel fatto che il ruolo verrà applicato - un "Ruolo" concederà l'accesso a un specifico namespace, mentre un "Ruolo del Cluster" può essere utilizzato in tutti i namespace del cluster. Inoltre, i Ruoli del Cluster possono anche concedere l'accesso a:

• Risorse a livello di cluster (come i nodi).

• Endpoint non basati su risorse (come /healthz).

• Risorse basate su namespace (come i Pod), in tutti i namespace.

A partire da Kubernetes 1.6, le politiche di RBAC sono abilitate per impostazione predefinita. Ma per abilitare RBAC puoi utilizzare qualcosa come:

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

Modelli

Nel modello di un Ruolo o di un ClusterRole sarà necessario indicare il nome del ruolo, il namespace (nei ruoli) e quindi gli apiGroups, risorse e verbi del ruolo:

• Gli apiGroups è 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 risorse è un array che definisce a quali risorse si applica questa regola. È possibile trovare tutte le risorse con: kubectl api-resources --namespaced=true

• I verbi è un array che contiene i verbi consentiti. Il verbo in Kubernetes definisce il tipo di azione che è necessario applicare alla risorsa. Ad esempio, il verbo di elenco viene utilizzato per le raccolte mentre "get" viene utilizzato per una singola risorsa.

Verbi delle regole

(Questa informazione è stata presa da i documenti)

Verbo HTTP	Verbo della richiesta
POST	create
GET, HEAD	get (per risorse individuali), list (per raccolte, inclusi i contenuti completi degli oggetti), watch (per monitorare una risorsa individuale o una raccolta di risorse)
PUT	update
PATCH	patch
DELETE	delete (per risorse individuali), deletecollection (per raccolte)

Kubernetes controlla talvolta l'autorizzazione per ulteriori autorizzazioni 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.

• Autenticazione

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

È possibile trovare tutti i verbi supportati da ogni risorsa eseguendo kubectl api-resources --sort-by name -o wide

Esempi

Ruolo

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 utente specifico 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 una lista di soggetti (utenti, gruppi o account di servizio) e un riferimento al ruolo che viene concesso. Un RoleBinding concede i permessi all'interno di uno specifico namespace, mentre un ClusterRoleBinding concede l'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 cumulativi, 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.

Enumerazione 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 Ruoli/ClusterRoles per l'Elevazione dei Privilegi

pageAbusing Roles/ClusterRoles in Kubernetes

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri The PEASS Family, la nostra collezione di esclusive NFT

• Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguimi su Twitter 🐦 @carlospolopm.

• Condividi i tuoi trucchi di hacking inviando PR ai repository di HackTricks e HackTricks Cloud github.