Kubelet Authentication & Authorization
Kubelet Authentication
डिफ़ॉल्ट रूप से, kubelet के HTTPS एंडपॉइंट पर अनुरोध जो अन्य कॉन्फ़िगर किए गए प्रमाणीकरण विधियों द्वारा अस्वीकृत नहीं होते हैं, उन्हें गुमनाम अनुरोध के रूप में माना जाता है, और उन्हें system:anonymous
का उपयोगकर्ता नाम और system:unauthenticated
का समूह दिया जाता है।
3 प्रमाणीकरण विधियाँ हैं:
गुमनाम (डिफ़ॉल्ट): सेटिंग का उपयोग करते हुए पैरामीटर
--anonymous-auth=true
या कॉन्फ़िग:
Webhook: यह kubectl API bearer tokens को प्रमाणीकरण के रूप में सक्षम करेगा (कोई भी मान्य टोकन मान्य होगा)। इसे अनुमति दें:
सुनिश्चित करें कि
authentication.k8s.io/v1beta1
API समूह API सर्वर में सक्षम हैkubelet को
--authentication-token-webhook
और--kubeconfig
ध्वजों के साथ प्रारंभ करें या निम्नलिखित सेटिंग का उपयोग करें:
kubelet TokenReview
API को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि उपयोगकर्ता जानकारी को बियरर टोकन से निर्धारित किया जा सके
X509 क्लाइंट सर्टिफिकेट: X509 क्लाइंट सर्टिफिकेट के माध्यम से प्रमाणीकरण की अनुमति देता है
अधिक विवरण के लिए apiserver प्रमाणीकरण दस्तावेज़ देखें
--client-ca-file
ध्वज के साथ kubelet शुरू करें, क्लाइंट सर्टिफिकेट को सत्यापित करने के लिए एक CA बंडल प्रदान करें। या कॉन्फ़िग के साथ:
Kubelet Authorization
कोई भी अनुरोध जो सफलतापूर्वक प्रमाणित होता है (जिसमें एक गुमनाम अनुरोध भी शामिल है) फिर अधिकृत किया जाता है। डिफ़ॉल्ट अधिकरण मोड AlwaysAllow
है, जो सभी अनुरोधों की अनुमति देता है।
हालांकि, अन्य संभावित मान webhook
है (जो आप ज्यादातर वहाँ पाएंगे)। यह मोड प्रमाणित उपयोगकर्ता के अनुमतियों की जांच करेगा ताकि किसी क्रिया की अनुमति या अस्वीकृति की जा सके।
ध्यान दें कि भले ही गुमनाम प्रमाणीकरण सक्षम हो, गुमनाम पहुंच को किसी भी क्रिया को करने के लिए कोई अनुमतियाँ नहीं हो सकती।
वेबहुक के माध्यम से अधिकरण को पैरामीटर --authorization-mode=Webhook
का उपयोग करके या कॉन्फ़िग फ़ाइल के माध्यम से कॉन्फ़िगर किया जा सकता है:
The kubelet SubjectAccessReview
API को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि यह निर्धारित किया जा सके कि क्या प्रत्येक अनुरोध अधिकार प्राप्त है।
kubelet API अनुरोधों को उसी अनुरोध विशेषताओं के दृष्टिकोण का उपयोग करके अधिकृत करता है जैसे कि apiserver:
क्रिया
HTTP क्रिया | अनुरोध क्रिया |
---|---|
POST | बनाना |
GET, HEAD | प्राप्त करना (व्यक्तिगत संसाधनों के लिए), सूची (संग्रहों के लिए, जिसमें पूर्ण वस्तु सामग्री शामिल है), देखना (व्यक्तिगत संसाधन या संसाधनों के संग्रह को देखने के लिए) |
PUT | अद्यतन |
PATCH | पैच |
DELETE | हटाना (व्यक्तिगत संसाधनों के लिए), हटाने का संग्रह (संग्रहों के लिए) |
Kubelet API से बात करने वाला संसाधन हमेशा नोड्स होता है और उप-संसाधन आने वाले अनुरोध के पथ से निर्धारित होता है:
Kubelet API | संसाधन | उप-संसाधन |
---|---|---|
/stats/* | नोड्स | आंकड़े |
/metrics/* | नोड्स | मेट्रिक्स |
/logs/* | नोड्स | लॉग |
/spec/* | नोड्स | स्पेक |
अन्य सभी | नोड्स | प्रॉक्सी |
उदाहरण के लिए, निम्नलिखित अनुरोध ने अनुमति के बिना kubelet के पॉड्स जानकारी तक पहुँचने की कोशिश की:
हमें Forbidden मिला, इसलिए अनुरोध Authentication check को पास कर गया। यदि नहीं, तो हमें केवल एक
Unauthorised
संदेश मिलता।हम username देख सकते हैं (इस मामले में टोकन से)
जांचें कि resource nodes था और subresource proxy (जो पिछले जानकारी के साथ समझ में आता है)
References
Last updated