Kubelet प्रमाणीकरण और प्राधिकरण
Tip
सीखें और अभ्यास करें AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- देखें subscription plans!
- शामिल हों 💬 Discord group या telegram group या हमें फ़ॉलो करें Twitter 🐦 @hacktricks_live.
- PRs सबमिट करके hacking tricks साझा करें HackTricks और HackTricks Cloud github repos.
Kubelet प्रमाणीकरण
डिफ़ॉल्ट रूप से, kubelet के HTTPS endpoint पर आने वाले वे अनुरोध जो अन्य कॉन्फ़िगर किए गए प्रमाणीकरण विधियों द्वारा अस्वीकार नहीं किए जाते, उन्हें anonymous अनुरोध माना जाता है, और उन्हें दिया जाता है username of system:anonymous और group of system:unauthenticated।
प्रमाणीकरण के 3 तरीके हैं:
- Anonymous (डिफ़ॉल्ट): पैरामीटर सेट करने के लिए उपयोग करें
--anonymous-auth=trueया config:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: यह kubectl API bearer tokens को authorization के रूप में सक्षम करेगा (कोई भी वैध token मान्य होगा)। इसे अनुमति दें:
- सुनिश्चित करें कि
authentication.k8s.io/v1beta1API group API server में सक्षम है - kubelet को
--authentication-token-webhookऔर--kubeconfigflags के साथ शुरू करें या निम्नलिखित setting का उपयोग करें:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
kubelet कॉन्फ़िगर किए गए API सर्वर पर
TokenReviewAPI को कॉल करके bearer tokens से उपयोगकर्ता जानकारी निर्धारित करता है
- X509 client certificates: X509 client certs के माध्यम से प्रमाणीकृत करने की अनुमति देते हैं
- अधिक जानकारी के लिए apiserver authentication documentation देखें
- kubelet को
--client-ca-fileफ्लैग के साथ शुरू करें, client certificates को सत्यापित करने के लिए एक CA bundle प्रदान करते हुए। या config के साथ:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Kubelet Authorization
किसी भी अनुरोध जो सफलतापूर्वक प्रमाणीकृत हो (जिसमें अनाम अनुरोध भी शामिल है) फिर अनुमोदित किया जाता है। डिफ़ॉल्ट authorization मोड AlwaysAllow है, जो सभी अनुरोधों की अनुमति देता है।
हालाँकि, दूसरा संभावित मान webhook है (जो आप वहां अधिकतर पाएँगे)। यह मोड किसी क्रिया को अनुमति देने या अस्वीकार करने के लिए प्रमाणीकृत उपयोगकर्ता की अनुमतियों की जाँच करेगा।
Warning
ध्यान दें कि भले ही अनाम प्रमाणीकरण सक्षम हो, अनाम पहुँच के पास किसी भी क्रिया को करने की अनुमतियाँ नहीं हो सकतीं।
Webhook के माध्यम से authorization को कॉन्फ़िगर किया जा सकता है param --authorization-mode=Webhook का उपयोग करके या config फ़ाइल के माध्यम से:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
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 always nodes and subresource is determined 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 |
Note
WebSocket-based
/exec,/run,/attach, and/portforwardfall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with onlynodes/proxyGET can still exec containers if it connects directly tohttps://<node_ip>:10250over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.
For example, the following request tried to access the pods info of kubelet without permission:
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 check पास कर गया। अगर ऐसा नहीं होता, तो हमें सिर्फ
Unauthorisedसंदेश मिलता। - हम username देख सकते हैं (इस मामले में token से)
- देखें कि resource कैसे nodes था और subresource proxy था (जो पिछली जानकारी से मेल खाता है)
संदर्भ
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
सीखें और अभ्यास करें AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
HackTricks का समर्थन करें
- देखें subscription plans!
- शामिल हों 💬 Discord group या telegram group या हमें फ़ॉलो करें Twitter 🐦 @hacktricks_live.
- PRs सबमिट करके hacking tricks साझा करें HackTricks और HackTricks Cloud github repos.
HackTricks Cloud

