Add Default RBAC for Non-Admins

[adambkaplan]

Changes

• Add view aggregate role for inspecting Shipwright Build objects
• Add edit aggregate role for managing Builds, BuildRuns, and BuildStrategies.
• Ensure aggregated user roles are installed in e2e testing

Fixes #1023

/kind feature

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Add default RBAC controls for "view" and "edit" users.

[SaschaSchwarze0]

Nice. Do we need to mention this somewhere in our documentation?

[gabemontero]

/approve

+1 on @SaschaSchwarze0 's note about identifying in the docs ... feels like a new rbac.md file.

could also get into some detail about the rbac defined for the controllers, though I would not block merge if you did not want to take that on @adambkaplan

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gabemontero

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [gabemontero]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[qu1queee]

@adambkaplan looks good. Any reasons you could think against enabling the get verb for the cluster-scope strategies?

My two thoughts:

• (abstraction): Users shouldn't need to take a look at them. Would like to keep them as much abstracted as possible. I think list is good enough.
• (security): Being able to see cluster-scope strategies might expose too much. Not sure if this applies in general, probably yes wherever there is a hard definition between users and strategy admins.

wdyt?

[SaschaSchwarze0]

@adambkaplan looks good. Any reasons you could think against enabling the get verb for the cluster-scope strategies?

My two thoughts:

* (_abstraction_): Users shouldn't need to take a look at them. Would like to keep them as much abstracted as possible. I think `list` is good enough.

* (_security_): Being able to see cluster-scope strategies might expose too much. Not sure if this applies in general, probably yes wherever there is a hard definition between users and strategy admins.

wdyt?

I think get and list should be fine. Security-wise, a strategy does not expose anything in addition to what users can see anyway in the generated TaskRun or Pod. The only thing you could hide is the existance. Not sure if there is a use case for this. Scenario-wise having access to the strategies is important for client applications. If you implement a UI that allows to create a Build, then it will want to prefil a strategy drop-down with the available strategies. Once a strategy is selected, a UI will also want to look at the strategy's parameter definitions to render a form for them.

[qu1queee]

@SaschaSchwarze0 right good points.

[adambkaplan]

Tekton allows "view" users to get any TaskRun in their namespace, so I think this proves @SaschaSchwarze0's point that there is minimal security risk granting "get" permission to ClusterBuildStrategy.

https://github.com/tektoncd/pipeline/blob/main/config/clusterrole-aggregate-view.yaml

If you implement a UI that allows to create a Build, then it will want to prefil a strategy drop-down with the available strategies. Once a strategy is selected, a UI will also want to look at the strategy's parameter definitions to render a form for them.

I imagine UIs for k8s create their own rolebindings and service accounts, though they may inherit these user-facing "view" or "edit" roles. This is a reasonable user story IMO.

[SaschaSchwarze0]

Thanks for adding the details. Suggesting to add a link to the Kubernetes documentation about aggregated roles.

[SaschaSchwarze0]

Suggested change

	This role is aggregated to the Kubernetes "view" role.
	This role is [aggregated to the Kubernetes "view" role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles).

[adambkaplan]

Thanks for the suggestion - I think the "Default user roles" section of that article may be a better fit:

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings

[SaschaSchwarze0]

/lgtm