You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question: Standard parameters for BucketClass and BucketAccessClass #244
Hello, seaweedfs-cosi-driver and cozystack maintainer here.
I'm working on implementing additional features in our COSI driver and have a question about the intended usage of the parameters field in BucketClass and BucketAccessClass.
Looking at the spec, I see that parameters are passed as opaque map<string,string> to the driver:
I want to create buckets with Object Lock (WORM protection). Should this be a BucketClass parameter?
apiVersion: objectstorage.k8s.io/v1alpha1kind: BucketClassmetadata:
name: immutable-storagedriverName: seaweedfs.objectstorage.k8s.iodeletionPolicy: Retainparameters:
objectLockEnabled: "true"# Is this the right place?
2. Granting read-only access to buckets
I want to grant read-only access to existing buckets. Should this be a BucketAccessClass parameter?
apiVersion: objectstorage.k8s.io/v1alpha1kind: BucketAccessClassmetadata:
name: readonly-accessdriverName: seaweedfs.objectstorage.k8s.ioauthenticationType: Keyparameters:
accessPolicy: "readonly"# Is this the right place?
Questions
Is this the intended usage of parameters in BucketClass and BucketAccessClass?
Are there any plans to standardize common parameters across drivers (similar to how CSI has standard parameters like csi.storage.k8s.io/fstype)?
Are there any existing drivers that implement similar functionality that I could reference?
For context, this is similar to how StorageClass parameters work in CSI:
If it helps, at a high level, the architecture and usage of COSI is intended to closely mirror that of CSI. If you are familiar with CSI driver development, you should find quite a bit of overlap with COSI.
BucketClass and BucketAccessClass are absolutely intended to be used as you described. I also think you've paired the right options for the right Classes.
In general, if an option is set per-bucket, the BucketClass is probably the right place. If an option is set per-user, the BucketAccessClass is probably the right place.
As far as standardization, we have talked about this a little. It gets complex for portability, but we do plan to add some recommended parameter names/descriptions so that different drivers can share some configurations that aren't appropriate for COSI's first-class APIs which need to be portable across myriad permutations of platform, protocol, driver, and backend. I would imagine these to be things like objectstorage.k8s.io/maxObjects, objectstorage.k8s.io/maxSize. COSI likely won't do any internal handling of parameters, just pass them through to drivers, but shared naming could still benefit the community as a whole I think. If you have recommendations for "shareable" parameter definitions, I'll be happy to make a note of them.
This example is slightly different, but Ceph-COSI has parameters that specify the namespace and name of the k8s Secret that contains credential information for COSI to create buckets/users in the Ceph RGW backend: https://github.com/ceph/ceph-cosi/blob/master/examples/bucketclass.yaml
Also worth noting, the COSI v1alpha2 API includes Read/Write access mode as a first-class API. While this isn't relevant for your v1alpha1 API, it might help you design for the present and future. The new KEP's PR is here for your reference if desired: kubernetes/enhancements#4599
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
Activity
BlaineEXE commentedon Jan 29, 2026
Thanks for the clear questions @kvaps .
If it helps, at a high level, the architecture and usage of COSI is intended to closely mirror that of CSI. If you are familiar with CSI driver development, you should find quite a bit of overlap with COSI.
BucketClass and BucketAccessClass are absolutely intended to be used as you described. I also think you've paired the right options for the right Classes.
In general, if an option is set per-bucket, the BucketClass is probably the right place. If an option is set per-user, the BucketAccessClass is probably the right place.
As far as standardization, we have talked about this a little. It gets complex for portability, but we do plan to add some recommended parameter names/descriptions so that different drivers can share some configurations that aren't appropriate for COSI's first-class APIs which need to be portable across myriad permutations of platform, protocol, driver, and backend. I would imagine these to be things like
objectstorage.k8s.io/maxObjects,objectstorage.k8s.io/maxSize. COSI likely won't do any internal handling of parameters, just pass them through to drivers, but shared naming could still benefit the community as a whole I think. If you have recommendations for "shareable" parameter definitions, I'll be happy to make a note of them.This example is slightly different, but Ceph-COSI has parameters that specify the namespace and name of the k8s Secret that contains credential information for COSI to create buckets/users in the Ceph RGW backend: https://github.com/ceph/ceph-cosi/blob/master/examples/bucketclass.yaml
Linode's COSI driver defines a read/write permissions option which more closely matches your scenarios: https://github.com/linode/linode-cosi-driver/blob/main/examples/linode-objectstorage.BucketAccessClass.yaml
Also worth noting, the COSI v1alpha2 API includes Read/Write access mode as a first-class API. While this isn't relevant for your v1alpha1 API, it might help you design for the present and future. The new KEP's PR is here for your reference if desired: kubernetes/enhancements#4599
feat(iam): support accessPolicy parameter for readonly bucket access
feat(iam): support accessPolicy parameter for readonly bucket access
feat(iam): support accessPolicy parameter for readonly bucket access
feat(iam): support accessPolicy parameter for readonly bucket access (#3
k8s-triage-robot commentedon Apr 29, 2026
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle stale/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
k8s-triage-robot commentedon May 29, 2026
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:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/remove-lifecycle rotten/closePlease send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
test(e2e): xfail bucket readonly-denial until driver enforces it
k8s-triage-robot commentedon Jun 28, 2026
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedlifecycle/rottenwas applied, the issue is closedYou can:
/reopen/remove-lifecycle rottenPlease send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
kubernetes-prow commentedon Jun 28, 2026
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
Details
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
test(e2e): xfail bucket readonly-denial until driver enforces it