hacktricks-cloud/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/kubelet-authentication-and-authorization.md

Kubelet Authentication & Authorization

{{#include ../../../banners/hacktricks-training.md}}

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
},

Note

kubelet TokenReview API को कॉन्फ़िगर किए गए API सर्वर पर कॉल करता है ताकि उपयोगकर्ता जानकारी को bearer tokens से निर्धारित किया जा सके।

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

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

Kubelet Authorization

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

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

Warning

ध्यान दें कि भले ही गुमनाम प्रमाणीकरण सक्षम है, गुमनाम पहुंच को किसी भी क्रिया को करने के लिए कोई अनुमतियाँ नहीं हो सकती हैं।

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

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

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

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

• क्रिया

HTTP क्रिया	अनुरोध क्रिया
POST	बनाना
GET, HEAD	प्राप्त करना (व्यक्तिगत संसाधनों के लिए), सूची (संग्रहों के लिए, पूर्ण वस्तु सामग्री सहित), देखना (व्यक्तिगत संसाधन या संसाधनों के संग्रह को देखने के लिए)
PUT	अपडेट
PATCH	पैच
DELETE	हटाना (व्यक्तिगत संसाधनों के लिए), हटाने का संग्रह (संग्रहों के लिए)

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

Kubelet API	संसाधन	उप-संसाधन
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
सभी अन्य	nodes	proxy

उदाहरण के लिए, निम्नलिखित अनुरोध ने अनुमति के बिना 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/

{{#include ../../../banners/hacktricks-training.md}}