कुबेरनेट्स में आरबीएसी को समझना

लगभग। ट्रांस। : यह लेख जेवियर सैल्मरॉन द्वारा लिखा गया था, जो बिटमनी में प्रसिद्ध कुबेरनेट्स समुदाय के एक इंजीनियर थे, और अगस्त की शुरुआत में सीएनसीएफ ब्लॉग पर प्रकाशित हुए थे। लेखक आरबीएसी (भूमिका-आधारित अभिगम नियंत्रण) तंत्र की बहुत मूल बातें करता है जो कुबेरनेट्स में डेढ़ साल पहले दिखाई दिया था। सामग्री उन लोगों के लिए विशेष रूप से उपयोगी होगी जो K8s के प्रमुख घटकों के उपकरण से परिचित हैं (अंत में अन्य समान लेखों के लिंक देखें)।


कुबेरनेट्स 1.6 की रिलीज़ के अवसर पर एक Google कर्मचारी द्वारा की गई प्रस्तुति से स्लाइड

कई अनुभवी कुबेरनेट्स उपयोगकर्ता कुबेरनेट्स 1.6 रिलीज को याद कर सकते हैं, जब रोल-आधारित एक्सेस कंट्रोल (आरबीएसी) आधारित प्राधिकरण बीटा बन गया। तो एक वैकल्पिक प्रमाणीकरण तंत्र दिखाई दिया, जो पहले से मौजूद मौजूदा, लेकिन प्रबंधन और समझने में मुश्किल है, विशेषता-आधारित अभिगम नियंत्रण (ABAC)। सभी ने उत्साहपूर्वक नई सुविधा का स्वागत किया, लेकिन एक ही समय में अनगिनत उपयोगकर्ता निराश हो गए। StackOverflow और GitHub ने RBAC के प्रतिबंधों की रिपोर्ट को रोक दिया क्योंकि अधिकांश प्रलेखन और उदाहरणों ने RBAC को ध्यान में नहीं रखा (लेकिन अब सब कुछ ठीक है)। संदर्भ उदाहरण हेलम था: सिर्फ हेल्म helm init + हेलम helm install अब काम नहीं करता। अचानक हमें वर्डप्रेस या RoleBindings साथ चार्ट को तैनात करने से पहले "अजीब" तत्वों जैसे ServiceAccounts या RoleBindings को जोड़ने की आवश्यकता थी (इस बारे में और निर्देश देखें)।

इन असफल पहले प्रयासों को छोड़कर, कोई भी आरबीएसी द्वारा कुबेरनेट्स को उत्पादन-तैयार मंच में बदलने के लिए किए गए भारी योगदान से इनकार नहीं कर सकता है। हम में से कई कुबेरनेट्स के साथ पूर्ण प्रशासक विशेषाधिकारों के साथ खेलने में कामयाब रहे, और हम पूरी तरह से समझते हैं कि वास्तविक वातावरण में यह आवश्यक है:

• विभिन्न उपयोगकर्ताओं के पास कई गुण हैं जो वांछित प्रमाणीकरण तंत्र प्रदान करते हैं।
• प्रत्येक उपयोगकर्ता या उपयोगकर्ताओं के समूह क्या कार्य कर सकते हैं, इस पर पूर्ण नियंत्रण रखें।
• हृदय में प्रत्येक प्रक्रिया क्या संचालन कर सकती है, इस पर पूरा नियंत्रण रखें।
• नामस्थानों में कुछ संसाधनों की दृश्यता को सीमित करें।

और इस संबंध में, आरबीएसी एक प्रमुख तत्व है जो बहुत आवश्यक क्षमताओं को प्रदान करता है। लेख में, हम जल्दी से मूल बातों के माध्यम से जाएंगे ( इस वीडियो को विवरण के लिए देखें; अंग्रेजी में 1 घंटे की बिटनामी वेबिनार लिंक का अनुसरण करें - लगभग अनुवाद। ) और सबसे भ्रमित क्षणों में थोड़ा गहरा जाएं।

कुबेरनेट्स में आरबीएसी को समझने की कुंजी

आरबीएसी के विचार को पूरी तरह से समझने के लिए, आपको यह समझने की आवश्यकता है कि इसमें तीन तत्व शामिल हैं:

