Kubelet Verifikasie & Magtiging
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
Kubelet Verifikasie
Standaard word versoeke aan die kubelet se HTTPS-endpunt wat nie deur ander ingestelde verifikasiemetodes verwerp word nie, as anonieme versoeke behandel, en gegee ’n gebruikersnaam van system:anonymous en ’n groep van system:unauthenticated.
Die 3 verifikasie metodes is:
- Anoniem (verstek): Stel die parameter
--anonymous-auth=trueof die konfigurasie:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: Dit sal die kubectl API bearer tokens as magtiging inskakel (enige geldige token sal geldig wees). Laat dit toe met:
- verseker dat die
authentication.k8s.io/v1beta1API-groep in die API-server geaktiveer is - begin die kubelet met die
--authentication-token-webhooken--kubeconfigvlae of gebruik die volgende instelling:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
Die kubelet roep die
TokenReviewAPI op die geconfigureerde API-server aan om gebruikerinligting te bepaal uit bearer tokens
- X509 client certificates: Laat toe om via X509 kliëntsertifikate te verifieer
- see the apiserver authentication documentation for more details
- start the kubelet with the
--client-ca-fileflag, providing a CA bundle to verify client certificates with. Or with the config:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Kubelet-magtiging
Enige versoek wat suksesvol geauthentiseer is (insluitend ’n anonieme versoek) word daarna gemagtig. Die verstek magtigingsmodus is AlwaysAllow, wat alle versoeke toelaat.
Die ander moontlike waarde is egter webhook (wat jy meestal daar sal vind). Hierdie modus sal die toestemmings van die geauthentiseerde gebruiker nagaan om ’n aksie toe te laat of te weier.
Warning
Neem kennis dat selfs al is die anonieme authentisering aangeskakel, het die anonieme toegang moontlik geen bevoegdhede om enige aksie uit te voer nie.
Die magtiging via webhook kan gekonfigureer word met die param --authorization-mode=Webhook of via die konfigurasielêer met:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
Die kubelet roep die SubjectAccessReview API op die gekonfigureerde API-server om te bepaal of elke versoek gemagtig is.
Die kubelet magtig API-versoeke deur dieselfde request attributes benadering as die apiserver te gebruik:
- Aksie
| 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) |
- Die resource wat met die Kubelet api praat is altyd nodes en die subresource word bepaal vanaf die inkomende versoek se pad:
| 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/portforwardval in die standaard proxy subresource en word gemagtig deur die aanvanklike HTTP GET handdruk. ’n Principal met slegsnodes/proxyGET kan steeds containers exec as dit direk methttps://<node_ip>:10250oor WebSockets verbind. Sien die nodes/proxy GET -> Kubelet /exec verb confusion abuse vir besonderhede.
Byvoorbeeld, die volgende versoek het probeer toegang verkry tot die pods-inligting van kubelet sonder toestemming:
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)
- Ons het ’n Forbidden gekry, dus het die request passed the Authentication check. As dit nie so was nie, sou ons net ’n
Unauthorisedboodskap gekry het. - Ons kan die username sien (in hierdie geval van die token)
- Kontroleer hoe die resource nodes was en die subresource proxy (wat sin maak met die vorige inligting)
References
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
HackTricks Cloud

