Helm Chart fails to install namespaced, into namespace, without cluster-level permissions.

[wasabii]

Two months ago a change was added that CREATES a ClusterRole when installing with 'namespaced' and with 'gateway' sources configured.

a270a32#diff-60307124dbbd2b5273650b5ee705153da138a0c0677fc190c2e010ddc1420796

For instance, I use Flux, to configure a tenant-based structure where namespaced users can install their own HelmReleases. These HelmReleases do not have cluster-level permissions: and thus cannot have users deploy Helm charts into their namespaces which would create resources outside their namespaces. And especially not ClusterRoles.

And thus they can no longer install the laterest External-DNS charts, when namespaced is true, and enabling gateways.

I'm not sure exactly what the goal of this ClusterRole was.

[wasabii]

Beewn staring at it for awhile. Maybe it should be in an {{else} with the Role that follows it? Not sure.

[TobyTheHutt]

@wasabii an else will likely not be enough.

• Gateway sources now add a ClusterRole even when namespaced=true so ExternalDNS can list and watch namespaces cluster-wide
• This breaks tenant installs, like Flux HelmRelease, which cannot create cluster-scope RBAC

Possible solutions:

1. I see a possible fix by conditionally skipping the extra ClusterRole/ClusterRoleBinding creation when both scopes are namespaced. For example we could create a Role for gateways in the namespace, if .Values.gatewayNamespace is set.

2. Alternatively, we might add a value like rbac.gatewayClusterPermissions which defaults to true. When it gets switched to false and namespaced=true, it won't create the extra ClusterRole/ClusterRoleBinding.

Considerations:

If your tenants need to target gateways outside their namespace, Helm alone cannot avoid cluster-scope RBAC. In such a case, a cluster admin will have to pre-create and bind cluster roles, or you have to limit yourself to a single gatewayNamespace which the tenant is allowed to bind.

Would one of those, or a similar solution work for your use case?

[wasabii]

I think either are fine. They both solve the issue: if the user wants to do a restricted namespace install, he should be able to do a restricted namespace install. Any features that cannot work because of that are the user's responsibility. But the Chart shouldn't prevent it.