Authentification et autorisation du Kubelet

Tip

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

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Authentification du Kubelet

From the docss:

Par défaut, les requêtes vers le endpoint 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 se voient attribuer un nom d’utilisateur system:anonymous et un groupe system:unauthenticated.

Les 3 méthodes d’authentification sont :

• Anonymous (par défaut) : régler le paramètre --anonymous-auth=true ou la configuration :

"authentication": {
"anonymous": {
"enabled": true
},

• Webhook: Cela va activer les kubectl API bearer tokens comme autorisation (tout token valide sera valide). Autorisez-le avec:
• assurez-vous que le groupe d’API authentication.k8s.io/v1beta1 est activé sur le serveur API
• démarrez le kubelet avec les --authentication-token-webhook et --kubeconfig flags ou utilisez le réglage suivant:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

Le kubelet appelle l’TokenReview API sur l’API server configuré pour déterminer les informations utilisateur à partir des bearer tokens

• X509 client certificates : Permettent de s’authentifier via des certificats clients X509
• voir la apiserver authentication documentation pour plus de détails
• démarrez le kubelet avec l’option --client-ca-file, en fournissant un bundle CA pour vérifier les certificats clients. Ou via la config:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Autorisation du Kubelet

Toute requête qui est authentifiée avec succès (y compris une requête anonyme) est alors autorisée. Le mode d’autorisation par défaut est AlwaysAllow, qui autorise toutes les requêtes.

Cependant, l’autre valeur possible est webhook (c’est ce que vous rencontrerez la plupart du temps). Ce mode va vérifier les permissions de l’utilisateur authentifié pour autoriser ou refuser une action.

Warning

Notez que même si l’authentification anonyme est activée, l’accès anonyme pourrait ne pas disposer 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 :

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

Le kubelet appelle l’API SubjectAccessReview sur le serveur API configuré pour déterminer si chaque requête est autorisée.

Le kubelet autorise les requêtes API en utilisant la même approche des request attributes que l’apiserver :

• Action

• La ressource qui s’adresse à l’API Kubelet est toujours nodes et la sous-ressource est déterminée à partir du chemin de la requête entrante :

Note

Les connexions WebSocket pour /exec, /run, /attach, et /portforward tombent dans la sous-ressource proxy par défaut et sont autorisées en utilisant la poignée de main HTTP initiale GET. Un principal disposant uniquement de nodes/proxy GET peut quand même exécuter des containers s’il se connecte directement à https://<node_ip>:10250 via WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.

Par exemple, la requête suivante a essayé d’accéder aux informations des pods du kubelet sans autorisation:

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. Si ce n’était pas le cas, nous aurions obtenu simplement un message Unauthorised.
• On peut voir le username (dans ce cas depuis le token)
• Vérifiez comment la resource était nodes et la subresource 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/
• nodes/proxy GET -> kubelet exec via WebSocket bypass

Tip

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

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.