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 ina moduli yaidhinisha inayoitwa Role-Based Access Control (RBAC) ambayo husaidia kuweka ruhusa za matumizi kwa seva ya API.
Mfano wa ruhusa wa RBAC umejengwa kutoka sehemu tatu tofauti:
Role\ClusterRole – Ruhusa halisi. Inajumuisha kanuni zinazowrepresenta seti ya ruhusa. Kila kanuni ina rasilimali na vitenzi. Kitenzi ni kitendo ambacho kitawekwa kwenye rasilimali.
Subject (Mtumiaji, Kundi au Akaunti ya Huduma) – Kitu ambacho kitapokea ruhusa.
RoleBinding\ClusterRoleBinding – Muunganisho kati ya Role\ClusterRole na subject.
Tofauti kati ya “Roles” na “ClusterRoles” ni mahali ambapo jukumu litatumika – “Role” itatoa ufikiaji kwa namespace moja maalum, wakati “ClusterRole” inaweza kutumika katika namespaces zote katika klasta. Zaidi ya hayo, ClusterRoles zinaweza pia kutoa ufikiaji kwa:
rasilimali za kiwango cha klasta (kama vile nodi).
mipangilio isiyo ya rasilimali (kama vile /healthz).
rasilimali zenye majina (kama Pods), katika namespaces zote.
Kuanzia Kubernetes 1.6 kuendelea, sera za RBAC zime wezeshwa kwa default. Lakini ili kuwezesha RBAC unaweza kutumia kitu kama:
Katika template ya Role au ClusterRole utahitaji kuashiria jina la jukumu, namespace (katika roles) na kisha apiGroups, resources na verbs za jukumu:
apiGroups ni array inayojumuisha API namespaces tofauti ambazo sheria hii inatumika. Kwa mfano, ufafanuzi wa Pod unatumia apiVersion: v1. Inaweza kuwa na thamani kama rbac.authorization.k8s.io au [*].
resources ni array inayofafanua ni rasilimali zipi sheria hii inatumika. Unaweza kupata rasilimali zote kwa: kubectl api-resources --namespaced=true
verbs ni array inayojumuisha vitendo vilivyokubaliwa. Kitenzi katika Kubernetes kinafafanua aina ya hatua unahitaji kutekeleza kwa rasilimali. Kwa mfano, kitenzi la orodha linatumika dhidi ya makusanyo wakati "pata" linatumika dhidi ya rasilimali moja.
(Taarifa hii ilichukuliwa kutoka the docs)
HTTP verb | request verb |
---|---|
POST | tengeneza |
GET, HEAD | pata (kwa rasilimali binafsi), orodha (kwa makusanyo, ikiwa ni pamoja na maudhui kamili ya kitu), angalia (kwa kuangalia rasilimali binafsi au mkusanyiko wa rasilimali) |
PUT | sasisha |
PATCH | patch |
DELETE | futa (kwa rasilimali binafsi), futakoleksiyoni (kwa makusanyo) |
Kubernetes wakati mwingine huangalia idhini kwa ruhusa za ziada kwa kutumia vitendo maalum. Kwa mfano:
kitenzi use
kwenye rasilimali podsecuritypolicies
katika kundi la API policy
.
vitendo bind
na escalate
kwenye rasilimali roles
na clusterroles
katika kundi la API rbac.authorization.k8s.io
.
kitenzi impersonate
kwenye users
, groups
, na serviceaccounts
katika kundi la API msingi, na userextras
katika kundi la API authentication.k8s.io
.
Unaweza kupata vitendo vyote ambavyo kila rasilimali inasaidia ukitekeleza kubectl api-resources --sort-by name -o wide
Kwa mfano, unaweza kutumia ClusterRole kumruhusu mtumiaji maalum kuendesha:
Kutoka kwenye nyaraka: Kifungo cha jukumu kinatoa ruhusa zilizofafanuliwa katika jukumu kwa mtumiaji au seti ya watumiaji. Kinashikilia orodha ya wahusika (watumiaji, vikundi, au akaunti za huduma), na rejeleo kwa jukumu linalotolewa. RoleBinding inatoa ruhusa ndani ya namespace maalum wakati ClusterRoleBinding inatoa ufikiaji huo kote kwenye klasta.
Ruhusa ni za kuongezeka hivyo ikiwa una clusterRole yenye “orodhesha” na “futa” siri unaweza kuiongeza na Role yenye “pata”. Hivyo kuwa makini na kila wakati jaribu majukumu yako na ruhusa na eleza kile kinachoruhusiwa, kwa sababu kila kitu kinakataliwa kwa msingi.
Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)