Helm in Shared Clusters

Permissions, history and ownership

Because Helm uses your kubeconfig and Kubernetes RBAC, it can do exactly what your user or CI service account can do, nothing more. In shared clusters, give each team's deployer an identity limited to its namespaces, and remember that installing charts with ClusterRoles, CRDs or webhooks needs cluster-level permissions that application teams usually should not have; platform teams install those. Keep release history bounded with --history-max so namespaces do not fill with old Secrets. Decide clearly who owns which release, because two pipelines upgrading the same release with different values will fight. Watch for very large releases: each revision is stored compressed in a Secret, and Kubernetes limits a Secret to about 1 MiB, so huge charts can hit that ceiling. Finally, keep the Helm CLI version consistent across laptops and CI, and read the release notes before upgrading Helm major versions.

A namespace-scoped deployer for CI

Enough to manage releases in one namespace, including Helm's release Secrets.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: shop-deployer
  namespace: shop
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: ci
roleRef:
  kind: ClusterRole
  name: edit            # built-in role: manage most namespaced objects, including Secrets
  apiGroup: rbac.authorization.k8s.io

One owner per release

If both a GitOps controller and a CI job upgrade the same release, each will undo the other's changes. Pick one mechanism per release and remove the other's access.

Quick check: Why might a CI service account with only namespace-level permissions fail to install a third-party chart?

• The chart creates cluster-scoped objects such as CRDs or ClusterRoles
• Helm requires cluster-admin for every install
• Namespaces cannot hold Helm releases
• OCI registries require cluster-admin