Kubernetes Role-Based Access Control(RBAC)

Support HackTricks

Role-Based Access Control (RBAC)

Kubernetes ina moduli ya idhini 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:

  1. Role\ClusterRole ­– Ruhusa halisi. Inajumuisha kanuni zinazowrepresenta seti ya ruhusa. Kila kanuni ina rasilimali na vitenzi. Kitenzi ni kitendo ambacho kitawekwa kwenye rasilimali.

  2. Subject (Mtumiaji, Kundi au Akaunti ya Huduma) – Kitu ambacho kitapokea ruhusa.

  3. 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 namespace zote katika klasta. Zaidi ya hayo, ClusterRoles zinaweza pia kutoa ufikiaji kwa:

  • Rasilimali za cluster-scoped (kama nodes).

  • Mipangilio ya non-resource (kama /healthz).

  • Rasilimali za namespaced (kama Pods), katika namespace zote.

Kuanzia Kubernetes 1.6 kuendelea, sera za RBAC zime wezeshwa kwa default. Lakini ili kuwezesha RBAC unaweza kutumia kitu kama:

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

Templates

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 inayoshikilia 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 inayoshikilia 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.

Rules Verbs

(Taarifa hii ilichukuliwa kutoka the docs)

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

Examples

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

Kwa mfano, unaweza kutumia ClusterRole kumruhusu mtumiaji maalum kuendesha:

kubectl get pods --all-namespaces

RoleBinding na ClusterRoleBinding

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.

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

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.

Kuhesabu 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

Abuse Role/ClusterRoles for Privilege Escalation

Support HackTricks

Last updated