Kubernetes Role-Based Access Control(RBAC)

Reading time: 7 minutes

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

एक 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 से ली गई है)

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

• PodSecurityPolicy
• podsecuritypolicies संसाधनों पर policy API समूह में use क्रिया।
• RBAC
• roles और clusterroles संसाधनों पर rbac.authorization.k8s.io API समूह में bind और escalate क्रियाएँ।
• Authentication
• कोर API समूह में users, groups, और serviceaccounts पर impersonate क्रिया, और authentication.k8s.io API समूह में userextras।

Examples

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