Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 :
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 :
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 :
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 :
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
| 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 :
Nous avons obtenu un Interdit, donc la requête 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)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
