Kubelet Authentication & Authorization

Support HackTricks

Kubelet Authentication

Z dokumentacji:

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, ustawiając parametr --anonymous-auth=true lub konfigurację:

"authentication": {
"anonymous": {
"enabled": true
},
  • 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:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

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ą:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

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, anonimowy dostęp 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:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

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 HTTPczasownik żą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 nodes, a subresource jest określany na podstawie ścieżki przychodzącego żądania:

API Kubeletzasóbsubresource

/stats/*

nodes

stats

/metrics/*

nodes

metrics

/logs/*

nodes

log

/spec/*

nodes

spec

wszystkie inne

nodes

proxy

Na przykład, poniższe żądanie próbowało uzyskać dostęp do informacji o podach kubelet bez uprawnień:

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 kontrolę autoryzacji. Gdyby nie, otrzymalibyśmy tylko komunikat Unauthorised.

  • Możemy zobaczyć nazwa użytkownika (w tym przypadku z tokena)

  • Sprawdź, jak zasób to nodes, a subzasób to proxy (co ma sens w kontekście wcześniejszych informacji)

References

Support HackTricks

Last updated