Generating a secret from secrets-store-csi-driver for Provider

[NeuronButter]

Hi there,
I'm trying to think of a way for Flux to be able to get a secret out of OpenBao (/Vault) to be able to use for the address of a Provider. The closest solution to this I've got is using the secrets-store-csi-driver to sync a secret to be referenced by a secretRef, but the only limitation is that it requires the volume to be mounted on a Pod. My thoughts are that it would be mounted on the notification-controller, but I'm not sure on how to extend the controller to be able to consume that volume (which will in turn trigger the secret to generate).
Has anyone encountered such a situation before (not necessarily using the CSI driver either, but just some way of creating a secret for Flux to consume like this)? I'm trying to avoid SOPS and solely use OpenBao for everything, although this is making me consider using SOPS for just this one secret.
Thanks!

Edit: Also looking into just using Vault instead of OpenBao since they still maintain their secrets-operator, was just hoping for an OpenBao solution

[NeuronButter]

Couldn't think of a workaround so just using Vault's secret operator with Vault. Would be cool to see Flux support this kind of thing in the future for other CSI drivers that work similarly too though :)

[stefanprodan]

A CSI driver works in the context of a pod, it would be so wasteful for Flux to create pods in the cluster just to make some secrets available. All Flux custom resources can refer to existing secrets in etcd, you can either use SOPS and keep the master key in Vault, or you can use SOPS directly with Vault, or you can use external-secrets controllers to sync secrets from Vault into etcd.

[NeuronButter]

Ah didn't realise the external-secrets controller could sync Vault -> etcd. I was more thinking about attaching CSI to the notification-controller Pod but suspected that manual changes to Flux objects wouldn't play well in the long run.