container-object-storage-interface-api icon indicating copy to clipboard operation
container-object-storage-interface-api copied to clipboard

Research support for bucket anonymous access modes

Open BlaineEXE opened this issue 1 year ago • 2 comments

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.

BlaineEXE avatar Jul 25 '24 18:07 BlaineEXE

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/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was 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

k8s-triage-robot avatar Oct 23 '24 18:10 k8s-triage-robot

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/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was 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

k8s-triage-robot avatar Nov 22 '24 19:11 k8s-triage-robot