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
vedere 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:
Qualsiasi richiesta che è stata autenticata con successo (inclusa una richiesta anonima) è poi 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'SubjectAccessReview API 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
| Verb HTTP | verb di richiesta |
|---|---|
POST | create |
GET, HEAD | get (per risorse individuali), list (per collezioni, incluso il contenuto completo dell'oggetto), watch (per monitorare una risorsa individuale o una collezione di risorse) |
PUT | update |
PATCH | patch |
DELETE | delete (per risorse individuali), deletecollection (per collezioni) |
La risorsa che comunica con l'API Kubelet è sempre nodes e il subresource è determinato dal percorso della richiesta in arrivo:
| API Kubelet | risorsa | subresource |
|---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
tutte le altre | nodes | proxy |
Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di kubelet senza permesso:
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)
