BUILD-348: update shared resource via CSI Driver proposal

[gabemontero]

/assign @adambkaplan
/assign @deads2k
/assign @jsafrane

@coreydaley FYI

A refresh on out EP stemming from:

• feedback from @deads2k in @coreydaley 's BUILD-284: Relocate shared resources api into openshift/api repository api#979
• updates I've had in the back of my mind that were needed
• "human cherrypicking" (vs. git) content from @adambkaplan 's Update projected resource CSI driver proposal #742

If the reference helps, openshift/csi-driver-shared-resource#51 includes changes articulated here (a POC if you will), as well as the latest version of @coreydaley 's openshift/api#979 but applied to the current in-repo API (i.e. the thing we want to migratate to https://github.com/openshift/api as part of getting this enhancement in the OCP payload).

As always, thanks everyone for prior collaboration that led to this PR, and the upcoming comments from you all once you get the cycles to review

[adambkaplan]

I think there is an argument to be made that this cluster role should be installed by the operator and aggregated to the user-facing "edit" role [1]:

1. Edit users are assumed to create and manage workloads. By their very nature they are granted a high level of trust.
2. Edit users are the primary audience who need to be able to discover shared resources.
3. The details embedded in a SharedResource are IMO pseduo-sensitive, equivalent to a network IP address. The object can divulge the potential existence of a Secret/ConfigMap in another namespace. However the object does not provide full details of truly sensitive information contained in a Secret.

I really do like this solution with the use verb - it succeeds in separating usage of the shared resource with the discovery of the shared resource. I can envision a SharedResource to be secured as follows:

1. Admins have full permissions (* verb)
2. Editors have (get, list), thereby can discover the SharedResources
3. Editors can request that a service account be granted the use permission. Admin configures the appropriate cluster rolebinding.
4. Editors can then deploy a workload which uses the shared resource.

[1] https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles

[adambkaplan]

/lgtm

Not sure if we want the api discussion to block merge - IMO we can keep this as an open question and submit a follow-up PR once we've come to agreement.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adambkaplan

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 [adambkaplan]

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

[gabemontero]

@deads2k @jsafrane - just chatted with @adambkaplan on slack, and he did not intend to merge this PR with his lgtm

if you all have cycles to still look at this, I'll take whatever comments you have and craft a follow up PR to incorporate them

thanks