Aggregated roles for ducks should distinguish admin, edit, view.

[mattmoor]

/area API /kind cleanup /kind feature

Kubernetes has some built-in cluster roles for Namespace admin/editor/viewer that allow folks to curate what resources show up in each with labels like:

    rbac.authorization.k8s.io/aggregate-to-admin: "true"

We have a similar problem for consumption of our assorted Duck types, which is that some consumers only need to view, and others need to patch.

I think that we should probably define and adopt a convention similar to the Kubernetes one for folks looking to define ACL fragments as we have/are.

cc @n3wscott @vaikas

[vaikas]

Just to make sure I understand :) IIUC, we already do these for some of eventing pieces (for example channelable-manipulator), like in the Channel spec: https://github.com/knative/eventing/blob/master/docs/spec/channel.md

Since you're talking in the context of the pkg, I could imagine for example defining something like reader for addressables? We have defined in the eventing the channelable-manipulator, so that we can patch subscriptions into the channels also.

In any case, just want to make sure I understand that concrete tasks there might be so that we can chunk them into smaller pieces and assigning owners.

[mattmoor]

I think the concrete task here is to document the pattern that we should follow for setting up ACLs for duck types that are for more than read-only. I think we should consider the Kubernetes precedent as something to align that pattern with (both in mechanism, and in naming our roles). I think we should consider standardizing an additional duck label to distinguish "roles" in a standard way for our various ducks.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[mattmoor]

/lifecycle frozen