Kubelet Authentication & Authorization

Impara l'hacking su AWS da zero a esperto con htARTE (Esperto Red Team di HackTricks su AWS)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale di PEASS & HackTricks

• Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguimi su Twitter 🐦 @carlospolopm.

• Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Autenticazione di Kubelet

Dalla documentazione:

Per impostazione predefinita, le richieste all'endpoint HTTPS di kubelet che non vengono respinte da altri metodi di autenticazione configurati sono trattate come richieste anonime e vengono assegnati un username di system:anonymous e un gruppo di system:unauthenticated.

I 3 metodi di autenticazione sono:

• Anonimo (predefinito): Usare l'impostazione impostando il parametro --anonymous-auth=true o la configurazione:

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook: Questo abiliterà i token bearer API kubectl come autorizzazione (qualsiasi token valido sarà accettato). Consentilo con:

• assicurati che il gruppo API authentication.k8s.io/v1beta1 sia abilitato nel server API

• avvia il kubelet con i flag --authentication-token-webhook e --kubeconfig o utilizza l'impostazione seguente:

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

Il kubelet chiama l'API TokenReview sul server API configurato per determinare le informazioni dell'utente dai token bearer

• Certificati client X509: Consentono di autenticarsi tramite certificati client X509

• consultare la documentazione sull'autenticazione dell'apiserver per ulteriori dettagli

• avviare il kubelet con il flag --client-ca-file, fornendo un bundle CA per verificare i certificati client. Oppure con la configurazione:

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

Autorizzazione di Kubelet

Qualsiasi richiesta che viene autenticata con successo (inclusa una richiesta anonima) viene quindi autorizzata. La modalità di autorizzazione predefinita è AlwaysAllow, che permette tutte le richieste.

Tuttavia, l'altro valore possibile è webhook (che è quello che troverai principalmente là fuori). Questa modalità verificherà i permessi dell'utente autenticato per consentire o negare un'azione.

Nota che anche se l'autenticazione anonima è abilitata, l'accesso anonimo potrebbe non avere nessun permesso per eseguire alcuna azione.

L'autorizzazione tramite webhook può essere configurata utilizzando il parametro --authorization-mode=Webhook o tramite il file di configurazione con:

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

Il kubelet chiama l'API SubjectAccessReview sul server API configurato per determinare se ogni richiesta è autorizzata.

Il kubelet autorizza le richieste API utilizzando lo stesso approccio degli attributi della richiesta come l'apiserver:

• Azione

Verbo HTTP	verbo della richiesta
POST	create
GET, HEAD	get (per risorse individuali), list (per raccolte, inclusi i contenuti completi degli oggetti), watch (per osservare una risorsa individuale o una raccolta di risorse)
PUT	update
PATCH	patch
DELETE	delete (per risorse individuali), deletecollection (per raccolte)

• La risorsa che comunica con l'API Kubelet è sempre nodes e il sotto-risorsa è determinato dal percorso della richiesta in arrivo:

API Kubelet	risorsa	sotto-risorsa
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
tutti gli altri	nodes	proxy

Ad esempio, la seguente richiesta ha cercato di accedere alle informazioni sui pod del kubelet senza autorizzazione:

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)

• Abbiamo ricevuto un Vietato, quindi la richiesta ha superato il controllo di autenticazione. In caso contrario, avremmo ricevuto solo un messaggio Non autorizzato.

• Possiamo vedere lo username (in questo caso dal token)

• Controlla come la risorsa era nodi e la sotto-risorsa proxy (che ha senso con le informazioni precedenti)

Riferimenti

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/

Impara l'hacking su AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!

• Ottieni il merchandising ufficiale PEASS & HackTricks

• Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi

• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguimi su Twitter 🐦 @carlospolopm.

• Condividi i tuoi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repository di Github.