@xing-yang I am curious how other projects like VolumeSnapshotter handle situations like this.

How can the COSI controller check that the user (or namespace, or serviceaccount) has proper permissions to read/use the BucketClass?

These block-style things seem like they must be created with a markdown tool that I don't know about. Since this is a non-standard tool, I am also going to replace all instances of these with simpler built-in markdown blocks like this:

    ```yaml
    apiVersion: objectstorage.k8s.io/v1alpha2
    kind: BucketClass
    metadata:
      name: silver
    spec:
      deletionPolicy: delete
      driverName: s3.amazonaws.com
      parameters:
        key: value
    ```

@shanduur here's the more complex version of what new secret might look like. Lmk if you have feedback.

I like it! Little bit more data, and still has clear naming convention.

One more thing we should consider is Google Cloud Storage support. It is a valid value for the Protocols, yet there is no place for adding any credentials to secret for GCS.

1. Do we want to continue to support GCS in the COSI spec?
2. Do we need to consider additional fields for GCS, or do we leave it as?

I'm having some trouble with this as well. I have access to plenty of S3 experts via the Ceph project, and we have Akash involved from Azure, but we don't have any GCP experts. I wonder if we could somehow introduce a more plugin-like method that would allow different/new object storage interfaces to be defined but in a way that can't be abused. I'll try to think more about that.

In the PodSpec below, I am seeing what could be a complication for our plans to change the secret format.

If users have multiple sets of credentials, they will have to do manual work to make sure their config vars (mounted either as env vars, files, or whatever) don't overlap with each other.

At the end of the day, this is still something that k8s users have to be somewhat mindful of, so maybe it doesn't matter too much. But it's something to consider.

@shanduur I'm curious your thoughts

In my opinion it is not different than the situation that happens now. If there are 2 secrets to be mounted, those will still have to be either renamed or mounted in different directories. I am in favour of the proposed design change with separate fields, as this collision can be easily avoided at the manifest level, without need for init containers or changes to application.

hello I'm trying to use a COSI s3 bucket within a tekton pipeline and this is what they have for awscli example https://github.com/tektoncd/catalog/tree/main/task/aws-cli/0.2

I could totally work with this enhancement as well because awscli takes ENV_VARS I can set in my containers from the ones exposed by the new design, old design is troublesome as it's json in a secret property

Some future thinking, reg. the single BucketAccess for multiple BucketClaims:

Hmm. This is a good idea. Before we started on v1alpha2, I was trying to see how we could accomplish this without API changes. But if we can modify the API, maybe it would be best. I'll think about this also, and probably include this suggestion. Thanks!

We can also use validation on the API side, to ensure that the array has at least one item.