Why are all the various "secrets vault" approaches so splintered and proprietary, anyway? Why is there a separate tool I have to install for:
• AWS secrets, GCP secrets, Azure secrets... each has its own API
• secrets in a HashiCorp Vault install
• secrets from whatever cloud password manager
• "ambient" secrets from env-vars, or the local .netrc, or the local macOS Keychain
• k8s Secrets resources (when you're a k8s CRD controller)
• secrets stored in SOPS files, in turn encrypted by keys held in any of the above
Why haven't we seen a generic "secrets client" library, with pluggable adapters for handling all of these cases through the same library API / CLI tooling?
Or better yet, why not a generic stub secrets client, that speaks to an also-generic "caching middleware proxy" like this AWS one — where the proxy has the pluggable backend adapters + connection config for them?
• AWS secrets, GCP secrets, Azure secrets... each has its own API
• secrets in a HashiCorp Vault install
• secrets from whatever cloud password manager
• "ambient" secrets from env-vars, or the local .netrc, or the local macOS Keychain
• k8s Secrets resources (when you're a k8s CRD controller)
• secrets stored in SOPS files, in turn encrypted by keys held in any of the above
Why haven't we seen a generic "secrets client" library, with pluggable adapters for handling all of these cases through the same library API / CLI tooling?
Or better yet, why not a generic stub secrets client, that speaks to an also-generic "caching middleware proxy" like this AWS one — where the proxy has the pluggable backend adapters + connection config for them?