Hindi - Ht Cloud

Kubernetes Role-Based Access Control(RBAC)

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!

रोल-आधारित पहुँच नियंत्रण (RBAC)

Kubernetes में एक अधिकृति मॉड्यूल है जिसका नाम रोल-आधारित पहुँच नियंत्रण (RBAC) है जो API सर्वर को उपयोग अनुमतियों को सेट करने में मदद करता है।

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

  1. रोल/क्लस्टररोल - वास्तविक अनुमति। इसमें नियम होते हैं जो एक सेट की अनुमतियों को प्रतिष्ठानित करते हैं। प्रत्येक नियम में संसाधन और क्रियाएँ होती हैं। क्रिया संसाधन पर लागू होने वाला कार्य है।

  2. विषय (उपयोगकर्ता, समूह या सेवा खाता) - अनुमतियों को प्राप्त करने वाला वस्तु।

  3. रोलबाइंडिंग/क्लस्टररोलबाइंडिंग - रोल/क्लस्टररोल और विषय के बीच कनेक्शन।

"रोल" और "क्लस्टररोल" के बीच का अंतर केवल यह है कि रोल केवल एक निश्चित नेमस्पेस के लिए पहुँच प्रदान करेगा, जबकि "क्लस्टररोल" क्लस्टर में सभी नेमस्पेस में उपयोग किया जा सकता है। इसके अलावा, क्लस्टररोल द्वारा पहुँच दी जा सकती है:

  • क्लस्टर-स्तरीय संसाधन (जैसे नोड्स)।

  • गैर-संसाधन अंत-बिंदु (जैसे /healthz)।

  • नेमस्पेसवार संसाधन (जैसे पॉड), सभी नेमस्पेस में।

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

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

टेम्पलेट

Role या ClusterRole के टेम्पलेट में आपको रोल का नाम, नेमस्पेस (रोल में) और फिर रोल के apiGroups, resources और verbs को निर्दिष्ट करने की आवश्यकता होगी:

  • apiGroups एक ऐरे है जिसमें इस नियम का प्रयोग होने वाले विभिन्न API नेमस्पेस शामिल होते हैं। उदाहरण के लिए, एक Pod परिभाषा apiVersion: v1 का उपयोग करती है। इसमें rbac.authorization.k8s.io या [*] जैसे मान्यताएं हो सकती हैं।

  • resources एक ऐरे है जो इस नियम का प्रयोग करने वाले संसाधनों को परिभाषित करता है। आप kubectl api-resources --namespaced=true के साथ सभी संसाधनों को खोज सकते हैं।

  • verbs एक ऐरे है जिसमें अनुमति दी गई क्रियाएं शामिल होती हैं। Kubernetes में क्रिया संसाधन को लागू करने के लिए आवश्यक कार्रवाई का प्रकार परिभाषित करती है। उदाहरण के लिए, सूची क्रिया संग्रहों के खिलाफ उपयोग किया जाता है जबकि "प्राप्त" एकल संसाधन के खिलाफ उपयोग किया जाता है।

नियम क्रियाएं

(यह जानकारी यहां से ली गई थी)

HTTP क्रियाअनुरोध क्रिया

POST

create

GET, HEAD

get (व्यक्तिगत संसाधनों के लिए), list (संग्रहों के लिए, पूरे ऑब्जेक्ट सामग्री के साथ), watch (व्यक्तिगत संसाधन या संसाधनों के संग्रह के लिए देखने के लिए)

PUT

update

PATCH

patch

DELETE

delete (व्यक्तिगत संसाधनों के लिए), deletecollection (संग्रहों के लिए)

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

  • PodSecurityPolicy

  • policy API समूह में podsecuritypolicies संसाधनों पर use क्रिया।

  • RBAC

  • rbac.authorization.k8s.io API समूह में roles और clusterroles संसाधनों पर bind और escalate क्रियाएं।

  • Authentication

  • मूल API समूह में users, groups, और serviceaccounts पर impersonate क्रिया, और authentication.k8s.io API समूह में userextras पर।

आप kubectl api-resources --sort-by name -o wide को निष्पादित करके प्रत्येक संसाधन का समर्थित सभी क्रियाएं खोज सकते हैं

उदाहरण

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

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

kubectl get pods --all-namespaces

RoleBinding और ClusterRoleBinding

एक role binding एक उपयोगकर्ता या सेट के लिए एक भूमिका में परिभाषित अनुमतियों को प्रदान करता है। इसमें एक विषयों की सूची (उपयोगकर्ता, समूह या सेवा खाते) और प्रदान की जा रही भूमिका का संदर्भ होता है। RoleBinding एक विशेष नेमस्पेस के भीतर अनुमतियाँ प्रदान करता है जबकि 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
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

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

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

विशेषाधिकार उन्नयन के लिए भूमिका / क्लस्टर भूमिका का दुरुपयोग करें

pageAbusing Roles/ClusterRoles in Kubernetes
हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!
PreviousKubernetes EnumerationNextAbusing Roles/ClusterRoles in Kubernetes

Last updated