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 ma moduł autoryzacji nazwany Role-Based Access Control (RBAC), który pomaga ustawić uprawnienia do korzystania z serwera API.

Model uprawnień RBAC składa się z trzech indywidualnych części:

1. Role\ClusterRole ­– Rzeczywiste uprawnienie. Zawiera zasady, które reprezentują zestaw uprawnień. Każda zasada zawiera zasoby i czasowniki. Czasownik to akcja, która będzie stosowana do zasobu.

2. Subject (Użytkownik, Grupa lub ServiceAccount) – Obiekt, który otrzyma uprawnienia.

3. RoleBinding\ClusterRoleBinding – Połączenie między Role\ClusterRole a podmiotem.

Różnica między “Roles” a “ClusterRoles” polega tylko na tym, gdzie rola będzie stosowana – “Role” przyzna dostęp tylko do jednego konkretnego namespace, podczas gdy “ClusterRole” może być używana we wszystkich namespace w klastrze. Ponadto, ClusterRoles mogą również przyznawać dostęp do:

• zasobów o zasięgu klastra (jak węzły).

• punktów końcowych, które nie są zasobami (jak /healthz).

• zasobów w namespace (jak Pods), w obrębie wszystkich namespace.

Od Kubernetes 1.6 wzwyż, polityki RBAC są włączone domyślnie. Ale aby włączyć RBAC, możesz użyć czegoś takiego:

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

Szablony

W szablonie Role lub ClusterRole musisz wskazać nazwę roli, namespace (w rolach), a następnie apiGroups, resources i verbs roli:

• apiGroups to tablica, która zawiera różne przestrzenie nazw API, do których ta reguła ma zastosowanie. Na przykład, definicja Pod używa apiVersion: v1. Może mieć wartości takie jak rbac.authorization.k8s.io lub [*].

• resources to tablica, która definiuje które zasoby ta reguła dotyczy. Możesz znaleźć wszystkie zasoby za pomocą: kubectl api-resources --namespaced=true

• verbs to tablica, która zawiera dozwolone czasowniki. Czasownik w Kubernetes definiuje typ akcji, którą musisz zastosować do zasobu. Na przykład, czasownik list jest używany w odniesieniu do kolekcji, podczas gdy "get" jest używany w odniesieniu do pojedynczego zasobu.

Czasowniki reguł

(Te informacje zostały zaczerpnięte z dokumentacji)

Czasownik HTTP	czasownik żądania
POST	create
GET, HEAD	get (dla pojedynczych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (dla obserwowania pojedynczego zasobu lub kolekcji zasobów)
PUT	update
PATCH	patch
DELETE	delete (dla pojedynczych zasobów), deletecollection (dla kolekcji)

Kubernetes czasami sprawdza autoryzację dla dodatkowych uprawnień, używając specjalnych czasowników. Na przykład:

• PodSecurityPolicy

• czasownik use na zasobach podsecuritypolicies w grupie API policy.

• RBAC

• czasowniki bind i escalate na zasobach roles i clusterroles w grupie API rbac.authorization.k8s.io.

• Uwierzytelnianie

• czasownik impersonate na users, groups i serviceaccounts w grupie API core oraz userextras w grupie API authentication.k8s.io.

Możesz znaleźć wszystkie czasowniki, które wspiera każdy zasób, wykonując kubectl api-resources --sort-by name -o wide

Przykłady

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

Na przykład możesz użyć ClusterRole, aby zezwolić określonemu użytkownikowi na uruchomienie:

kubectl get pods --all-namespaces

RoleBinding i ClusterRoleBinding

Z dokumentacji: Binding roli przyznaje uprawnienia zdefiniowane w roli użytkownikowi lub grupie użytkowników. Zawiera listę podmiotów (użytkowników, grup lub kont serwisowych) oraz odniesienie do przyznawanej roli. RoleBinding przyznaje uprawnienia w określonym namespace, podczas gdy ClusterRoleBinding przyznaje dostęp w całym klastrze.

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

Uprawnienia są addytywne, więc jeśli masz clusterRole z „list” i „delete” sekretami, możesz dodać to z Role z „get”. Dlatego bądź świadomy i zawsze testuj swoje role i uprawnienia oraz określ, co jest DOZWOLONE, ponieważ wszystko jest DOMYŚLNIE ZABRONIONE.

Enumerowanie 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

Nadużywanie ról/ClusterRoles do eskalacji uprawnień

Abusing Roles/ClusterRoles in Kubernetes

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.