csi

we have added clusterID mapping to identify the volumes in case of a failover in Diaster recovery in ceph/ceph-csi#1946. with ceph/ceph-csi#2314 we are moving to a configuration in configmap for clusterID and poolID mapping. and with #2314 we have all the required information to identify the image mappings and the workaround implementation in #194

Is your feature request related to a problem?/Why is this needed
kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-0.10" takes a long time.

/feature

Describe the solution you'd like in detail
Publish zip, tarball archives with just the deploy/ files.

Describe alternatives you've considered
Publish a tag with j

What

Encrypt volumes provisioned by topolvm

How

eg. LUKS

Generate per-PVC encryption keys, stored as Kubernetes secrets.

The threat this would mitigate is physical theft of server (as keys are only kept in memory)

When running kubectl describe datasets dataset-name the remote bucket credentials are shown in plaintext. This also happens with kubectl describe datasetinternal/dataset-name when the cache plugin still hasn't provisioned the caching endpoint along with its credentials.

It seems that a common way of storing non-Unicode secrets in Vault is to base64-encode them. Is there currently a way to mount these through the CSI provider without adding a manual decoding process?
If not, the Azure driver supports an objectEncoding property (see Azure/secrets-store-csi-driver-provider-azure#236). Would you accept a PR that adds a similar feature?

We can have the following color codes for the corresponding drive states

in-use, ready -> Green
available -> Blue
unavailable, terminating, released -> Red

the error messages (messages with * prefix) can be displayed in Red