Kubelet Authentication & Authorization

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Kubelet Autentikacija

Iz dokumenata:

Podrazumevano, zahtevi ka HTTPS endpointu kubeleta koji nisu odbijeni drugim konfigurisanim metodama autentikacije tretiraju se kao anonimni zahtevi i dodeljuju se korisničko ime system:anonymous i grupa system:unauthenticated.

Postoje 3 autentikaciona metoda:

  • Anonimna (podrazumevana): Koristi postavljanje parametra --anonymous-auth=true ili konfiguraciju:

"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Ovo će omogućiti kubectl API bearer tokens kao autorizaciju (svaki validan token će biti validan). Dozvolite ga sa:

  • osigurajte da je authentication.k8s.io/v1beta1 API grupa omogućena u API serveru

  • pokrenite kubelet sa --authentication-token-webhook i --kubeconfig zastavicama ili koristite sledeće podešavanje:

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

Kubelet poziva TokenReview API na konfigurisanom API serveru da odredi informacije o korisniku iz bearer tokena

  • X509 klijentski sertifikati: Omogućavaju autentifikaciju putem X509 klijentskih sertifikata

  • pokrenite kubelet sa --client-ca-file zastavicom, pružajući CA bundle za proveru klijentskih sertifikata. Ili sa konfiguracijom:

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

Autorizacija Kubeleta

Bilo koji zahtev koji je uspešno autentifikovan (uključujući anoniman zahtev) je zatim autorizovan. Podrazumevani režim autorizacije je AlwaysAllow, koji dozvoljava sve zahteve.

Međutim, druga moguća vrednost je webhook (što ćete najčešće pronaći). Ovaj režim će proveriti dozvole autentifikovanog korisnika da dozvoli ili zabrani akciju.

Imajte na umu da čak i ako je omogućena anonimna autentikacija, anoniman pristup možda nema dozvole da izvrši bilo koju akciju.

Autorizacija putem webhook-a može biti konfigurisana korišćenjem parametra --authorization-mode=Webhook ili putem konfiguracione datoteke sa:

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

Kubelet poziva API SubjectAccessReview na konfigurisanom API serveru da odredi da li je svaki zahtev autorizovan.

Kubelet autorizuje API zahteve koristeći isti pristup atributima zahteva kao i apiserver:

  • Akcija

HTTP glagolglagol zahteva

POST

create

GET, HEAD

get (za pojedinačne resurse), list (za kolekcije, uključujući pun sadržaj objekta), watch (za praćenje pojedinačnog resursa ili kolekcije resursa)

PUT

update

PATCH

patch

DELETE

delete (za pojedinačne resurse), deletecollection (za kolekcije)

  • Resurs koji komunicira sa Kubelet API-jem je uvek nodes i podresurs se određuje iz putanje dolaznog zahteva:

Kubelet APIresurspodresurs

/stats/*

nodes

stats

/metrics/*

nodes

metrics

/logs/*

nodes

log

/spec/*

nodes

spec

svi ostali

nodes

proxy

Na primer, sledeći zahtev pokušao je da pristupi informacijama o podovima kubeleta bez dozvole:

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)
  • Dobili smo Zabranjeno, tako da je zahtev prošao proveru autentikacije. Da nije prošao, dobili bismo samo poruku Neovlašćeno.

  • Možemo videti korisničko ime (u ovom slučaju iz tokena)

  • Proverite kako je resurs bio čvorovi i podresurs proxy (što ima smisla sa prethodnim informacijama)

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Last updated