Thoughts on API mappings

[jcope]

If gGroups butchers the embedded images, you can view and edit a generated copy of them in draw.io. 

Here's my interpretation of what the API mappings would look like as discussed in today's review.

Access and Identity management are coupled under BucketAccessRequests (BAR).  Given that a policy is being applied, BARs must always be generated after buckets.  This is because the policy has to specify both the identity and the resource being accessed.  When a user creates a new BAR, it may either:

(Greenfield ID/Policy)

A) mint credentials and apply a policy defined in the BucketAccessClass to grant access to the credentials to the Bucket

or 

B) associate a cloud provider IAM policy to a specified k8 service account to grant access to the credentials to the Bucket 

(Brownfield ID/Policy)

A) clone an existing secret specified by the existing BucketAccess object into the namespace of the statically bound BAR and enable access to the Bucket

or

B) associate the existing IAM role named in the BucketAccess to the service account specified by the statically bound BAR and enable access to the Bucket

A couple challenges come to mind: 

1) In greenfield, how do you identify the owner of the bucket in order to give them ownership permissions.

One thought I've had would be to pre-populate the BucketContent.spec.bindableNamespaceSelector array with an entry for the originating namespace.  However, this array doesn't (at least yet) specify allowed actions.  If it did, that would be relatively straight forward.  The array would specify the originating namespace and a policy: "*" to indicate full control.  Unfortunately, this doesn't fit well when BucketAccessRequests must specify a BucketAccessClass, which would define a set of policies.

2) How can (or should) cluster users set namespace access to greenfield buckets they own?  That is, I have a greenfield bucket, now how do I permit other namespaces access to it?

Note: "Parent" and "Cloned" Secret at named to show that, during credential minting, the provisioner will write to a secret in its namespace, which will then be cloned by the controller to the app namespace.