• विषय - उपयोगकर्ताओं और प्रक्रियाओं का एक सेट जो कुबेरनेट्स एपीआई तक पहुंच चाहते हैं;
• संसाधन - एक क्लस्टर में उपलब्ध कुबेरनेट्स एपीआई वस्तुओं का संग्रह। उनके उदाहरण (दूसरों के बीच) पॉड्स , डिप्लॉयमेंट्स , सर्विसेज , नोड्स , पर्सिस्टेंटवोल्यूम हैं ;
• क्रिया (क्रिया) - संचालन का एक सेट जो संसाधनों पर किया जा सकता है। विभिन्न क्रियाएं (प्राप्त करें, देखें, बनाएं, हटाएं, आदि) हैं, लेकिन ये सभी अंततः CRUD ऑपरेशन हैं (क्रिएट, रीड, अपडेट, डिलीट)।

इन तीन तत्वों को ध्यान में रखते हुए, RBAC का मुख्य विचार है:

"हम विषयों, एपीआई संसाधनों और संचालन को जोड़ना चाहते हैं।" दूसरे शब्दों में, हम किसी दिए गए उपयोगकर्ता के लिए संकेत करना चाहते हैं जो विभिन्न प्रकार के संसाधनों पर किया जा सकता है।

एपीआई में RBAC ऑब्जेक्ट्स को समझना

इन तीन प्रकार की संस्थाओं को मिलाकर, कुबेरनेट्स एपीआई में उपलब्ध आरबीएसी वस्तुएं स्पष्ट हो जाती हैं:

• Roles संसाधनों और क्रियाओं को जोड़ती हैं। विभिन्न विषयों के लिए उनका पुन: उपयोग किया जा सकता है। एक नामस्थान (हम एक से अधिक [नामस्थान] का प्रतिनिधित्व करने वाले टेम्प्लेट का उपयोग नहीं कर सकते, लेकिन हम एक ही भूमिका ऑब्जेक्ट को विभिन्न नामस्थानों पर तैनात कर सकते हैं)। यदि आप भूमिका को पूरे क्लस्टर में लागू करना चाहते हैं, तो समान ClusterRoles ऑब्जेक्ट है।
• RoleBindings शेष इकाई संस्थाओं को जोड़ती है। एक ऐसी भूमिका को निर्दिष्ट करके, जो पहले से ही एपीआई वस्तुओं को क्रियाओं से जोड़ देती है, अब हम उन विषयों का चयन करते हैं जो उनका उपयोग कर सकते हैं। क्लस्टर स्तर के लिए बराबर (यानी नामस्थानों के लिए बाध्य किए बिना) ClusterRoleBindings ।

नीचे दिए गए उदाहरण में, हम उपयोगकर्ता को jsalmeron को पढ़ने, सूची प्राप्त करने, और परीक्षण नाम में चूल्हा बनाने का अधिकार देते हैं। इसका अर्थ है कि jsalmeron इन कमांड्स को निष्पादित करने में सक्षम होगा:

 kubectl get pods --namespace test kubectl describe pod --namespace test pod-name kubectl create --namespace test -f pod.yaml #      

... लेकिन ऐसा नहीं है:

 kubectl get pods --namespace kube-system #    kubectl get pods --namespace test -w #    watch 

YAML फ़ाइलों के उदाहरण:

 kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: pod-read-create namespace: test rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "create"] 

 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: salme-pods namespace: test subjects: - kind: User name: jsalmeron apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-read-create apiGroup: rbac.authorization.k8s.io 

एक और दिलचस्प बिंदु यह है: अब जब उपयोगकर्ता फली बना सकता है, तो हम कितना सीमित कर सकते हैं? इसके लिए अन्य ऑब्जेक्ट्स की आवश्यकता होगी जो सीधे RBAC विनिर्देश से संबंधित नहीं हैं और आपको संसाधन सीमाएँ कॉन्फ़िगर करने की अनुमति देते हैं: ResourceQuota और LimitRanges । ऐसे महत्वपूर्ण क्लस्टर घटक को कॉन्फ़िगर करते समय वे निश्चित रूप से खोज के लायक होते हैं [जैसा कि चूल्हा बनाना]।

विषय: उपयोगकर्ता और ... ServiceAccounts?

विषयों के संदर्भ में कई कुबेरनेट उपयोगकर्ता जिन कठिनाइयों का सामना करते हैं, उनमें से एक नियमित उपयोगकर्ताओं और ServiceAccounts बीच का अंतर है। सिद्धांत रूप में, सब कुछ सरल है:

