Research support for bucket anonymous access modes

[BlaineEXE]

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.

[k8s-triage-robot]

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]

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