feat: Improve user facing roles with dedicated roles

[remyj38]

What does this PR do?

Creating two dedicated cluster roles (view and admin) for user facing aggregated roles.

Motivation

User facing aggregated roles were supported since #664 but only aggregating Traefik cluster role to aggregated role.
In my opinion, this is not the right way to implement it as the Traefik cluster role only have view permission to traefik CRDs while admin aggregated role should "allow read/write access to most resources in a namespace".

More

• Yes, I updated the tests accordingly
• Yes, I updated the schema accordingly
• Yes, I ran make test and all the tests passed

[mloiseleur]

Hello @remyj38 ,

Thank you for your interest.
For the use case, we’re unsure about this need and the traction it will receive. We are going to leave the status as kind/proposal to give the community time to let us know if they would like this idea.

We will reevaluate as people respond.

For the implementation, it would require the maintainers to update rbac in a third file. It's already not ideal with the ClusterRole and the Role.
🤔 So why adding a duplicate rbac file instead of adding write access in the existing rbac when this feature is enabled ?

[remyj38]

Hello

I understand to wait for community traction on it.

Some other charts like cert-manager or external-secrets implement it and it prevents admins to searching all the doc about which CRDs they needs to add to there RBAC when implementing Traefik.

It's also make upgrades easier for users when new CRD is added.

For the implementation, it would require the maintainers to update rbac in a third file. It's already not ideal with the ClusterRole and the Role.

I think it can be possible to merge both to one file. I'll check and do a PR if it possible

So why adding a duplicate rbac file instead of adding write access in the existing rbac when this feature is enabled ?

Because of least privileges rule. Traefik don't need to edit the objects

[rmoreas]

+1 for adding this feature. As someone who is new to Traefik, I was genuinely surprised that this capability isn’t already available. Implementing it would significantly improve the ability to set up proper RBAC for cluster users and aligns well with common Kubernetes security expectations. This addition would make the Traefik chart feel more complete and more secure to operate in multi‑user environments.

[rmoreas]

Here an example on how these user cluster roles *-edit and *-view are setup by CloudNativePG Operator: https://github.com/cloudnative-pg/charts/blob/main/charts/cloudnative-pg/templates/rbac.yaml#L117

[mloiseleur]

I'll check and do a PR if it possible

@remyj38 Do you think you can rebase and update this PR?

[remyj38]

I'll check and do a PR if it possible

@remyj38 Do you think you can rebase and update this PR?

I'll try to look at it next week

[remyj38]

I'll check and do a PR if it possible

@remyj38 Do you think you can rebase and update this PR?

Ok, it's rebased !

And I looked at merging service role and user roles, but it will create a lot of conditions in the template and makes it unreadable...

[mloiseleur]

@remyj38 🤔 A PR that duplicates RBAC lines to that extent won't be sustainable in the long term. We will surely miss a new right here or there. We clearly cannot review or merge it "as is".

Wdyt about adopting the same pattern as for _podtemplate.tpl and _service.tpl, that are after called (respectively) by daemonset.yaml & deployment.yaml?

You are welcome to explore other patterns, too, if you find a better one.
As you can imagine, we clearly need simplicity and reliability in this chart.

[rmoreas]

As suggested by @mloiseleur, usage of named templates can improve maintainability.

I've added some extra suggestions for improvement.

[rmoreas]

I would change this condition to just:

{{- if .Values.rbac.enabled }}

These roles should always be created, but aggregation should be optional (with .Values.rbac.aggregateClusterRoles)

[rmoreas]

Aggregation is not supported on namespace-scoped Role objects

[rmoreas]

Two user-facing cluster roles are probably sufficient with the names:

• {{ template "traefik.clusterRoleName" . }}-edit
• {{ template "traefik.clusterRoleName" . }}-view

[rmoreas]

When .Values.rbac.namespaced is true, the names might be better:

• {{ template "traefik.fullname" $ }}-edit
• {{ template "traefik.fullname" $ }}-view

[rmoreas]

For the edit ClusterRole, I would make this:

    {{- if .Values.rbac.aggregateClusterRoles }}
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    {{- end }}

[rmoreas]

For the view ClusterRole this could be simply:

    {{- if .Values.rbac.aggregateClusterRoles }}
    rbac.authorization.k8s.io/aggregate-to-view: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    {{- end }}

See also comment for the edit ClusterRole.