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)
Per impostazione predefinita, le richieste all'endpoint HTTPS del kubelet che non vengono rifiutate da altri metodi di autenticazione configurati vengono trattate come richieste anonime, e viene assegnato un nome utente di system:anonymous e un gruppo di system:unauthenticated.
I 3 metodi di autenticazione sono:
Anonimo (predefinito): Usa l'impostazione impostando il parametro --anonymous-auth=true o la configurazione:
Webhook: Questo abiliterà i token API bearer di kubectl come autorizzazione (qualsiasi token valido sarà valido). Abilitare con:
assicurarsi che il gruppo API authentication.k8s.io/v1beta1 sia abilitato nel server API
avviare il kubelet con i flag --authentication-token-webhook e --kubeconfig oppure utilizzare la seguente impostazione:
Il kubelet chiama l'TokenReview API sul server API configurato per determinare le informazioni dell'utente dai token bearer
Certificati client X509: Consentono di autenticarsi tramite certificati client X509
consulta la documentazione sull'autenticazione dell'apiserver per ulteriori dettagli
avvia il kubelet con il flag --client-ca-file, fornendo un bundle CA per verificare i certificati client. Oppure con la configurazione:
Qualsiasi richiesta che è stata autenticata con successo (inclusa una richiesta anonima) è quindi autorizzata. La modalità di autorizzazione predefinita è AlwaysAllow, che consente 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 alcun 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:
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 di richiesta come l'apiserver:
Azione
POST
crea
GET, HEAD
ottieni (per risorse individuali), elenco (per collezioni, incluso il contenuto completo dell'oggetto), osserva (per osservare una risorsa individuale o una collezione di risorse)
PUT
aggiorna
PATCH
patch
DELETE
elimina (per risorse individuali), deletecollection (per collezioni)
La risorsa che comunica con l'API Kubelet è sempre nodi e il sotto-risorsa è determinato dal percorso della richiesta in arrivo:
/stats/*
nodi
stats
/metrics/*
nodi
metrics
/logs/*
nodi
log
/spec/*
nodi
spec
tutte le altre
nodi
proxy
Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di kubelet senza autorizzazione:
Abbiamo ricevuto un Forbidden, quindi la richiesta ha superato il controllo di autenticazione. Altrimenti, avremmo ricevuto solo un messaggio Unauthorised.
Possiamo vedere il nome utente (in questo caso dal token)
Controlla come la risorsa fosse nodes e il subresource proxy (il che ha senso con le informazioni precedenti)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
