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

Kubelet Verifikasie

Vanaf die dokumentasie:

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=true of 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/v1beta1 API-groep in die API-server geaktiveer is
  • begin die kubelet met die --authentication-token-webhook en --kubeconfig vlae of gebruik die volgende instelling:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

Die kubelet roep die TokenReview API 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-file flag, 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 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)
  • Die resource wat met die Kubelet api praat is altyd nodes en die subresource word bepaal vanaf die inkomende versoek se pad:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward val in die standaard proxy subresource en word gemagtig deur die aanvanklike HTTP GET handdruk. ’n Principal met slegs nodes/proxy GET kan steeds containers exec as dit direk met https://<node_ip>:10250 oor 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 Unauthorised boodskap 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

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