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

Uwierzytelnianie Kubeleta

From the docss:

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=true lub 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/v1beta1 jest włączona na serwerze API
  • uruchom kubelet z flagami --authentication-token-webhook i --kubeconfig lub użyj następującego ustawienia:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

Kubelet wywołuje TokenReview API 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-file flag, 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 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)
  • Zasób komunikujący się z Kubelet api to zawsze nodes, a subresource jest określany na podstawie ścieżki przychodzącego żądania:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over 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

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