Skip to content

[Apr 2025] - Allow administrators to limit which Bucket(Access)Classes users can use #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
BlaineEXE opened this issue Apr 11, 2025 · 0 comments

Comments

@BlaineEXE
Copy link
Contributor

Enhancement

Is your feature request related to a problem?/Why is this needed

Admins should have a way to limit which BucketClasses and BucketAccessClasses that certain users (namespaces) can use.
This can be broken down into 2 parts:

basic access limits: limiting the allowed B(A)Classes on a per-namespace basis
quota limits: limiting the number of references any BClaim/BAccess can make in total or for particular B(A)Classes
The latest prior art in the Kube ecosystem is Pod Security Admission and Resource Quotas -- and of course RBAC

None of the above tools allow us to limit the references that are allowed in BClaims/BAccesses. However, admins can rely on Resource Quotas and RBAC to limit whether namespaces are allowed to create BClaims/BAccesses, and how many can be created. We should rely on existing mechanisms where possible, so we will not plan to implement tools for those limitations.

From our current understanding, there are no KEPs currently that are attempting to address broadly-applicable control of references. We could attempt to start such a KEP if we want to.

We may wish to implement a mechanism in COSI that will allow us to give administrators control over user consumption of COSI resources during COSI's early phases (right now). We should do our best to implement this mechanism in such a way that it can be easily replaced with a broadly-applicable implementation in the future.

Describe the solution you'd like in detail

Solution TBD. A sig-auth member at Kubecon SLC (2024) recommended designing auth using annotations as a first-pass design, since annotations are simple and often fully effective enough for Administrators.

Describe alternatives you've considered

Pod Security Admission and Resource Quotas have both been investigated thoroughly, and neither have abilities that could limit the ability for COSI resources to reference other COSI resources. E.g., User abilities on BucketClaim can be limited with RBAC and ResourceQuotas, but there is no way to limit BucketClaim's ability to reference certain BucketClasses (or BucketAccessClasses, if that becomes relevant).

Additional context

This issue was manually migrated from the archived issue: kubernetes-retired/container-object-storage-interface-api#107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: To do for v1alpha2
Development

No branches or pull requests

1 participant