Description
Tiller was the server-side component of Helm 2. It changes resources using its own service account permissions, so inadequate access controls or excessive permissions can increase the impact of abuse.
Helm 2 has received no security updates since November 2020. Migrate to a supported Helm version that does not use Tiller.
Potential impact
- Compromised or misused Tiller instances can change workloads and resources within their granted permissions.
- An unsupported component does not receive fixes for newly identified security problems.
Remediation
- Preserve existing release information and required values, and test the new deployment procedures.
- After migration, remove the Tiller Deployment and Service and clean up dedicated service accounts and permission bindings.
- Keep required applications running while confirming that Tiller and its management access paths are gone.
Examples
The first example shows the structure of a historical Tiller deployment. Its image value is a placeholder, and it is not a recommended new installation. The second is a separate ordinary Pod example.
Before
apiVersion: apps/v1
kind: Deployment
metadata:
name: tiller-deploy
labels:
app: helm
name: tiller
spec:
selector:
matchLabels:
app: helm
name: tiller
template:
metadata:
labels:
app: helm
name: tiller
spec:
containers:
- name: tiller-v2
image: tiller-image
The Deployment runs a Tiller container. Actual reachability and permissions depend on the Service and service account configuration.
After
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
containers:
- name: sec-ctx-demo
image: busybox
securityContext:
allowPrivilegeEscalation: false
This Pod does not run Tiller and restricts container privilege escalation. Adding this Pod or merely renaming a resource does not remove an existing Tiller installation.