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 का समर्थन करें

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/v1beta1 API group API server में सक्षम है
  • kubelet को --authentication-token-webhook और --kubeconfig flags के साथ शुरू करें या निम्नलिखित setting का उपयोग करें:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

kubelet कॉन्फ़िगर किए गए API सर्वर पर TokenReview API को कॉल करके 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 verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (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 APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over 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 था (जो पिछली जानकारी से मेल खाता है)

संदर्भ

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 का समर्थन करें