Description
A Tiller Service pointing to running Tiller instances leaves an internal route to the Helm 2 management endpoint. Without a backend, the Service alone cannot perform Tiller operations, but unused configuration should still be removed.
Helm 2 is unsupported. Remove both the Service and server components after migration. Deleting only the Service does not block direct access through Pod addresses or port forwarding.
Potential impact
- If Tiller is running without adequate authentication, other workloads may abuse its service account permissions.
- Leftover management configuration and permissions make actual deployment paths harder to understand.
Remediation
- First confirm that required releases and applications continue to work with the new deployment approach.
- Remove unused Tiller Services and Deployments, then clean up dedicated service accounts and unnecessary permission bindings.
- Check backends and direct access paths, and test required services.
Examples
The first example routes to Tiller; the second is a separate ordinary Service. Adding the second configuration does not delete an existing Tiller Service.
Before
apiVersion: v1
kind: Service
metadata:
name: tiller-deploy
labels:
app: helm
name: tiller
spec:
type: ClusterIP
selector:
app: helm
name: tiller
ports:
- name: tiller
port: 44134
targetPort: tiller
Traffic can reach a matching Pod if it defines a port named tiller. Check the actual backends and authentication settings.
After
apiVersion: v1
kind: Service
metadata:
name: some-service
labels:
name: some-label
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
This ordinary Service excerpt has no selector. It needs separate endpoint management, such as EndpointSlices, and says nothing about Tiller remaining elsewhere.