Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubernetes Role-Based Access Control(RBAC)

Support 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 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 gli 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)

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

# 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

Supporta HackTricks
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated