Kubelet Authentication & Authorization

Wesprzyj HackTricks

Uwierzytelnianie Kubelet

Z dokumentacji:

Domyślnie żądania do punktu końcowego HTTPS kubelet, które nie są odrzucane przez inne skonfigurowane metody uwierzytelniania, są traktowane jako żądania anonimowe i otrzymują nazwę użytkownika system:anonymous oraz grupę system:unauthenticated.

3 metody uwierzytelniania to:

  • Anonimowa (domyślna): Użyj ustawienia parametru --anonymous-auth=true lub konfiguracji:

"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: To włączy to autoryzację kubectl API bearer tokens (każdy ważny token będzie poprawny). Pozwól na to, wykonując:

  • 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ącej konfiguracji:

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

Kubelet wywołuje API TokenReview na skonfigurowanym serwerze API, aby określić informacje o użytkowniku z tokenów nosiciela.

  • Certyfikaty klienta X509: Pozwalają na uwierzytelnianie za pomocą certyfikatów klienta X509

  • zobacz dokumentację uwierzytelniania apiservera 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"
}
}

Autoryzacja Kubelet

Każde żądanie, które zostało pomyślnie uwierzytelnione (w tym anonimowe żądanie) jest następnie autoryzowane. Domyślnym trybem autoryzacji jest AlwaysAllow, który zezwala na wszystkie żądania.

Jednakże inna możliwa wartość to webhook (co najczęściej znajdziesz). Ten tryb będzie sprawdzał uprawnienia uwierzytelnionego użytkownika w celu zezwolenia lub zabronienia działania.

Zauważ, że nawet jeśli uwierzytelnienie 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:

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

Kubelet wywołuje API SubjectAccessReview na skonfigurowanym serwerze API, aby ustalić, czy każde żądanie jest autoryzowane.

Kubelet autoryzuje żądania API, korzystając z tego samego podejścia do atrybutów żądania co apiserver:

  • Akcja

Metoda HTTPczasownik żądania

POST

create

GET, HEAD

get (dla poszczególnych zasobów), list (dla kolekcji, w tym pełnej zawartości obiektu), watch (do obserwowania pojedynczego zasobu lub kolekcji zasobów)

PUT

update

PATCH

patch

DELETE

delete (dla poszczególnych zasobów), deletecollection (dla kolekcji)

  • Zasób komunikujący się z interfejsem API Kubelet zawsze to nodes, a podzasób jest ustalany na podstawie ścieżki przychodzącego żądania:

API Kubeletzasóbpodzasób

/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 Zakazane, więc żądanie zdało sprawdzanie uwierzytelniania. Gdyby nie, otrzymalibyśmy tylko komunikat Nieautoryzowane.

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

  • Sprawdź, jakim był zasobem węzły i podzasobem proxy (co zgadza się z poprzednimi informacjami)

Referencje

Wesprzyj HackTricks

Last updated