The gateway chart always rendered the ClusterRole and ClusterRoleBinding, so
every install and upgrade required cluster-admin even when only namespaced
objects were needed. Installers that are namespace-admin GitOps or platform
controllers could not run the release at all, and clusters where cluster-scoped
RBAC is owned by a separate team had no supported way to split the install.
Add an rbac values block so a cluster-admin can apply the cluster-scoped objects
once and a namespace-admin can install and upgrade the release without
cluster-scoped permissions:
rbac:
create: true
clusterScoped:
create: true
clusterRoleName: ""
clusterRoleBindingName: ""
rbac.clusterScoped.create gates the ClusterRole and ClusterRoleBinding, and is
independent of the workspace mode. rbac.create additionally gates the namespaced
sandbox Role and RoleBinding, which matters because Kubernetes escalation
prevention stops an installer holding only the built-in admin role from creating
a Role that grants agents.x-k8s.io verbs it does not itself hold. The certgen
hook and credential driver RBAC keep their existing flags.
Both flags default to true, so current installs are unchanged. The helpers treat
a missing rbac block as enabled so upgrades with --reuse-values do not drop RBAC,
matching the existing workspaceResources pattern. The ClusterRoleBinding roleRef
follows clusterRoleName so a separately applied ClusterRole can carry a name the
cluster-admin chooses.
Document the migration for a release that already owns the cluster-scoped
objects: Helm deletes objects that leave the manifest, so annotate them with
helm.sh/resource-policy=keep before setting the flag, otherwise the gateway
loses TokenReview until a cluster-admin re-applies them.
Signed-off-by: ansjindal <ansjindal@nvidia.com>
* feat(helm): scope ClusterRole/ClusterRoleBinding names by release namespace
The chart creates cluster-scoped ClusterRole and ClusterRoleBinding
resources with a fixed name derived from the release name. When
multiple Helm releases coexist on the same cluster (multi-tenant),
only one release can own these resources due to Helm ownership
annotations -- the second install fails with a conflict.
Append .Release.Namespace to the ClusterRole and ClusterRoleBinding
names so each release gets its own cluster-scoped resources. The
duplication is harmless (the rules are identical and small) and
eliminates multi-tenant conflicts entirely without requiring external
RBAC management.
Signed-off-by: Brandon Squizzato <bsquizza@redhat.com>
* test(helm): add regression tests for namespace-scoped ClusterRole names
Assert the generated ClusterRole name, ClusterRoleBinding name, and
roleRef all include the release namespace suffix so multi-namespace
installations cannot silently regress to conflicting fixed names.
Signed-off-by: Brandon Squizzato <bsquizza@redhat.com>
---------
Signed-off-by: Brandon Squizzato <bsquizza@redhat.com>
ansjindal