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 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:
Role\ClusterRole – Rzeczywiste uprawnienie. Zawiera reguły, które reprezentują zestaw uprawnień. Każda reguła zawiera zasoby i czasowniki. Czasownik to akcja, która będzie stosowana do zasobu.
Subject (Użytkownik, Grupa lub ServiceAccount) – Obiekt, który otrzyma uprawnienia.
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:
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.
(Te informacje zostały zaczerpnięte z dokumentacji)
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:
czasownik use
na zasobach podsecuritypolicies
w grupie API policy
.
czasowniki bind
i escalate
na zasobach roles
i clusterroles
w grupie API rbac.authorization.k8s.io
.
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 obsługuje każdy zasób, wykonując kubectl api-resources --sort-by name -o wide
Na przykład możesz użyć ClusterRole, aby zezwolić określonemu użytkownikowi na uruchomienie:
Z dokumentacji: Binding roli przyznaje uprawnienia zdefiniowane w roli użytkownikowi lub zestawowi 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.
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.
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)