Research support for bucket anonymous access modes
Enhancement
Is your feature request related to a problem?/Why is this needed
gRPC spec currently has/had this code (below), which is not captured in the KEP. It is a remnant of KEP discussions that were removed from v1alpha1.
enum AnonymousBucketAccessMode {
UnknownBucketAccessMode = 0;
// Default, disallow uncredentialed access to the backend storage.
Private = 1;
// Read only, uncredentialed users can call ListBucket and GetObject.
ReadOnly = 2;
// Write only, uncredentialed users can only call PutObject.
WriteOnly = 3;
// Read/Write, uncredentialed users can read objects as well as PutObject.
ReadWrite = 4;
}
Describe the solution you'd like in detail
COSI will remove this unused proto spec, but we should also consider whether/when to start designing this feature again in the future.
@BlaineEXE remembers 1 Rook user who has mentioned a desire for anonymous access for ObjectBucketClaims.
Describe alternatives you've considered
Alternative that is still possible: if COSI believes this feature is not widely supported and not a good target for the portable API, COSI could recommend that drivers implement this via storage classes, or COSI could suggest instead that all accessors need a BucketAccess, even users external to the k8s cluster. Additional context
Likely, all users of buckets within kubernetes can use a BucketAccess to access any bucket (provided cross-namespace access is set up).
This feature might therefore be more important when considering bucket users outside of the Kubernetes cluster where BucketAccess self-service isn't available.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten