[throw1230]

Because a security vulnerability in the common library will have a much larger impact. It also increases the potential attack surface by adding more components. Companies value the secrets they keep and want to make sure they have 100% vertical control, where they can audit everything.

Also, at any project with a sane architecture, you're using 1 vault and maybe 1-2 ambient strategies to pass the data. You won't use all the vaults at the same time anyway

[derefr]

> Also, at any project with a sane architecture, you're using 1 vault and maybe 1-2 ambient strategies to pass the data. You won't use all the vaults at the same time anyway

You're assuming the secrets here are managed by infra+glue added by a DevOps team when deploying an app.

I'm talking about use-cases where the secret-handling is designed into e.g. a cluster-scale deployable virtual appliance, where you configure the app through its UI or deployment-time config files to access your "secrets provider" of choice. (Think "deployable PaaS.")