Kubelet Uwierzytelnianie i autoryzacja
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
Uwierzytelnianie Kubeleta
Domyślnie żądania do punktu końcowego HTTPS kubeleta, które nie zostaną odrzucone przez inne skonfigurowane metody uwierzytelniania, są traktowane jako żądania anonimowe i otrzymują nazwę użytkownika system:anonymous oraz grupę system:unauthenticated.
The 3 authentication methods are:
- Anonymous (domyślnie): Ustaw parametr
--anonymous-auth=truelub konfigurację:
"authentication": {
"anonymous": {
"enabled": true
},
- Webhook: To spowoduje włączenie kubectl API bearer tokens jako mechanizmu autoryzacji (każdy ważny token będzie akceptowany). Zezwól na to, wykonując:
- upewnij się, że grupa API
authentication.k8s.io/v1beta1jest włączona na serwerze API - uruchom kubelet z flagami
--authentication-token-webhooki--kubeconfiglub użyj następującego ustawienia:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
Note
Kubelet wywołuje
TokenReviewAPI na skonfigurowanym serwerze API, aby określić informacje o użytkowniku z bearer tokens
- X509 client certificates: Pozwalają na uwierzytelnianie za pomocą certyfikatów klienta X509
- 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"
}
}
Autoryzacja Kubeleta
Każde żądanie, które zostanie pomyślnie uwierzytelnione (w tym żądanie anonimowe) jest następnie autoryzowane. domyślny tryb autoryzacji to AlwaysAllow, który zezwala na wszystkie żądania.
However, the other possible value is webhook (który jest tym, co przeważnie spotkasz). Ten tryb sprawdza uprawnienia uwierzytelnionego użytkownika, aby zezwolić lub odmówić wykonania akcji.
Warning
Należy pamiętać, że nawet jeśli uwierzytelnianie anonimowe jest włączone to dostęp anonimowy może nie mieć żadnych uprawnień do wykonania żadnej akcji.
Autoryzację przez webhook można skonfigurować używając parametru --authorization-mode=Webhook lub przez plik konfiguracyjny za pomocą:
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
The kubelet calls the SubjectAccessReview API on the configured API server to determine whether each request is authorized.
The kubelet authorizes API requests using the same request attributes approach as the apiserver:
- Akcja
| 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) |
- Zasób komunikujący się z Kubelet api to zawsze nodes, a subresource jest określany na podstawie ścieżki przychodzącego żądania:
| 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. A principal with onlynodes/proxyGET can still exec containers if it connects directly tohttps://<node_ip>:10250over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.
For example, the following request tried to access the pods info of kubelet without permission:
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)
- Otrzymaliśmy Forbidden, więc żądanie przeszło sprawdzenie uwierzytelniania. Gdyby nie, otrzymalibyśmy tylko komunikat
Unauthorised. - Widać username (w tym przypadku z tokena)
- Zwróć uwagę, że resource to nodes, a subresource to proxy (co ma sens w świetle powyższych informacji)
Referencje
- https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/
- nodes/proxy GET -> kubelet exec via WebSocket bypass
Tip
Ucz się & ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Wspieraj HackTricks
- Sprawdź subscription plans!
- Dołącz do 💬 Discord group lub telegram group lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Podziel się hacking tricks, zgłaszając PRy do HackTricks i HackTricks Cloud github repos.
HackTricks Cloud

