Aggregate CRD access to default user-facing roles

[AndreKR]

Welcome!

• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

I'm relatively new to Kubernetes, so there might be a good reason not to do this, but let me describe my experience.

In a deploy script I'm creating an Ingress with a path and I'd like to strip that path. In Traefik 1.7 I used PathPrefixStrip, but I'm migrating to Traefik 2.4. So in my deploy script I tried to create a StripPrefix Middleware for the respective path currently being deployed.

I got an error:

User "system:serviceaccount:deploy-413:deploy-413-service-account" cannot get resource "middlewares" in API group "traefik.containo.us" in the namespace "deploy-413"

My deploy job is running with Kubernetes' default admin role.

I was curious why I can for example create cert-manager CRDs but not Traefik CRD. It turns out that the cert-manager Helm chart creates a ClusterRole that has the label rbac.authorization.k8s.io/aggregate-to-admin: "true" set. This adds them automatically to the default admin role.

~~I think the Traefik Helm chart should set the label rbac.authorization.k8s.io/aggregate-to-admin: "true" on the ClusterRoles~~.

Actually I just noticed that the ClusterRoles that the Helm chart creates only allow Traefik to read its resources, so I'm gonna rephrase this feature request:

I think the Traefik Helm chart should create some ClusterRoles that have the label rbac.authorization.k8s.io/aggregate-to-admin: "true" set to make sure that predefined admins can automatically create resources like Middleware.

[faust64]

Hi,

You're right. Someone that has admin (or even edit) privileges within a Namespace should be able to configure his Middlewares, and other Traefik related objects, as much as they can operate their own Ingresses.

The current ClusterRole grants privileges to patch/update ingress, gateways, gatewayclasses and httproutes statuses. While as you've seen: it would only allow the Traefik Ingress Controller to get/list/watch Traefik Custom Resources.

We may want to add another ClusterRole ... If you're up for it, feel free to submit a PR. Otherwise I'll look into it.

[mloiseleur]

Hello @AndreKR,

I updated PR #464 from @faust64 and extended it with some tests and capacity to enable admin, edit or view.

You can see what it could looks like in PR #664

Will it solve your issue ?

[powo]

Users with ClusterRole/admin still cannot manage (create/delete/update...) Traefik Resources within their namespace.

The merged PR #644 allows them only to readl/list/watch the Resources.

The traefik-aggregate ClusterRole proposed in #464 would have allowed this, but it has been closed in favour of #644.

[faust64]

#664 looks good

However, that clusterrole grants privileges to traefik controller posting/updating resource status (eg tcproutes/status). Arguably, this is not some privilege you would want to delegate end-users. Only controller (and cluster admins) should have those permissions.

Besides, if the purpose is to grant someone with local-admin or local-edit rolebinding, privileges to operate their own Traefik resources: it would make more sense to have ClusterRoles focusing on those objects. While controller requires read access to secrets, services, endpoints, ... as a cluster admin, should I want to grant my end-users with management privileges over their own Traefik custom resources: I do not necessarily want them being able to see secrets (or if I do, this would go through some specific aggregated clusterrole and/or rolebinding). Simliarily, if PSP enabled, I certainly don't want to grant anyone with their admin rolebinding usage of that traefik PSP.