# Kubelet Verifikasie & Magtiging

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

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

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

Standaard word versoeke aan die kubelet se HTTPS-endpunt wat nie deur ander ingestelde verifikasiemetodes verwerp word nie, as anonieme versoeke behandel, en gegee 'n **gebruikersnaam van `system:anonymous`** en 'n **groep van `system:unauthenticated`**.

Die **3** verifikasie **metodes** is:

- **Anoniem** (verstek): Stel die parameter **`--anonymous-auth=true` of die konfigurasie:**
```json
"authentication": {
"anonymous": {
"enabled": true
},
```
- **Webhook**: Dit sal die kubectl **API bearer tokens** as magtiging **inskakel** (enige geldige token sal geldig wees). Laat dit toe met:
- verseker dat die `authentication.k8s.io/v1beta1` API-groep in die API-server geaktiveer is
- begin die kubelet met die **`--authentication-token-webhook`** en **`--kubeconfig`** vlae of gebruik die volgende instelling:
```json
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},
```
> [!NOTE]
> Die kubelet roep die **`TokenReview` API** op die geconfigureerde API-server aan om **gebruikerinligting te bepaal** uit bearer tokens
> 
- **X509 client certificates:** Laat toe om via X509 kliëntsertifikate te verifieer
- see the [apiserver authentication documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
- start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with. Or with the config:
```json
"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}
```
## Kubelet-magtiging <a href="#kubelet-authentication" id="kubelet-authentication"></a>

Enige versoek wat suksesvol geauthentiseer is (insluitend 'n anonieme versoek) **word daarna gemagtig**. Die **verstek** magtigingsmodus is **`AlwaysAllow`**, wat **alle versoeke toelaat**.

Die ander moontlike waarde is egter **`webhook`** (wat jy **meestal daar sal vind**). Hierdie modus sal **die toestemmings van die geauthentiseerde gebruiker nagaan** om 'n aksie toe te laat of te weier.

> [!WARNING]
> Neem kennis dat selfs al is die **anonieme authentisering aangeskakel**, het die **anonieme toegang** moontlik **geen bevoegdhede** om enige aksie uit te voer nie.

Die magtiging via webhook kan gekonfigureer word met die **param `--authorization-mode=Webhook`** of via die konfigurasielêer met:
```json
"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},
```
Die kubelet roep die **`SubjectAccessReview`** API op die gekonfigureerde API-server om te **bepaal** of elke versoek **gemagtig** is.

Die kubelet magtig API-versoeke deur dieselfde [request attributes](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#review-your-request-attributes) benadering as die apiserver te gebruik:

- **Aksie**

| 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)                                                                                         |

- Die **resource** wat met die Kubelet api praat is **altyd** **nodes** en die **subresource** word **bepaal** vanaf die inkomende versoek se pad:

| Kubelet API  | resource | subresource |
| ------------ | -------- | ----------- |
| /stats/\*    | nodes    | stats       |
| /metrics/\*  | nodes    | metrics     |
| /logs/\*     | nodes    | log         |
| /spec/\*     | nodes    | spec        |
| _all others_ | nodes    | proxy       |

> [!NOTE]
> WebSocket-based `/exec`, `/run`, `/attach`, and `/portforward` val in die standaard **proxy** subresource en word gemagtig deur die aanvanklike HTTP **GET** handdruk. ’n Principal met slegs `nodes/proxy` **GET** kan steeds containers exec as dit direk met `https://<node_ip>:10250` oor WebSockets verbind. Sien die [nodes/proxy GET -> Kubelet /exec verb confusion abuse](../abusing-roles-clusterroles-in-kubernetes/README.md#nodesproxy-get---kubelet-exec-via-websocket-verb-confusion) vir besonderhede.

Byvoorbeeld, die volgende versoek het probeer toegang verkry tot die pods-inligting van kubelet sonder toestemming:
```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)
```
- Ons het 'n **Forbidden** gekry, dus het die request **passed the Authentication check**. As dit nie so was nie, sou ons net 'n `Unauthorised` boodskap gekry het.
- Ons kan die **username** sien (in hierdie geval van die token)
- Kontroleer hoe die **resource** **nodes** was en die **subresource** **proxy** (wat sin maak met die vorige inligting)

## References

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