Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kwa default, maombi kwa mwisho wa HTTPS wa kubelet ambayo hayakukataliwa na njia nyingine za uthibitishaji zilizowekwa yanachukuliwa kama maombi yasiyo na jina, na yanapewa jina la mtumiaji system:anonymous na kikundi system:unauthenticated.
Njia 3 za uthibitishaji ni:
Anonymous (default): Tumia kuweka param --anonymous-auth=true au usanidi:
Webhook: Hii itawa wezesha kubectl API bearer tokens kama idhini (token yoyote halali itakuwa halali). Ruhusu kwa:
hakikisha kundi la API authentication.k8s.io/v1beta1 limewezeshwa katika seva ya API
anzisha kubelet na bendera za --authentication-token-webhook na --kubeconfig au tumia mipangilio ifuatayo:
Kubelet inaita TokenReview API kwenye seva ya API iliyowekwa ili kubaini taarifa za mtumiaji kutoka kwa alama za kubeba
X509 vyeti vya mteja: Ruhusu kuthibitisha kupitia vyeti vya mteja vya X509
angalia nyaraka za uthibitishaji wa apiserver kwa maelezo zaidi
anzisha kubelet na bendera ya --client-ca-file, ukitoa pakiti ya CA ili kuthibitisha vyeti vya wateja. Au kwa usanidi:
Maombi yoyote ambayo yamefanikiwa kuthibitishwa (ikiwemo maombi ya kutotambulika) yanaruhusiwa. Njia ya kuthibitisha ya AlwaysAllow ni ya kawaida, ambayo inaruhusu maombi yote.
Hata hivyo, thamani nyingine inayowezekana ni webhook (ambayo ndiyo utakayokutana nayo zaidi huko nje). Njia hii it akagua ruhusa za mtumiaji aliyethibitishwa ili kuruhusu au kukataa kitendo.
Kumbuka kwamba hata kama uthibitisho wa kutotambulika umewezeshwa, upatikanaji wa kutotambulika huenda usiwe na ruhusa yoyote ya kufanya kitendo chochote.
Kuthibitisha kupitia webhook kunaweza kuwekewa mipangilio kwa kutumia param --authorization-mode=Webhook au kupitia faili ya usanidi na:
The kubelet calls the SubjectAccessReview API on the configured API server to kubaini whether each request is imeidhinishwa.
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 daima nodes and subresource is kubainishwa 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:
Tulipata Forbidden, hivyo ombi lilipita kwenye ukaguzi wa Uthibitishaji. La sivyo, tungekuwa na ujumbe wa Unauthorised tu.
Tunaweza kuona jina la mtumiaji (katika kesi hii kutoka kwenye tokeni)
Angalia jinsi rasilimali ilikuwa nodes na subresource proxy (ambayo ina maana na taarifa za awali)
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
