Kubelet Authentication & Authorization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
डिफ़ॉल्ट रूप से, 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 सर्वर पर कॉल करता है ताकि उपयोगकर्ता जानकारी को bearer tokens से निर्धारित किया जा सके
X509 क्लाइंट सर्टिफिकेट: X509 क्लाइंट सर्टिफिकेट के माध्यम से प्रमाणीकरण की अनुमति देता है
अधिक विवरण के लिए apiserver प्रमाणीकरण दस्तावेज़ देखें
--client-ca-file ध्वज के साथ kubelet शुरू करें, क्लाइंट सर्टिफिकेट को सत्यापित करने के लिए CA बंडल प्रदान करते हुए। या कॉन्फ़िग के साथ:
कोई भी अनुरोध जो सफलतापूर्वक प्रमाणित होता है (जिसमें एक गुमनाम अनुरोध भी शामिल है) फिर अधिकृत किया जाता है। डिफ़ॉल्ट अधिकरण मोड AlwaysAllow है, जो सभी अनुरोधों की अनुमति देता है।
हालांकि, अन्य संभावित मान webhook है (जो आप ज्यादातर वहाँ पाएंगे)। यह मोड प्रमाणित उपयोगकर्ता के अनुमतियों की जांच करेगा ताकि किसी क्रिया की अनुमति या अस्वीकृति की जा सके।
ध्यान दें कि भले ही गुमनाम प्रमाणीकरण सक्षम हो, गुमनाम पहुंच को किसी भी क्रिया को करने के लिए कोई अनुमतियाँ नहीं हो सकती।
वेबहुक के माध्यम से अधिकरण को पैरामीटर --authorization-mode=Webhook का उपयोग करके या कॉन्फ़िग फ़ाइल के माध्यम से कॉन्फ़िगर किया जा सकता है:
The kubelet calls the SubjectAccessReview API on the configured API server to निर्धारित whether each request is अधिकार प्राप्त.
The kubelet authorizes API requests using the same request attributes approach as the apiserver:
Action
| HTTP verb | request verb |
|---|---|
POST | create |
GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
PUT | update |
PATCH | patch |
DELETE | delete (for individual resources), deletecollection (for collections) |
The resource talking to the Kubelet api is हमेशा nodes and subresource is निर्धारित from the incoming request's path:
| Kubelet API | resource | subresource |
|---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
all others | nodes | proxy |
For example, the following request tried to access the pods info of kubelet without permission:
हमें Forbidden मिला, इसलिए अनुरोध Authentication check को पास कर गया। यदि नहीं, तो हमें केवल एक Unauthorised संदेश मिलता।
हम username देख सकते हैं (इस मामले में टोकन से)
जांचें कि resource nodes था और subresource proxy (जो पिछले जानकारी के साथ समझ में आता है)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
