Agent Sidecar Injector based around role as opposed to key

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:


Which makes the annotation configuration for the agent simple: 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 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: apps/app-a/secrets 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: 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?