Kubelet Verifikasie & Magtiging
Tip
Leer en oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer en oefen Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subskripsie planne!
- Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.
Kubelet Verifikasie
Standaard word versoeke na die kubelet se HTTPS-eindpunt wat nie deur ander geconfigureerde verifikasie metodes verwerp word nie, as anonieme versoeke behandel, en ontvang ’n gebruikersnaam van system:anonymous en ’n groep van system:unauthenticated.
Die 3 verifikasie metodes is:
- Anoniem (standaard): Gebruik die instelling deur die parameter
--anonymous-auth=trueof die konfigurasie:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: Dit sal die kubectl API bearer tokens as outorisering aktiveer (enige geldige token sal geldig wees). Laat dit toe met:
- verseker dat die
authentication.k8s.io/v1beta1API-groep geaktiveer is in die API-bediener - 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-bediener om gebruikersinligting uit draer tokens te bepaal.
- X509 kliënt sertifikate: Laat toe om te autentiseer via X509 kliënt sertifikate
- sien die apiserver authentication documentation vir meer besonderhede
- begin die kubelet met die
--client-ca-filevlag, wat ’n CA-bundel verskaf om kliënt sertifikate mee te verifieer. Of met die konfigurasie:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
Kubelet Authorization
Enige versoek wat suksesvol geverifieer is (insluitend ’n anonieme versoek) word dan geoutoriseer. Die verstek outorisasi-modus is AlwaysAllow, wat alle versoeke toelaat.
Die ander moontlike waarde is webhook (wat jy meestal daar buite sal vind). Hierdie modus sal die regte van die geverifieerde gebruiker nagaan om ’n aksie toe te laat of te weier.
Warning
Let daarop dat selfs al is die anonieme outentisering geaktiveer die anonieme toegang dalk nie enige regte het om enige aksie uit te voer.
Die outorisering via webhook kan gekonfigureer word met die param --authorization-mode=Webhook of via die konfigurasie-lêer met:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
Die kubelet roep die SubjectAccessReview API op die geconfigureerde API-bediener om te bepaal of elke versoek geoutoriseer is.
Die kubelet autoriseer API versoeke met dieselfde versoek eienskappe benadering as die apiserver:
- Aksie
| HTTP werkwoord | versoek werkwoord |
|---|---|
| POST | skep |
| GET, HEAD | kry (vir individuele hulpbronne), lys (vir versamelings, insluitend volle objekinhoud), kyk (vir die monitering van ’n individuele hulpbron of versameling van hulpbronne) |
| PUT | opdateer |
| PATCH | patch |
| DELETE | verwyder (vir individuele hulpbronne), verwyderversameling (vir versamelings) |
- Die hulpbron wat met die Kubelet API praat, is altyd nodes en subresource word bepaal uit die inkomende versoek se pad:
| Kubelet API | hulpbron | subresource |
|---|---|---|
| /stats/* | nodes | stats |
| /metrics/* | nodes | metrics |
| /logs/* | nodes | log |
| /spec/* | nodes | spec |
| alle ander | nodes | proxy |
Byvoorbeeld, die volgende versoek het probeer om toegang te 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 Verbode gekry, so die versoek het die Authentikasie kontrole geslaag. As nie, sou ons net ’n
Onbevoegboodskap gekry het. - Ons kan die gebruikersnaam sien (in hierdie geval van die token)
- Kyk hoe die hulpbron nodes was en die subhulpbron proxy (wat sin maak met die vorige inligting)
Verwysings
Tip
Leer en oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer en oefen Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subskripsie planne!
- Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.
HackTricks Cloud

