Kubelet Authentication & Authorization
Impara e pratica l'Hacking su AWS: HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Autenticazione di Kubelet
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
--anonymous-auth=true
o la configurazione:
Webhook: Questo abilità i token bearer dell'API kubectl come autorizzazione (qualsiasi token valido sarà accettato). Consentilo con:
assicurati che il gruppo API
authentication.k8s.io/v1beta1
sia abilitato nel server APIavvia il kubelet con i flag
--authentication-token-webhook
e--kubeconfig
o utilizza l'impostazione seguente:
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:
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). 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:
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 parla 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:
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 il nome utente (in questo caso dal token)
Controlla come la risorsa era nodi e la sotto-risorsa proxy (che ha senso con le informazioni precedenti)
Riferimenti
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated