# Kubelet Authentication & Authorization

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

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

[**Dalla documentazione:**](https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/)

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:**
```json
"authentication": {
"anonymous": {
"enabled": true
},
```
- **Webhook**: Questo abiliterà i **token bearer API** 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`** o utilizzare la seguente impostazione:
```json
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
```
> [!NOTE]
> 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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) 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:
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Autorizzazione Kubelet <a href="#kubelet-authentication" id="kubelet-authentication"></a>

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.

> [!WARNING]
> 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:
```json
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
```
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](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) del apiserver:

- **Azione**

| Verb HTTP | verbo 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 **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        |
| _tutte le altre_ | nodes    | proxy       |

Ad esempio, la seguente richiesta ha tentato di accedere alle informazioni sui pod di kubelet senza permesso:
```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 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

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

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