Kubelet Authentication & Authorization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Standaard word versoeke na die kubelet se HTTPS-eindpunt wat nie deur ander geconfigureerde autentikasie metodes verwerp word nie, as anonieme versoeke behandel, en 'n gebruikersnaam van system:anonymous en 'n groep van system:unauthenticated gegee.
Die 3 autentikasie metodes is:
Anoniem (standaard): Gebruik die instelling deur die parameter --anonymous-auth=true of die konfigurasie:
Webhook: Dit sal aktiveer dat die kubectl API draer tokens as outorisering (enige geldige token sal geldig wees). Laat dit toe met:
verseker dat die authentication.k8s.io/v1beta1 API-groep geaktiveer is in die API-bediener
begin die kubelet met die --authentication-token-webhook en --kubeconfig vlae of gebruik die volgende instelling:
Die kubelet roep die TokenReview API op die geconfigureerde API-bediener om gebruikersinligting uit draer tokens te bepaal
X509 kliënt sertifikate: Laat toe om te autentiseer via X509 kliënt sertifikate
sien die apiserver autentisering dokumentasie vir meer besonderhede
begin die kubelet met die --client-ca-file vlag, wat 'n CA-bundel verskaf om kliënt sertifikate mee te verifieer. Of met die konfigurasie:
Enige versoek wat suksesvol geverifieer is (insluitend 'n anonieme versoek) word dan geoutoriseer. Die verstek outeurstellingsmodus is AlwaysAllow, wat alle versoeke toelaat.
Die ander moontlike waarde is webhook (wat jy meestal daar buite sal vind). Hierdie modus sal die regte van die geverifieerde gebruiker nagaan om 'n aksie toe te laat of te weier.
Let daarop dat selfs al is die anonieme outeurstelling geaktiveer, die anonieme toegang dalk nie enige regte het om enige aksie uit te voer nie.
Die outeurstelling via webhook kan gekonfigureer word met die param --authorization-mode=Webhook of via die konfigurasie-lêer met:
Die kubelet roep die SubjectAccessReview API op die geconfigureerde API-bediener om te bepaal of elke versoek geoutoriseer is.
Die kubelet autoriseer API versoeke met behulp van dieselfde versoek eienskappe benadering as die apiserver:
Aksie
POST
skep
GET, HEAD
kry (vir individuele hulpbronne), lys (vir versamelings, insluitend volle objekinhoud), kyk (vir die monitering van 'n individuele hulpbron of versameling hulpbronne)
PUT
opdateer
PATCH
patch
DELETE
verwyder (vir individuele hulpbronne), verwyderversameling (vir versamelings)
Die hulpbron wat met die Kubelet API praat, is altyd nodes en subhulpbron word bepaal uit die inkomende versoek se pad:
/stats/*
nodes
stats
/metrics/*
nodes
metrics
/logs/*
nodes
log
/spec/*
nodes
spec
alle ander
nodes
proxy
Byvoorbeeld, die volgende versoek het probeer om toegang te verkry tot die pods inligting van kubelet sonder toestemming:
Ons het 'n Verbode gekry, so die versoek het die Verifikasie-toets geslaag. As nie, sou ons net 'n Nie gemagtig boodskap gekry het.
Ons kan die gebruikersnaam sien (in hierdie geval van die token)
Kyk hoe die hulpbron nodes was en die subhulpbron proxy (wat sin maak met die vorige inligting)
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
