- Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
Helm est le **gestionnaire de paquets** pour Kubernetes. Il permet de regrouper des fichiers YAML et de les distribuer dans des dépôts publics et privés. Ces paquets sont appelés **Helm Charts**. **Tiller** est le **service****exécuté** par défaut sur le port 44134 offrant le service.
Si vous pouvez **énumérer les pods et/ou les services** de différents espaces de noms, énumérez-les et recherchez ceux qui ont **"tiller" dans leur nom** :
Helm is a package manager for Kubernetes that allows developers and operators to more easily package, configure, and deploy applications and services onto Kubernetes clusters. Helm uses a client-server architecture, where the client is called `helm` and the server is called `tiller`. Tiller runs inside the Kubernetes cluster and manages releases (installations) of Helm packages.
### Tiller Security
Tiller is a privileged component in the Kubernetes cluster, with the ability to create, modify, and delete resources in any namespace. As such, it is important to secure Tiller to prevent unauthorized access and potential attacks.
#### Tiller Deployment
By default, Tiller is deployed with full administrative privileges. This means that any user or application with access to Tiller can perform any action on the Kubernetes cluster. To secure Tiller, it is recommended to deploy it with limited privileges.
#### Tiller RBAC
Role-Based Access Control (RBAC) can be used to limit the permissions of Tiller. RBAC allows you to define roles and permissions for users and applications in the Kubernetes cluster. By default, Tiller is deployed with a `cluster-admin` role, which grants full administrative privileges. To secure Tiller, you should create a new role with limited permissions and assign it to Tiller.
#### Tiller TLS
Transport Layer Security (TLS) can be used to encrypt communication between `helm` and Tiller. By default, Tiller does not use TLS, which means that all communication is unencrypted. To secure Tiller, you should enable TLS and configure `helm` to use it.
### Tiller Pentesting
#### Tiller Information Gathering
To begin pentesting Tiller, you should first gather information about the Tiller deployment. This can include the Tiller version, the Kubernetes version, the Tiller deployment configuration, and any RBAC roles assigned to Tiller.
#### Tiller Enumeration
Once you have gathered information about the Tiller deployment, you can begin enumerating the resources managed by Tiller. This can include Kubernetes objects, such as pods, services, and deployments, as well as Helm releases.
#### Tiller Exploitation
If you find a vulnerability in Tiller or one of the resources managed by Tiller, you can attempt to exploit it to gain unauthorized access or perform other malicious actions. This can include privilege escalation, data exfiltration, or even a full cluster takeover.
Tiller is a critical component of the Helm package manager for Kubernetes. As such, it is important to secure Tiller to prevent unauthorized access and potential attacks. By following best practices for Tiller deployment, RBAC, and TLS, you can help ensure the security of your Kubernetes cluster.
Une fois que vous l'avez découvert, vous pouvez communiquer avec lui en téléchargeant l'application client helm. Vous pouvez utiliser des outils tels que `homebrew`, ou consulter [**la page des versions officielles**](https://github.com/helm/helm/releases)**.** Pour plus de détails ou pour d'autres options, consultez [le guide d'installation](https://v2.helm.sh/docs/using\_helm/#installing-helm).
Par défaut, **Helm2** était installé dans l'espace de noms **kube-system** avec des **privilèges élevés**, donc si vous trouvez le service et y avez accès, cela pourrait vous permettre d'**élever les privilèges**.
Tout ce que vous avez à faire est d'installer un package comme celui-ci : [**https://github.com/Ruil1n/helm-tiller-pwn**](https://github.com/Ruil1n/helm-tiller-pwn) qui donnera au **jeton de service par défaut l'accès à tout dans l'ensemble du cluster.**
Dans [http://rui0.cn/archives/1573](http://rui0.cn/archives/1573), vous trouverez **l'explication de l'attaque**, mais en gros, si vous lisez les fichiers [**clusterrole.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrole.yaml) et [**clusterrolebinding.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrolebinding.yaml) dans _helm-tiller-pwn/pwnchart/templates/_ vous pouvez voir comment **tous les privilèges sont donnés au jeton par défaut**.