vault-csi-provider VS vault-creds

Why not use https://github.com/kubernetes-sigs/secrets-store-csi-driver to do this? Then you don't have a strict binding to runc. A live example of using the CSI driver with a secrets provider is https://github.com/hashicorp/vault-csi-provider

Exactly, we hide this from our devs. They can add secrets to hc vault via ui or via cli and know the „keywords“ to render it to properties. Which we then provide via env vars or properties file to app. For databases we do the same, there we use https://github.com/uswitch/vault-creds which hides the database related things. For encrypted communication we used in the past a sidecar with envoy that simply took certs from vault and in our apps we added the pki ca we managed via vault. So this was also hidden and devs not had to take care of encryption in their apps (today you use a service mesh for it) ;) and especially were also not affected by expired certs, as envoy has hot reload. For Kafka we still use this mechanism to implement authn and authz. There we have a callback which rotates pods when Kafka keystone is near expiry date. The only thing our devs have to worry about is encryption as a service. There I found so far no abstraction.