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 zasady, które reprezentują zestaw uprawnień. Każda zasada 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 całym 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)
Czasownik HTTP | czasownik żądania |
---|---|
POST | create |
GET, HEAD | get (dla pojedynczych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (do 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 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.
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)