What is the permission model for bucket sharing?

[guymguym]

Hi

I couldn't find in the design doc any reference to how permissions are granted/revoked - https://github.com/yard-turkey/lib-bucket-provisioner/blob/master/doc/design/object-bucket-lib.md#bucket-sharing

Did I miss it specified somewhere?

Otherwise, anyone can claim any existing bucket and get unconditional access to it.

Thanks

[copejon]

Grant() and Revoke() calls can be controlled via RBAC permissions. The design intends pre-existing buckets to be made available through a StorageClass with the bucketName: parameter defined.

Since an OBC would have to reference one of these SCs, access can be controlled via RBAC.
ClusterRoles can be used to define sets of SCs by name and ServiceAccounts can then be linked to them. In this model, user namespaced service accounts would only be allowed to get certain SCs.

The cons here being that it's a bare-minimum level of access control and puts a lot on the admins to maintain it. Before we consider moving the library towards a beta state, it's something we should consider adding as a configurable feature within the library itself.

cc @jeffvance

[guymguym]

Thanks Jon.

Does this design mean that bucket sharing between applications always requires platform admin work? I think most ACL solutions allow data owners to share it with other users without admin involved.

So a storage-class that does not specify a bucketName allows to claim any of the existing buckets without restrictions? Is that mode usable at all then?

Thanks!

On Tue, May 28, 2019, 17:16 Jon Cope notifications@github.com wrote:

Grant() and Revoke() calls can be controlled via RBAC permissions. The design intends pre-existing buckets to be made available through a StorageClass with the bucketName: parameter defined.

Since an OBC would have to reference one of these SCs, access can be controlled via RBAC. ClusterRoles can be used to define sets of SCs by name and ServiceAccounts can then be linked to them. In this model, user namespaced service accounts would only be allowed to get certain SCs.

The cons here being that it's a bare-minimum level of access control and puts a lot on the admins to maintain it. Before we consider moving the library towards a beta state, it's something we should consider adding as a configurable feature within the library itself.

cc @jeffvance https://github.com/jeffvance

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yard-turkey/lib-bucket-provisioner/issues/94?email_source=notifications&email_token=AAIKOXSTDKGJNZ7FU7PWAMLPXU5CPA5CNFSM4HPAHNY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMISAY#issuecomment-496535811, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIKOXST5J3NSZB672EISKLPXU5CPANCNFSM4HPAHNYQ .

[jeffvance]

We have discussed the idea of being able to specify some sort of ACL in the OBC and in the SC, where the OBC's ACL cannot exceed the SC's ACL. This concept could possibly apply to all storage not just buckets. The amount of effort need to implement ACL-like security was deemed to be more than we could tackle for the initial phases.

[copejon]

@guymguym

Does this design mean that bucket sharing between applications always requires platform admin work? I think most ACL solutions allow data owners to share it with other users without admin involved.

If a user wanted to share access between Pods in a Namespace, the solution would be to mount the OBC's associated secret to each Pod. That doesn't differentiate ACLs between apps however.

Generating secondary keys for a dynamically created bucket is something that we've had planned for a long time. It's been back burnered while we were preparing for cephalcon but I would think it's a necessary feature for general use.

So a storage-class that does not specify a bucketName allows to claim any of the existing buckets without restrictions? Is that mode usable at all then?

Currently, we use the bucketName field to determine whether the bucket is static (pre-existing) or dynamic. If the key is present and value is non-nil, we assume the SC references an existing bucket. If it is absent or a nil value, we assume the request is for a dynamic bucket. OBCs that specify a bucket by name won't be fulfilled if that bucket already exists.

[guymguym]

Thanks @copejon @jeffvance for the answers!

So how would you imagine that design evolve?

How about that OBC will have an optional list of roles that should be granted access to the bucket. When checking permissions to claim an existing bucket we would check if the claim belongs to any of the roles currently allowed by existing OBC's to that bucket. This makes sense given that a fulfilled OBC represents a granted access permission in itself, so by this extension, each app can choose to share the access to others.

Perhaps this can be developed in the library generically?

[copejon]

optional list of roles that should be granted access to the bucket

I'm having trouble visualizing what a role would represent. Is it a unique policy (RW, R, W)? Or something more complex to identify k8s users/serviceaccounts? Should it span namespaces?

[guymguym]

@copejon Just a reference to an RBAC Role

[copejon]

@guymguym Ah! Right, I'm familiar with RBAC ClusterRoles/Roles/Bindings. Was thinking you might have meant something more abstract :)

Would these Roles be bound to the ServiceAccount of the app Pods? I think to be enforceable, we'd have to assume the app Pod is k8s aware and making API calls.