Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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:
Soggetto (Utente, Gruppo o ServiceAccount) – L'oggetto che riceverà i permessi.
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 scopate 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:
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 quali risorse si applicano a 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.
(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:
verbo use
sulle risorse podsecuritypolicies
nel gruppo API policy
.
verbi bind
ed escalate
sulle risorse roles
e clusterroles
nel gruppo API rbac.authorization.k8s.io
.
verbo impersonate
su users
, groups
e serviceaccounts
nel gruppo API core, e 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
Ad esempio, puoi utilizzare un ClusterRole per consentire a un particolare utente di eseguire:
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.
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.
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)