Description
Tiller is the server-side component of Helm v2. It manages resources with its assigned Kubernetes permissions. Compromise or unauthorized use of a broadly privileged Tiller instance can affect multiple workloads.
Helm v2 is no longer supported. Migrate to a supported Helm version without Tiller and remove the actual remaining server components and permissions.
Potential impact
- Workloads and cluster resources within Tiller’s permission scope may be modified.
- The retired component no longer receives security fixes or operational support.
Remediation
- Preserve release information and prepare recovery plans before migrating release management to a supported Helm version.
- After verifying the transition, remove the Tiller Deployment, Service and dedicated accounts and RBAC permissions.
- Confirm that the Tiller process and access paths are gone; changing names or labels is insufficient.
Examples
These historical examples contrast a Tiller deployment with an ordinary application deployment. tiller-image is an illustrative name, and the nginx version is old. They are not a migration procedure or current image recommendations.
Before
resource "kubernetes_deployment" "helm_server" {
metadata {
name = "tiller-deploy"
labels = {
app = "helm"
}
}
spec {
replicas = 1
selector {
match_labels = {
app = "helm"
}
}
template {
metadata {
labels = {
app = "helm"
}
}
spec {
container {
name = "helm-server"
image = "tiller-image"
}
}
}
}
}
This represents a Tiller server. Actual access depends on the image’s behavior and account and RBAC configuration.
After
resource "kubernetes_deployment" "app" {
metadata {
name = "service-deploy"
labels = {
app = "web"
}
}
spec {
replicas = 1
selector {
match_labels = {
app = "web"
}
}
template {
metadata {
labels = {
app = "web"
}
}
spec {
container {
name = "web"
image = "nginx:1.7.8"
}
}
}
}
}
This is an ordinary application example. Adding it or changing names does not remove an existing Tiller instance; clean up the old server and its permissions separately.