Kubelet Authentication & Authorization

Reading time: 5 minutes

Kubelet Authentication

From the docss:

डिफ़ॉल्ट रूप से, kubelet के HTTPS एंडपॉइंट पर अनुरोध जो अन्य कॉन्फ़िगर किए गए प्रमाणीकरण विधियों द्वारा अस्वीकृत नहीं होते हैं, उन्हें अनाम अनुरोध के रूप में माना जाता है, और उन्हें system:anonymous का उपयोगकर्ता नाम और system:unauthenticated का समूह दिया जाता है।

3 प्रमाणीकरण विधियाँ हैं:

• अनाम (डिफ़ॉल्ट): सेटिंग का उपयोग करें पैरामीटर --anonymous-auth=true या कॉन्फ़िग:

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook: यह kubectl API bearer tokens को प्रमाणीकरण के रूप में सक्षम करेगा (कोई भी मान्य टोकन मान्य होगा)। इसे अनुमति दें:
• सुनिश्चित करें कि authentication.k8s.io/v1beta1 API समूह API सर्वर में सक्षम है
• kubelet को --authentication-token-webhook और --kubeconfig ध्वजों के साथ प्रारंभ करें या निम्नलिखित सेटिंग का उपयोग करें:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

• X509 क्लाइंट सर्टिफिकेट: X509 क्लाइंट सर्टिफिकेट के माध्यम से प्रमाणीकरण की अनुमति देता है
• अधिक विवरण के लिए apiserver authentication documentation देखें
• --client-ca-file फ्लैग के साथ kubelet शुरू करें, क्लाइंट सर्टिफिकेट को सत्यापित करने के लिए CA बंडल प्रदान करते हुए। या कॉन्फ़िगरेशन के साथ:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

कोई भी अनुरोध जो सफलतापूर्वक प्रमाणित होता है (जिसमें एक गुमनाम अनुरोध भी शामिल है) फिर अधिकृत किया जाता है। डिफ़ॉल्ट अधिकरण मोड AlwaysAllow है, जो सभी अनुरोधों की अनुमति देता है।

हालांकि, अन्य संभावित मान webhook है (जो आप ज्यादातर वहाँ पाएंगे)। यह मोड प्रमाणित उपयोगकर्ता के अनुमतियों की जांच करेगा ताकि किसी क्रिया की अनुमति या अस्वीकृति की जा सके।

वेबहुक के माध्यम से अधिकरण को param --authorization-mode=Webhook का उपयोग करके या कॉन्फ़िग फ़ाइल के माध्यम से कॉन्फ़िगर किया जा सकता है:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

kubelet SubjectAccessReview API को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि यह निर्धारित किया जा सके कि क्या प्रत्येक अनुरोध अधिकार प्राप्त है।

kubelet API अनुरोधों को उसी अनुरोध विशेषताओं के दृष्टिकोण का उपयोग करके अधिकृत करता है जैसे कि apiserver:

• क्रिया

• Kubelet API से बात करने वाला संसाधन हमेशा nodes होता है और उप-संसाधन आने वाले अनुरोध के पथ से निर्धारित होता है:

उदाहरण के लिए, निम्नलिखित अनुरोध ने अनुमति के बिना kubelet के pods जानकारी तक पहुँचने की कोशिश की:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

• हमें एक Forbidden मिला, इसलिए अनुरोध Authentication जांच को पास कर गया। यदि नहीं, तो हमें केवल एक Unauthorised संदेश मिलता।
• हम username देख सकते हैं (इस मामले में टोकन से)
• जांचें कि resource nodes था और subresource proxy (जो पिछले जानकारी के साथ समझ में आता है)

References

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/