Kubernetes autorise les actions sous forme de verbes (get, list, create, update) sur des ressources (pods, secrets, roles). Le RBAC est censé empêcher une identité de s'octroyer plus qu'elle n'a, mais plusieurs permissions spécifiques brisent ce confinement. En détenir une seule transforme un service account restreint en une voie vers l'admin du cluster : un role trop large, les verbes escalate ou bind qui défont le contrôle anti-escalade, impersonate pour devenir une autre identité, la signature de certificats pour émettre un certificat client privilégié, l'API TokenRequest pour émettre les tokens d'autres service accounts, ou la capacité de créer des pods et d'en planifier un qui possède son nœud.
Cartographiez d'abord les permissions de l'identité :
kubectl auth can-i --list # the full rule set for this identity
# flag the dangerous ones:
kubectl auth can-i create pods --all-namespaces
kubectl auth can-i get secrets --all-namespaces
kubectl auth can-i impersonate users
kubectl auth can-i create clusterrolebindings
kubectl auth can-i '*' '*'
Sous-sujets#
- Roles trop permissifs : roles à wildcard ou lisant les secrets.
- Verbes escalate et bind : s'octroyer plus que l'on ne détient.
- Usurpation d'identité : agir comme un autre utilisateur, groupe ou service account.
- Approbation de CSR : émettre un certificat client privilégié.
- API TokenRequest : émettre des tokens pour d'autres service accounts.
- Abus de token de service account : monter ou réutiliser des tokens puissants.
- Création de pod vers le nœud : planifier un pod qui possède son nœud.