Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Domyślnie, żądania do punktu końcowego HTTPS kubeleta, które nie są odrzucane przez inne skonfigurowane metody uwierzytelniania, są traktowane jako żądania anonimowe i otrzymują nazwa użytkownika system:anonymous oraz grupa system:unauthenticated.
3 metody uwierzytelniania to:
Anonimowe (domyślnie): Użyj ustawienia parametru --anonymous-auth=true lub konfiguracji:
Webhook: To włączyć tokeny API bearer kubectl jako autoryzację (każdy ważny token będzie ważny). Włącz to za pomocą:
upewnij się, że grupa API authentication.k8s.io/v1beta1 jest włączona w serwerze API
uruchom kubelet z flagami --authentication-token-webhook i --kubeconfig lub użyj następującego ustawienia:
Kubelet wywołuje TokenReview API na skonfigurowanym serwerze API, aby określić informacje o użytkowniku z tokenów nośnych
Certyfikaty klienta X509: Umożliwiają uwierzytelnianie za pomocą certyfikatów klienta X509
zobacz dokumentację uwierzytelniania apiserver po więcej szczegółów
uruchom kubelet z flagą --client-ca-file, podając pakiet CA do weryfikacji certyfikatów klienta. Lub z konfiguracją:
Każde żądanie, które zostało pomyślnie uwierzytelnione (w tym anonimowe żądanie) jest następnie autoryzowane. Domyślny tryb autoryzacji to AlwaysAllow, który zezwala na wszystkie żądania.
Jednak inną możliwą wartością jest webhook (co jest tym, co najczęściej znajdziesz na zewnątrz). Ten tryb sprawdzi uprawnienia uwierzytelnionego użytkownika, aby zezwolić lub zabronić wykonania akcji.
Zauważ, że nawet jeśli uwierzytelnianie anonimowe jest włączone, dostęp anonimowy może nie mieć żadnych uprawnień do wykonania jakiejkolwiek akcji.
Autoryzacja za pomocą webhooka może być skonfigurowana za pomocą parametru --authorization-mode=Webhook lub za pomocą pliku konfiguracyjnego z:
Kubelet wywołuje API SubjectAccessReview na skonfigurowanym serwerze API, aby określić, czy każde żądanie jest autoryzowane.
Kubelet autoryzuje żądania API, używając tego samego podejścia atrybutów żądania co apiserver:
Akcja
| Czasownik HTTP | czasownik żądania |
|---|---|
POST | create |
GET, HEAD | get (dla pojedynczych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (dla obserwowania pojedynczego zasobu lub kolekcji zasobów) |
PUT | update |
PATCH | patch |
DELETE | delete (dla pojedynczych zasobów), deletecollection (dla kolekcji) |
Zasób komunikujący się z API Kubelet to zawsze węzły, a podzasób jest określany na podstawie ścieżki przychodzącego żądania:
| API Kubelet | zasób | podzasób |
|---|---|---|
/stats/* | węzły | stats |
/metrics/* | węzły | metrics |
/logs/* | węzły | log |
/spec/* | węzły | spec |
wszystkie inne | węzły | proxy |
Na przykład, poniższe żądanie próbowało uzyskać dostęp do informacji o podach kubelet bez uprawnień:
Otrzymaliśmy Forbidden, więc żądanie przeszło kontrolę uwierzytelniania. Gdyby nie, otrzymalibyśmy tylko komunikat Unauthorised.
Możemy zobaczyć nazwa użytkownika (w tym przypadku z tokena)
Sprawdź, jak zasób był nodes, a subresource proxy (co ma sens w kontekście wcześniejszych informacji)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
