# Kubernetes Role-Based Access Control(RBAC)

{{#include ../../banners/hacktricks-training.md}}

## Role-Based Access Control (RBAC)

Kubernetes में एक **अधिकार मॉड्यूल है जिसे Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) कहा जाता है, जो API सर्वर के लिए उपयोग अनुमति सेट करने में मदद करता है।

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

1. **Role\ClusterRole ­–** वास्तविक अनुमति। इसमें _**नियम**_ होते हैं जो अनुमतियों के सेट का प्रतिनिधित्व करते हैं। प्रत्येक नियम में [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) और [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) होते हैं। क्रिया वह क्रिया है जो संसाधन पर लागू होगी।
2. **Subject (User, Group या ServiceAccount) –** वह वस्तु जो अनुमतियाँ प्राप्त करेगी।
3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRole और विषय के बीच का संबंध।

![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png)

“**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

एक **Role** या **ClusterRole** के टेम्पलेट में आपको **भूमिका का नाम**, **namespace** (भूमिकाओं में) और फिर भूमिका के **apiGroups**, **resources** और **verbs** को इंगित करने की आवश्यकता होगी:

- **apiGroups** एक ऐरे है जो विभिन्न **API namespaces** को शामिल करता है जिन पर यह नियम लागू होता है। उदाहरण के लिए, एक Pod परिभाषा apiVersion: v1 का उपयोग करती है। _इसके मान जैसे rbac.authorization.k8s.io या \[\*] हो सकते हैं_।
- **resources** एक ऐरे है जो **यह परिभाषित करता है कि यह नियम किन संसाधनों पर लागू होता है**। आप सभी संसाधनों को पा सकते हैं: `kubectl api-resources --namespaced=true`
- **verbs** एक ऐरे है जो **अनुमत क्रियाओं** को शामिल करता है। Kubernetes में क्रिया उस **क्रिया के प्रकार** को परिभाषित करती है जिसे आपको संसाधन पर लागू करना है। उदाहरण के लिए, सूची क्रिया संग्रहों के खिलाफ उपयोग की जाती है जबकि "get" एकल संसाधन के खिलाफ उपयोग की जाती है।

### Rules Verbs

(_यह जानकारी_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) _से ली गई है_)

| HTTP verb | request verb                                                                                                                                                  |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST      | create                                                                                                                                                        |
| GET, HEAD | get (व्यक्तिगत संसाधनों के लिए), list (संग्रहों के लिए, पूर्ण वस्तु सामग्री सहित), watch (व्यक्तिगत संसाधन या संसाधनों के संग्रह को देखने के लिए) |
| PUT       | update                                                                                                                                                        |
| PATCH     | patch                                                                                                                                                         |
| DELETE    | delete (व्यक्तिगत संसाधनों के लिए), deletecollection (संग्रहों के लिए)                                                                                         |

Kubernetes कभी-कभी विशेष क्रियाओं का उपयोग करके अतिरिक्त अनुमतियों के लिए प्राधिकरण की जांच करता है। उदाहरण के लिए:

- [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
- `podsecuritypolicies` संसाधनों पर `policy` API समूह में `use` क्रिया।
- [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
- `roles` और `clusterroles` संसाधनों पर `rbac.authorization.k8s.io` API समूह में `bind` और `escalate` क्रियाएँ।
- [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
- कोर API समूह में `users`, `groups`, और `serviceaccounts` पर `impersonate` क्रिया, और `authentication.k8s.io` API समूह में `userextras`।

> [!WARNING]
> आप **सभी क्रियाएँ जो प्रत्येक संसाधन का समर्थन करती हैं** को निष्पादित करके पा सकते हैं `kubectl api-resources --sort-by name -o wide`

### Examples
```yaml: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"]
```

```yaml: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"]
```
उदाहरण के लिए, आप एक **ClusterRole** का उपयोग कर सकते हैं ताकि एक विशेष उपयोगकर्ता को चलाने की अनुमति दी जा सके:
```
kubectl get pods --all-namespaces
```
### **RoleBinding और ClusterRoleBinding**

[**दस्तावेज़ों से:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) एक **रोल बाइंडिंग एक भूमिका में परिभाषित अनुमतियों को एक उपयोगकर्ता या उपयोगकर्ताओं के सेट को प्रदान करती है**। इसमें विषयों (उपयोगकर्ता, समूह, या सेवा खाते) की एक सूची होती है, और दी जा रही भूमिका का संदर्भ होता है। एक **RoleBinding** एक विशिष्ट **namespace** के भीतर अनुमतियाँ प्रदान करता है जबकि एक **ClusterRoleBinding** उस पहुँच को **क्लस्टर-व्यापी** प्रदान करता है।
```yaml:RoleBinding
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
```

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

## **RBAC की गणना करना**
```bash
# 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

{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
{{#endref}}

{{#include ../../banners/hacktricks-training.md}}