Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubelet Authentication & Authorization

Support HackTricks

Kubelet Authentication

Dalla documentazione:

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 impostando il parametro --anonymous-auth=true o la configurazione:

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

  • 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:

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

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:

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

Kubelet Authorization

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:

"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 di richiesta come l'apiserver:

  • Azione

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

Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di 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 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)

Riferimenti

Supporta HackTricks
PreviousPentesting Kubernetes ServicesNextExposing Services in Kubernetes

Last updated