# Kubelet Authentication & Authorization

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

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

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

Par défaut, les requêtes vers le point de terminaison HTTPS du kubelet qui ne sont pas rejetées par d'autres méthodes d'authentification configurées sont traitées comme des requêtes anonymes, et reçoivent un **nom d'utilisateur de `system:anonymous`** et un **groupe de `system:unauthenticated`**.

Les **3** méthodes d'**authentification** sont :

- **Anonyme** (par défaut) : Utilisez le paramètre **`--anonymous-auth=true` ou la configuration :**
```json
"authentication": {
"anonymous": {
"enabled": true
},
```
- **Webhook** : Cela va **activer** les **tokens bearer API** kubectl comme autorisation (tout token valide sera valide). Autorisez-le avec :
- assurez-vous que le groupe API `authentication.k8s.io/v1beta1` est activé dans le serveur API
- démarrez le kubelet avec les drapeaux **`--authentication-token-webhook`** et **`--kubeconfig`** ou utilisez le paramètre suivant :
```json
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
```
> [!NOTE]
> Le kubelet appelle l'**API `TokenReview`** sur le serveur API configuré pour **déterminer les informations utilisateur** à partir des jetons porteurs

- **Certificats clients X509 :** Permettent de s'authentifier via des certificats clients X509
- voir la [documentation d'authentification de l'apiserver](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) pour plus de détails
- démarrer le kubelet avec le drapeau `--client-ca-file`, en fournissant un bundle CA pour vérifier les certificats clients. Ou avec la configuration :
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Kubelet Authorization <a href="#kubelet-authentication" id="kubelet-authentication"></a>

Toute demande qui est authentifiée avec succès (y compris une demande anonyme) **est ensuite autorisée**. Le mode d'autorisation **par défaut** est **`AlwaysAllow`**, qui **permet toutes les demandes**.

Cependant, l'autre valeur possible est **`webhook`** (qui est ce que vous trouverez **principalement là-bas**). Ce mode **vérifie les permissions de l'utilisateur authentifié** pour autoriser ou interdire une action.

> [!WARNING]
> Notez que même si l'**authentification anonyme est activée**, l'**accès anonyme** pourrait **ne pas avoir de permissions** pour effectuer une action.

L'autorisation via webhook peut être configurée en utilisant le **paramètre `--authorization-mode=Webhook`** ou via le fichier de configuration avec :
```json
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
```
Le kubelet appelle l'API **`SubjectAccessReview`** sur le serveur API configuré pour **déterminer** si chaque demande est **autorisée.**

Le kubelet autorise les demandes API en utilisant la même approche des [attributs de demande](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) que l'apiserver :

- **Action**

| Verbe HTTP | verbe de demande                                                                                                                                                  |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| POST       | créer                                                                                                                                                             |
| GET, HEAD  | obtenir (pour des ressources individuelles), lister (pour des collections, y compris le contenu complet de l'objet), surveiller (pour surveiller une ressource individuelle ou une collection de ressources) |
| PUT        | mettre à jour                                                                                                                                                    |
| PATCH      | patch                                                                                                                                                             |
| DELETE     | supprimer (pour des ressources individuelles), deletecollection (pour des collections)                                                                            |

- La **ressource** communiquant avec l'API Kubelet est **toujours** **nodes** et la **sous-ressource** est **déterminée** à partir du chemin de la demande entrante :

| API Kubelet  | ressource | sous-ressource |
| ------------ | -------- | -------------- |
| /stats/\*    | nodes    | stats          |
| /metrics/\*  | nodes    | metrics        |
| /logs/\*     | nodes    | log            |
| /spec/\*     | nodes    | spec           |
| _toutes les autres_ | nodes    | proxy          |

Par exemple, la demande suivante a essayé d'accéder aux informations des pods de kubelet sans autorisation :
```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)
```
- Nous avons reçu un **Forbidden**, donc la requête **a passé la vérification d'authentification**. Sinon, nous aurions simplement reçu un message `Unauthorised`.
- Nous pouvons voir le **nom d'utilisateur** (dans ce cas à partir du jeton)
- Vérifiez comment la **ressource** était **nodes** et le **sous-ressource** **proxy** (ce qui a du sens avec les informations précédentes)

## Références

- [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}}
