Kubernetes में RBAC की जाँच करना

कुबेरनेट क्लस्टर को सुरक्षित करना एक बात है, लेकिन सुरक्षा बनाए रखना अभी भी एक चुनौती है। हालाँकि, कुबेरनेट्स में नए उपकरण जोड़े गए हैं: अब दोनों को करना बहुत आसान है।

कुबेरनेट्स (संस्करण 1.6 के साथ शुरू) ने भूमिका-आधारित अभिगम नियंत्रण (आरबीएसी) की अवधारणा पेश की, जो प्रशासकों को क्लस्टर उपयोगकर्ताओं के लिए प्रतिबंध नीतियों को परिभाषित करने की अनुमति देता है। यही है, आप एक उपयोगकर्ता को सीमित पहुंच के साथ बनाते हैं: रहस्य या कुछ नामस्थानों जैसे संसाधनों तक उपयोगकर्ता की पहुंच सीमित करें।

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

• https://medium.com/containerum/configuring-permissions-in-kubernetes-with-rbac-a456a9717d5d
• https://www.cncf.io/blog/2018/08/01/demystifying-rbac-in-kubernetes/
• https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/
• https://kubernetes.io/docs/reference/access-authn-authz/rbac/

अपने व्यवसाय की आवश्यकताओं को पूरा करने के तरीके पर ध्यान देना बेहतर है, और देखें कि क्या आरबीएसी ऑब्जेक्ट जो चल रहे हैं, उन्हें यह देखने के लिए जांचने की आवश्यकता है कि क्या वे अपने कार्य करते हैं।

हमारी लिपि

कुछ संगठन नए Kubernetes क्लस्टर के साथ काम करने के लिए कई समूहों को स्वीकार करते हैं। एक आवश्यकता है: आप एक पड़ोसी समूह की तैनाती में हस्तक्षेप नहीं कर सकते हैं, ताकि कोई अप्रत्याशित अंतरसमूह समस्याएं या डाउनटाइम्स न हों।

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

एक हफ्ता बीत गया। क्लस्टर के मालिक ने देखा कि एक पृथक नाम स्थान का उपयोगकर्ता किसी अन्य नामस्थान से रहस्य पढ़ रहा है। ऐसा कैसे? उन्होंने RBAC का इस्तेमाल किया!

मैंने इसे लागू किया, लेकिन, कोड के साथ काम करने के रूप में, सिस्टम को वांछित परिणाम के अनुपालन के लिए परीक्षण किया जाना चाहिए। यह अच्छा है कि kubectl CLI Kubernetes kubectl RBAC कॉन्फ़िगरेशन की जाँच के लिए उपकरणों का एक सेट प्रदान करता है। kubectl auth can-i

क्या मैं? ("क्या मैं?")
can-i एपीआई का उपयोग करके यह देखने के लिए जांच कर सकता हूं कि क्या एक निश्चित कार्रवाई की जा सकती है। वह निम्नलिखित मापदंडों का उपयोग करता है: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] । अब वर्तमान उपयोगकर्ता जांच कर सकता है कि क्या उसके लिए कोई विशिष्ट कार्रवाई उपलब्ध है। आइए जाने:

 kubectl auth can-i create pods 

यह उचित निकास कोड के साथ "हां" या "नहीं" प्रतिक्रिया वापस करना चाहिए।

हालांकि, जब किसी अन्य उपयोगकर्ता के अधिकारों की जांच करने की कोशिश की जाती है, तो हम एक समस्या भर में आते हैं: वह उपयोगकर्ता जिसके अंतर्गत हम क्लस्टर में अधिकृत हैं ./kube/config कॉन्फ़िग फ़ाइल में निर्दिष्ट किया गया है, और अलग-अलग उपयोगकर्ताओं के परीक्षण के लिए अलग-अलग कॉन्फ़िगर होना असुविधाजनक है। सौभाग्य से, कुबेरनेट्स फिर से बचाव में आता है: यह --as --as= और --as-group= टैग का उपयोग करके उपयोगकर्ताओं को अनुकरण करने में सक्षम है।

कमांड को अपडेट करें, किसी अन्य उपयोगकर्ता के सिमुलेशन का उपयोग करें:

 kubectl auth can-i create pods --as=me 

हमें देखना चाहिए कि बाहर निकलने के कोड 1 , प्रतिक्रिया "नहीं" वापस आ गई है।

और यह बहुत अच्छा है, क्योंकि अब हमारे पास कमांड का एक सेट है, जो हमें यह जांचने की अनुमति देता है कि उपयोगकर्ता या उपयोगकर्ताओं के समूह के पास कुबेरनेट्स के किसी भी संसाधन तक पहुंच है - पॉड्स देखने से लेकर रहस्य हटाने तक।

स्वचालन

हालाँकि, इसे रोकना बहुत जल्दी है: अब हम एक परीक्षण अनुक्रम को लागू करने में सक्षम हैं जो आवश्यकताओं की सूची का वर्णन करेगा और इसे सीडी पाइपलाइन के हिस्से के रूप में चलाएगा। कारण के लिए!

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

नीचे एक परीक्षण चलाने का एक उदाहरण है। यह आरबीएसी नियमों के संचालन की जांच करता है जो किसी समूह के उपयोगकर्ता को नामस्थान में चल रहे चूल्हों की संख्या को बदलने की अनुमति देता है। इसे निष्पादित किया जाता है यदि "निष्पादन योग्य" विशेषता सेट की गई है। या - bats filename का उपयोग कर।

 #!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done } 

--as और --as-group को निम्नलिखित RBAC नियमों के उपयोग की आवश्यकता होती है:

 rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create 

कुबेरनेट्स में अपने आरबीएसी नियमों पर जांच को लागू करने के लिए यहां एक सरल विधि है। इसे कुबेरनेट पाइप लाइन का हिस्सा बनाकर, हम आरबीएसी नीति को काफी मजबूत करेंगे। विधि का व्यवहार में परीक्षण किया गया है: उन परिवर्तनों को पकड़ना जो एक्सेस नीतियों का उल्लंघन करते हैं, बहुत तेज है!

इस पोस्ट को पढ़ने के लिए समय निकालने के लिए धन्यवाद!