• Users - वैश्विक उपयोगकर्ता, जो क्लस्टर के बाहर रहने वाले लोगों या प्रक्रियाओं के लिए डिज़ाइन किए गए हैं;
• ServiceAccounts - नेमस्पेस द्वारा सीमित और पॉड्स पर चलने वाले क्लस्टर के भीतर प्रक्रियाओं के लिए अभिप्रेत है।

दोनों प्रकार की समानता कई संसाधनों पर कुछ संचालन करने के लिए एपीआई के साथ प्रमाणित करने की आवश्यकता में निहित है, और उनके विषय क्षेत्र बहुत विशिष्ट लगते हैं। वे समूहों से भी संबंधित हो सकते हैं, इसलिए RoleBinding एक से अधिक विषयों को बाँधने की अनुमति देती है (हालाँकि केवल एक समूह के लिए अनुमति दी जाती है ServiceAccounts - system:serviceaccounts )। हालांकि, मुख्य अंतर सिरदर्द का कारण है: उपयोगकर्ताओं के पास कुबेरनेट्स एपीआई में उनके अनुरूप वस्तुएं नहीं हैं। यह पता चला है कि इस तरह के एक ऑपरेशन मौजूद है:

 kubectl create serviceaccount test-service-account # OK 

... लेकिन यह एक चला गया है:

 kubectl create user jsalmeron # ! 

इस स्थिति का एक गंभीर परिणाम है: यदि क्लस्टर उपयोगकर्ताओं के बारे में जानकारी संग्रहीत नहीं करता है, तो व्यवस्थापक को क्लस्टर के बाहर खातों का प्रबंधन करना होगा। समस्या को हल करने के लिए अलग-अलग तरीके हैं: टीएलएस प्रमाण पत्र, टोकन, OAuth2, आदि।

इसके अलावा, आपको kubectl संदर्भों को बनाने की आवश्यकता होगी kubectl हम इन नए खातों के माध्यम से क्लस्टर तक पहुंच सकें। उनके साथ फाइलें बनाने के लिए, आप kubectl config कमांड का उपयोग कर सकते हैं (जिसे कुबेरनेट एपीआई तक पहुंच की आवश्यकता नहीं है, इसलिए उन्हें किसी भी उपयोगकर्ता द्वारा निष्पादित किया जा सकता है)। उपरोक्त वीडियो में टीएलएस प्रमाण पत्र के साथ एक उपयोगकर्ता बनाने का एक उदाहरण है।

तैनाती में RBAC: उदाहरण

हमने एक उदाहरण देखा जिसमें निर्दिष्ट उपयोगकर्ता को क्लस्टर में संचालन के अधिकार दिए गए हैं। लेकिन Kubernetes API तक पहुंच की आवश्यकता वाले तैनाती के बारे में क्या? बेहतर समझ पाने के लिए एक विशिष्ट परिदृश्य पर विचार करें।

उदाहरण के लिए लोकप्रिय इन्फ्रास्ट्रक्चर एप्लिकेशन - RabbitMQ लें। हम RabbitMQ के लिए Bitnami (आधिकारिक helm / चार्ट रिपॉजिटरी से) के लिए Helm चार्ट का उपयोग करेंगे, जो कि Bitnami / rabbitmq कंटेनर का उपयोग करता है। कुबेरनेट्स के लिए एक प्लगइन कंटेनर में बनाया गया है, जो कि रैबिटएमक्यू क्लस्टर के अन्य सदस्यों का पता लगाने के लिए जिम्मेदार है। इस वजह से, कंटेनर के अंदर की प्रक्रिया को कुबेरनेट्स एपीआई तक पहुंच की आवश्यकता होती है, और हमें सही आरबीएसी विशेषाधिकारों के साथ सर्विसअकाउंट को कॉन्फ़िगर करने की आवश्यकता है।

जब यह ServiceAccounts बात आती है, तो इस अच्छे अभ्यास का पालन करें:

- हर तैनाती के लिए ServiceAccounts को कॉन्फ़िगर करें विशेषाधिकारों के न्यूनतम सेट के साथ।

कुबेरनेट एपीआई तक पहुंच की आवश्यकता वाले अनुप्रयोगों के लिए, आपको "विशेषाधिकार प्राप्त ServiceAccount " के कुछ प्रकार बनाने के लिए लुभाया जा सकता है जो क्लस्टर में लगभग कुछ भी कर सकते हैं। हालांकि यह एक सरल समाधान की तरह लगता है, यह अंततः एक सुरक्षा भेद्यता को जन्म दे सकता है जो अवांछित संचालन की अनुमति दे सकता है। (वीडियो एक टिलर [हेल्म घटक] के उदाहरण और महान विशेषाधिकार के साथ ServiceAccounts होने के परिणामों को देखता है।)

