Spike Objective

From our API review to get to tech preview:

Your API needs to be complete in terms of security and visiblity in alpha or the feedback you receive is not useful for determining whether or not you can graduate.

In a restrictive setting (which should be on-by-default in openshift), I don't see how a pod author locates SharedResources. Granting GET permissions to a particular item does not allow LIST permission which show all content, not just ones you have GET access for.

Being able to describe a complete and secure story here is a blocker for alpha.

[1]

A restricted user/service account should:

1. Be able to list all of the shared resources available on the cluster (discoverability)
2. Should not be able to mount the shared resource unless permission has been granted by some level of administrator.

We also need to get agreement on the api group name - we've agreed to SharedResource as the object's name. storage.openshift.io already exists as an api group, with resources related to the local storage operator.

Acceptance Criteria

• Define/design APIs and procedures that enable share discoverability for restricted users.
• Come to agreement on the group name for the SharedResource CRD.
• Update our enhancement proposal for the shared resource CSI driver for review and merge next version as "implementable".

Notes

Restricting to just "list" does not make sense in Kubernetes - "list" gives you names of things, "get" gives you the the details of the object.
Security best practices recommend that service accounts be restricted to access ServiceAccounts [3].
Verbs in Kubernetes RBAC are flexible - we can for example create a "use" verb and gate control on this. This is how SCCs work.

[1] https://github.com/openshift/api/pull/979#discussion_r708347447

[2] https://github.com/openshift/enhancements/blob/master/enhancements/cluster-scope-secret-volumes/csi-driver-host-injections.md

[3] https://kubernetes.io/docs/concepts/configuration/secret/#clients-that-use-the-secret-api