Kubelet Authentication & Authorization
Tip
Jifunze na ufanye mazoezi ya AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Saidia HackTricks
- Angalia the subscription plans!
- Jiunge na 💬 Discord group au the telegram group au utufuate kwenye Twitter 🐦 @hacktricks_live.
- Shiriki hacking tricks kwa kutuma PRs kwa HackTricks and HackTricks Cloud github repos.
Kubelet Authentication
Kwa chaguo-msingi, maombi kwa endpoint ya kubelet ya HTTPS ambayo hayakatwi na mbinu nyingine zilizoamuliwa za authentication hutendewa kama maombi anonymous, na yanapewa username ya system:anonymous na group ya system:unauthenticated.
Njia 3 za authentication ni:
- Anonymous (default): Weka param
--anonymous-auth=trueau tumia config:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: Hii ita wezesha kubectl API bearer tokens kama njia ya uthibitisho (token yoyote halali itatumika). Ili kuruhusu:
- hakikisha
authentication.k8s.io/v1beta1API group imewezeshwa kwenye API server - anzisha kubelet kwa
--authentication-token-webhookna--kubeconfigflags au tumia mpangilio ufuatao:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
Kubelet huita
TokenReviewAPI kwenye API server iliyosanidiwa ili kubaini taarifa za mtumiaji kutoka kwa bearer tokens
- X509 client certificates: Zinaruhusu uthibitishaji kupitia X509 client certificates
- angalia apiserver authentication documentation kwa maelezo zaidi
- anza kubelet kwa kutumia flag ya
--client-ca-file, ukiweka CA bundle ili kuthibitisha client certificates. Au kwa config:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Uidhinishaji wa Kubelet
Kila ombi ambalo limethibitishwa kwa mafanikio (ikijumuisha ombi la mtumiaji isiyotambulika) halafu linaidhinishwa. Hali ya chaguo-msingi ya uidhinishaji ni AlwaysAllow, ambayo inaruhusu maombi yote.
Hata hivyo, thamani nyingine inayowezekana ni webhook (ambayo ndiyo utakayopata kwa kawaida). Hali hii itakagua ruhusa za mtumiaji aliyethibitishwa ili kuruhusu au kukataa kitendo.
Warning
Kumbuka kwamba hata kama uthibitishaji wa watumiaji wasiotambulika umewezeshwa, ufikiaji wa watumiaji wasiotambulika unaweza kubaki bila ruhusa zozote za kufanya kitendo chochote.
Uidhinishaji kupitia webhook unaweza kusanidiwa kwa kutumia param --authorization-mode=Webhook au kupitia faili ya usanidi kwa:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
The kubelet inaita API ya SubjectAccessReview kwenye API server iliyosanidiwa ili kuamua kama kila ombi limeidhinishwa.
Kubelet inaidhinisha maombi ya API kwa kutumia mbinu ile ile ya request attributes kama apiserver:
- Kitendo
| 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 inayozungumza na Kubelet api ni daima nodes na subresource huamuliwa kutoka kwenye path ya ombi linalokuja:
| 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. Msimamizi (principal) mwenye tunodes/proxyGET bado anaweza kufanya exec kwenye containers ikiwa anatoka moja kwa moja kwa kuunganishwa nahttps://<node_ip>:10250kwa kupitia WebSockets. Tazama the nodes/proxy GET -> Kubelet /exec verb confusion abuse kwa maelezo.
Kwa mfano, ombi lifuatalo lilijaribu kupata taarifa za pods za kubelet bila ruhusa:
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)
- Tulipokea Forbidden, hivyo ombi lilipita Authentication check. Kama sivyo, tungepata ujumbe tu wa
Unauthorised. - Tunaweza kuona username (kwa kesi hii kutoka kwa token)
- Angalia jinsi resource ilikuwa nodes na subresource proxy (ambayo inaeleweka kutokana na taarifa zilizotangulia)
Marejeo
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
Jifunze na ufanye mazoezi ya AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Saidia HackTricks
- Angalia the subscription plans!
- Jiunge na 💬 Discord group au the telegram group au utufuate kwenye Twitter 🐦 @hacktricks_live.
- Shiriki hacking tricks kwa kutuma PRs kwa HackTricks and HackTricks Cloud github repos.
HackTricks Cloud

