Kubelet Autenticazione e Autorizzazione

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks

Kubelet Autenticazione

From the docss:

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

I 3 metodi di autenticazione sono:

  • Anonymous (default): impostare il parametro --anonymous-auth=true o la configurazione:
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Questo abiliterà i kubectl API bearer tokens come autorizzazione (qualsiasi token valido sarà valido). Abilitalo con:
  • assicurati che il gruppo API authentication.k8s.io/v1beta1 sia abilitato nell’API server
  • avvia il kubelet con i flag --authentication-token-webhook e --kubeconfig oppure usa la seguente impostazione:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

Il kubelet chiama la TokenReview API sull’API server configurato per determinare le informazioni sull’utente dai bearer tokens

  • X509 client certificates: Consentono di autenticarsi tramite X509 client certs
  • vedi la apiserver authentication documentation per maggiori dettagli
  • avvia il kubelet con il flag --client-ca-file, fornendo un CA bundle per verificare i certificati client. Oppure con la config:
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Autorizzazione Kubelet

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

Tuttavia, l’altro valore possibile è webhook (che è quello che troverai più spesso). Questa modalità verifica i permessi dell’utente autenticato per consentire o negare un’azione.

Warning

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

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

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

Il kubelet invoca l’API SubjectAccessReview sull’API server configurato per determinare se ogni richiesta è autorizzata.

Il kubelet autorizza le richieste API usando lo stesso approccio request attributes dell’apiserver:

  • Azione
HTTP verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • La resource che parla con la Kubelet API è sempre nodes e la subresource è determinata dal percorso della richiesta in ingresso:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

Le connessioni WebSocket basate su /exec, /run, /attach, e /portforward rientrano nella subresource predefinita proxy e sono autorizzate usando la stretta di mano HTTP GET iniziale. Un principal con solo nodes/proxy GET può comunque eseguire exec sui container se si connette direttamente a https://<node_ip>:10250 tramite WebSockets. Vedi la nodes/proxy GET -> Kubelet /exec verb confusion abuse per i dettagli.

Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni dei pods 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 ottenuto un Forbidden, quindi la richiesta passed the Authentication check. Altrimenti, avremmo ricevuto solo un messaggio Unauthorised.
  • Possiamo vedere il username (in questo caso dal token)
  • Nota come la resource fosse nodes e la subresource proxy (il che è coerente con le informazioni precedenti)

Riferimenti

Tip

Impara & pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara & pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Impara & pratica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Sostieni HackTricks