# Kubelet Autenticazione e Autorizzazione

{{#include ../../../banners/hacktricks-training.md}}

## Kubelet Autenticazione <a href="#kubelet-authentication" id="kubelet-authentication"></a>

[**From the docss:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)

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:
```json
"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:
```json
"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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) 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:
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Autorizzazione Kubelet <a href="#kubelet-authentication" id="kubelet-authentication"></a>

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:
```json
"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](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) dell'apiserver:

- **Azione**

| HTTP verb | request verb                                                                                                                                                  |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST      | create                                                                                                                                                        |
| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) |
| PUT       | update                                                                                                                                                        |
| PATCH     | patch                                                                                                                                                         |
| DELETE    | delete (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 API  | resource | subresource |
| ------------ | -------- | ----------- |
| /stats/\*    | nodes    | stats       |
| /metrics/\*  | nodes    | metrics     |
| /logs/\*     | nodes    | log         |
| /spec/\*     | nodes    | spec        |
| _all others_ | nodes    | proxy       |

> [!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](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) per i dettagli.

Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni dei pods del kubelet senza autorizzazione:
```bash
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

- [https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)
- [nodes/proxy GET -> kubelet exec via WebSocket bypass](https://grahamhelton.com/blog/nodes-proxy-rce)

{{#include ../../../banners/hacktricks-training.md}}
