Nous cassons un cluster Kubernetes via Helm v2 tiller.

Nous cassons un cluster Kubernetes via Helm v2 tiller.

Helm — un gestionnaire de paquets pour Kubernetes, semblable à apt-get Ubuntu. Dans cet article, nous allons explorer la version précédente de helm (v2) avec le service tiller installé par défaut, par lequel nous accéderons au cluster.

Préparons le cluster, pour cela, exécutons la commande :

kubectl run --rm --restart=Never -it --image=madhuakula/k8s-goat-helm-tiller -- bash

Nous cassons un cluster Kubernetes via Helm v2 tiller.

Démonstration

  • Si rien n'est configuré de manière supplémentaire, helm v2 lance le service tiller, qui a des droits RBAC avec des droits d'administrateur complets au cluster.
  • Après l'installation dans l'espace de noms kube-system une proposition pour couper le son de tous les onglets le reproduisant tiller-deploy, un port 44134 est également ouvert, lié à 0.0.0.0. Cela peut être vérifié avec telnet.

$ telnet tiller-deploy.kube-system 44134

Nous cassons un cluster Kubernetes via Helm v2 tiller.

  • Nous pouvons maintenant nous connecter au service tiller. Nous utiliserons le binaire helm pour effectuer des opérations lors de la communication avec le service tiller :

$ helm --host tiller-deploy.kube-system:44134 version

Nous cassons un cluster Kubernetes via Helm v2 tiller.

  • Essayons d'obtenir les secrets du cluster Kubernetes dans l'espace de noms kube-system:

$ kubectl get secrets -n kube-system

Nous cassons un cluster Kubernetes via Helm v2 tiller.

  • Nous pouvons maintenant créer notre propre chart, où nous créerons un rôle avec des droits d'administrateur et attribuerons ce rôle au compte de service par défaut. En utilisant le token de ce compte de service, nous avons obtenu un accès complet à notre cluster.

$ helm --host tiller-deploy.kube-system:44134 install /pwnchart

Nous cassons un cluster Kubernetes via Helm v2 tiller.

  • Maintenant que pwnchart est déployé, le compte de service par défaut a un accès administratif complet. Vérifions à nouveau l'obtention des secrets depuis kube-system

$ kubectl get secrets -n kube-system

Nous cassons un cluster Kubernetes via Helm v2 tiller.

L'exécution réussie de ce scénario dépend de la manière dont tiller a été déployé, parfois les administrateurs le déploient dans un espace de noms séparé avec d'autres privilèges. Helm 3 n'est pas sujet à de telles vulnérabilités, car il n'inclut pas tiller.

Note du traducteur : l'utilisation de politiques réseau pour filtrer le trafic dans le cluster aide à se protéger contre des vulnérabilités de ce type.

Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster