Kubernetes Role-Based Access Control(RBAC)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Role-Based Access Control (RBAC)

Kubernetes में एक अधिकार मॉड्यूल है जिसे Role-Based Access Control (RBAC) कहा जाता है, जो API सर्वर के लिए उपयोग अनुमति सेट करने में मदद करता है।

RBAC का अनुमति मॉडल तीन व्यक्तिगत भागों से बना है:

1. Role\ClusterRole ­– वास्तविक अनुमति। इसमें नियम होते हैं जो अनुमतियों के सेट का प्रतिनिधित्व करते हैं। प्रत्येक नियम में resources और verbs होते हैं। क्रिया वह क्रिया है जो संसाधन पर लागू होगी।
2. Subject (User, Group या ServiceAccount) – वह वस्तु जो अनुमतियाँ प्राप्त करेगी।

3. RoleBinding\ClusterRoleBinding – Role\ClusterRole और विषय के बीच का संबंध।

“Roles” और “ClusterRoles” के बीच का अंतर केवल यह है कि भूमिका कहाँ लागू होगी – एक “Role” केवल एक विशिष्ट namespace तक पहुँच प्रदान करेगा, जबकि एक “ClusterRole” को क्लस्टर में सभी namespaces में उपयोग किया जा सकता है। इसके अलावा, ClusterRoles भी पहुँच प्रदान कर सकते हैं:

• cluster-scoped संसाधन (जैसे nodes)।

• non-resource endpoints (जैसे /healthz)।

• namespaced संसाधन (जैसे Pods), सभी namespaces में।

Kubernetes 1.6 से आगे, RBAC नीतियाँ डिफ़ॉल्ट रूप से सक्षम होती हैं। लेकिन RBAC को सक्षम करने के लिए आप कुछ इस तरह का उपयोग कर सकते हैं:

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

Templates

In the template of a Role or a ClusterRole you will need to indicate the name of the role, the namespace (in roles) and then the apiGroups, resources and verbs of the role:

• The apiGroups is an array that contains the different API namespaces that this rule applies to. For example, a Pod definition uses apiVersion: v1. यह rbac.authorization.k8s.io या [*] जैसे मान हो सकते हैं।

• The resources is an array that defines which resources this rule applies to. You can find all the resources with: kubectl api-resources --namespaced=true

• The verbs is an array that contains the allowed verbs. The verb in Kubernetes defines the type of action you need to apply to the resource. For example, the list verb is used against collections while "get" is used against a single resource.

Rules Verbs

(This info was taken from the docs)

HTTP verb	request verb

Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:

• PodSecurityPolicy
• use verb on podsecuritypolicies resources in the policy API group.

• RBAC
• bind and escalate verbs on roles and clusterroles resources in the rbac.authorization.k8s.io API group.

• Authentication
• impersonate verb on users, groups, and serviceaccounts in the core API group, and the userextras in the authentication.k8s.io API group.

You can find all the verbs that each resource support executing 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"]

क्लस्टररोल

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

उदाहरण के लिए, आप एक ClusterRole का उपयोग कर सकते हैं ताकि एक विशेष उपयोगकर्ता को चलाने की अनुमति दी जा सके:

kubectl get pods --all-namespaces

RoleBinding और ClusterRoleBinding

दस्तावेज़ों से: एक रोल बाइंडिंग एक भूमिका में परिभाषित अनुमतियों को एक उपयोगकर्ता या उपयोगकर्ताओं के सेट को प्रदान करती है। इसमें विषयों (उपयोगकर्ता, समूह, या सेवा खाते) की एक सूची होती है, और दी जा रही भूमिका का संदर्भ होता है। एक RoleBinding एक विशिष्ट namespace के भीतर अनुमतियाँ प्रदान करता है जबकि एक ClusterRoleBinding उस पहुँच को क्लस्टर-व्यापी प्रदान करता है।

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

अनुमतियाँ जोड़ने योग्य हैं इसलिए यदि आपके पास "सूची" और "हटाएँ" रहस्यों के साथ एक clusterRole है, तो आप इसे "प्राप्त करें" के साथ एक Role के साथ जोड़ सकते हैं। इसलिए सतर्क रहें और हमेशा अपनी भूमिकाओं और अनुमतियों का परीक्षण करें और यह निर्दिष्ट करें कि क्या अनुमत है, क्योंकि डिफ़ॉल्ट रूप से सब कुछ अस्वीकृत है।

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

Abusing Roles/ClusterRoles in Kubernetes

Support HackTricks

• सदस्यता योजनाएँ देखें!
• हमारे 💬 Discord समूह या telegram समूह में शामिल हों या Twitter 🐦 पर हमें फॉलो करें @hacktricks_live.
• हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PR सबमिट करें।