इसके अलावा, एपीआई तक पहुंच के मामले में अलग-अलग तैनाती की अलग-अलग जरूरतें होंगी, इसलिए प्रत्येक तैनाती के लिए अलग-अलग ServiceAccounts ।

इसे ध्यान में रखते हुए, आइए देखें कि आरबीएसी कॉन्फ़िगरेशन आरबेटीएमक्यू के साथ तैनाती के मामले के लिए सही है।

प्लगइन के प्रलेखन और इसके स्रोत कोड में, आप देख सकते हैं कि यह कुबेरनेट्स एपीआई से एंडपॉइंट की एक सूची का अनुरोध कर रहा है। इस तरह से रैबिटएमक्यू क्लस्टर के शेष सदस्यों का पता लगाया जाता है। इसलिए, Bitnami RabbitMQ चार्ट बनाता है:

• RabbitMQ के साथ सुनवाई के लिए सेवा
  
  

   {{- if .Values.rbacEnabled }} apiVersion: v1 kind: ServiceAccount metadata: name: {{ template "rabbitmq.fullname" . }} labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" {{- end }} 

• भूमिका (हम मानते हैं कि संपूर्ण रैबिटएमक्यू क्लस्टर एकल नामस्थान में तैनात है), क्रिया को समापन बिंदु संसाधन के लिए अनुमति देता है:
  
  

   {{- if .Values.rbacEnabled }} kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template "rabbitmq.fullname" . }}-endpoint-reader labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" rules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get"] {{- end }} 

• रोलबाइंडिंग ServiceAccount को एक भूमिका से जोड़ते हुए:
  
  

   {{- if .Values.rbacEnabled }} kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: {{ template "rabbitmq.fullname" . }}-endpoint-reader labels: app: {{ template "rabbitmq.name" . }} chart: {{ template "rabbitmq.chart" . }} release: "{{ .Release.Name }}" heritage: "{{ .Release.Service }}" subjects: - kind: ServiceAccount name: {{ template "rabbitmq.fullname" . }} roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: {{ template "rabbitmq.fullname" . }}-endpoint-reader {{- end }} 

आरेख से पता चलता है कि हमने एंडपॉइंट ऑब्जेक्ट पर संचालन प्राप्त करने के लिए रैबिटएमक्यू पॉड्स में चलने वाली प्रक्रियाओं की अनुमति दी। यह संचालन का न्यूनतम सेट है जो काम करने के लिए आवश्यक है। उसी समय, हम जानते हैं कि तैनात चार्ट सुरक्षित है और कुबेरनेट क्लस्टर के अंदर अवांछित कार्रवाई नहीं करेगा।

अंतिम विचार

उत्पादन में कुबेरनेट्स के साथ काम करने के लिए, आरबीएसी नीतियां वैकल्पिक नहीं हैं। उन्हें एपीआई वस्तुओं के एक सेट के रूप में नहीं माना जा सकता है जो केवल प्रशासकों को पता होना चाहिए। डेवलपर्स को वास्तव में सुरक्षित अनुप्रयोगों को तैनात करने और क्लाउड-देशी अनुप्रयोगों के लिए कुबेरनेट्स एपीआई द्वारा पेश की जाने वाली क्षमता का पूरा लाभ उठाने की आवश्यकता है। RBAC पर अधिक जानकारी इन लिंक पर देखी जा सकती है:

• बिटनामी दस्तावेज: " अपने कुबेरनेट क्लस्टर में आरबीएसी को कॉन्फ़िगर करें ";
• कुबेरनेट्स प्रलेखन: "आरबीएसी प्राधिकरण का उपयोग करना ।"

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

• " 11 तरीके (नॉट) कुबेरनेट्स हैकिंग का शिकार बनें ";
• “ कुबेरनेट्स में क्या होता है जब कुबलेटल रन शुरू होता है? भाग 1 ”;
• " कुबेरनेट्स अनुसूचक वास्तव में कैसे काम करता है?" ";
• " कुबेरनेट्स पर नेटवर्क के दृश्यों के पीछे ";
• " छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव " (वीडियो रिपोर्ट, जिसमें कुबेरनेट्स तकनीकी उपकरण का परिचय शामिल है) ।