Kubelet Authentication & Authorization

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT !

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez La famille PEASS, notre collection exclusive de NFT

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦 @carlospolopm.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud dépôts GitHub.

Authentification de Kubelet

À partir de la documentation :

Par défaut, les requêtes vers l'endpoint HTTPS de 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 system:anonymous et un groupe system:unauthenticated.

Les 3 méthodes d'authentification sont :

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

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

• Webhook: Cela activera les jetons d'API bearer de kubectl comme autorisation (tout jeton valide sera accepté). Autorisez-le avec :

• assurez-vous que le groupe d'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étrage suivant :

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

Le kubelet appelle l'API TokenReview sur le serveur API configuré pour déterminer les informations de l'utilisateur à partir des jetons d'authentification

• Certificats client X509 : Permettent de s'authentifier via des certificats client X509

• voir la documentation sur l'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"
}
}

Autorisation de Kubelet

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 autorise toutes les demandes.

Cependant, l'autre valeur possible est webhook (ce que vous trouverez principalement). Ce mode vérifiera les autorisations de l'utilisateur authentifié pour autoriser ou refuser une action.

Notez que même si l'authentification anonyme est activée, l'accès anonyme pourrait ne pas avoir les autorisations 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 attributs de requête que l'apiserver :

• Action

Verbe HTTP	verbe de requête
POST	create
GET, HEAD	get (pour les ressources individuelles), list (pour les collections, y compris le contenu complet de l'objet), watch (pour surveiller une ressource individuelle ou une collection de ressources)
PUT	update
PATCH	patch
DELETE	delete (pour les ressources individuelles), deletecollection (pour les collections)

• La ressource interagissant avec l'API Kubelet est toujours nodes et le sous-ressource est déterminée à partir du chemin de la requête entrante :

API Kubelet	ressource	sous-ressource
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
tous les autres	nodes	proxy

Par exemple, la requête suivante a tenté 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 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 nodes et la sous-ressource proxy (ce qui est logique avec les informations précédentes)

Références

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks:

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT!

• Obtenez le swag officiel PEASS & HackTricks

• Découvrez La famille PEASS, notre collection exclusive de NFT

• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦 @carlospolopm.

• Partagez vos astuces de piratage en soumettant des PR aux HackTricks et HackTricks Cloud github repos.