Kubernetes Role-Based Access Control(RBAC)

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

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 HTTPczasownik żądania
POSTcreate
GET, HEADget (dla pojedynczych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (do obserwowania pojedynczego zasobu lub kolekcji zasobów)
PUTupdate
PATCHpatch
DELETEdelete (dla pojedynczych zasobów), deletecollection (dla kolekcji)

Kubernetes czasami sprawdza autoryzację dla dodatkowych uprawnień za pomocą 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.
  • Authentication
  • czasownik impersonate na users, groups i serviceaccounts w grupie API core oraz userextras w grupie API authentication.k8s.io.

Warning

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

Przykłady

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

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

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

Wykorzystanie ról/ClusterRoles do eskalacji uprawnień

Abusing Roles/ClusterRoles in Kubernetes

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks