Français - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Kubelet Authentication & Authorization

Support HackTricks

Kubelet Authentication

D'après la documentation :

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 config :

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

  • Webhook : Cela va activer les tokens porteurs 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 options --authentication-token-webhook et --kubeconfig ou utilisez le paramètre suivant :

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

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

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

Kubelet Authorization

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érifiera les permissions de l'utilisateur authentifié pour autoriser ou interdire une action.

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 :

"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 d'attributs de demande que l'apiserver :

  • Action

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

Par exemple, la demande suivante a essayé d'accéder aux informations des pods de 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 obtenu un Interdit, donc la demande a passé la vérification d'authentification. Sinon, nous aurions simplement reçu un message Non autorisé.

  • Nous pouvons voir le nom d'utilisateur (dans ce cas à partir du jeton)

  • Vérifiez comment la ressource était nœuds et le sous-ressource proxy (ce qui a du sens avec les informations précédentes)

Références

Support HackTricks
PreviousPentesting Kubernetes ServicesNextExposing Services in Kubernetes

Last updated