Is there a way to allow injection of secrets based on what a role has access to instead of giving a set of keys?
The system I’m working on has a large amount of interdependency between services. This means there are quite a few places where I wish to share the same key to multiple services.
Currently our keys are organised into this type of structure:
apps/app-a/secrets
apps/app-b/secrets
apps/app-c/secrets
Which makes the annotation configuration for the agent simple:
vault.hashicorp.com/agent-inject-secret-envvars: apps/app-a/secrets
However, this means duplicating secrets that multiple services need across different keys, which is brittle.
Instead I’d like to organise things like so:
concept/app-a-readonly/secrets
concept/app-c-write/secrets
apps/app-a/secrets
apps/app-b/secrets
apps/app-c/secrets
concept/app-a-readonly/secrets would be made accessible to the role assigned to app-a and app-b. This would allow app-a to permission the API key, and app-b use the same key.
However, this then duplicates things in the annotation configuration for the agent:
vault.hashicorp.com/agent-inject-secret-app-a: apps/app-a/secrets
vault.hashicorp.com/agent-inject-secret-concept-app-a-readonly: concept/app-a-readonly/secrets
# along with the required templates
This feels like it should be unnecessary as the policies on vault will already have been configured to show what secrets are available to app-a.
Instead I’d love to be able to do something like:
vault.hashicorp.com/agent-inject-secret-envvars: role/app-a
And have all of the secrets templated that are readable from that role. This would allow it to act transparently and not require updating when new secrets are added (instead only a change to the policy for an app).
Is there a way to do this currently? Am I missing a better way to organise things?