It would be great to be able to combine multiple sources of secrets under same item.
I.e. manually created ones + automated ones from different components/modules.
Since there is no access control granularity past vault-level - there is no security downside to this.
However from UX standpoint - this has a benefit of keeping everything in one place vs needing to spam an item per individual piece of automation code + anything manual you'd have to add on top.
Use cases
PostgreSQL users/urls, multiple levels of grafana tokens (cloud/stack), secrets for a single app that comes from multiple sources (db, cdn, deploy keys, buckets, metrics/logs/traces publisher keys).
If you use something like terragrunt or magic python wrapper - you get separately scoped component for each service. (to reduce graph size, apply different concurrency or run less in CI/CD.. etc)
Proposed solution
Have dedicated section/item resource. Possibly needing a "custom composite" item type that supports this.
Is there a workaround to accomplish this today?
Hint of a workaround is to use ignore_changes+protect_from_destroy for manual secrets, but still does not handle multiple sources. Also, other code having to ignore things it should not know about is a scope leak.
Summary
It would be great to be able to combine multiple sources of secrets under same item. I.e. manually created ones + automated ones from different components/modules. Since there is no access control granularity past vault-level - there is no security downside to this. However from UX standpoint - this has a benefit of keeping everything in one place vs needing to spam an item per individual piece of automation code + anything manual you'd have to add on top.
Use cases
PostgreSQL users/urls, multiple levels of grafana tokens (cloud/stack), secrets for a single app that comes from multiple sources (db, cdn, deploy keys, buckets, metrics/logs/traces publisher keys). If you use something like terragrunt or magic python wrapper - you get separately scoped component for each service. (to reduce graph size, apply different concurrency or run less in CI/CD.. etc)
Proposed solution
Have dedicated section/item resource. Possibly needing a "custom composite" item type that supports this.
Is there a workaround to accomplish this today?
Hint of a workaround is to use ignore_changes+protect_from_destroy for manual secrets, but still does not handle multiple sources. Also, other code having to ignore things it should not know about is a scope leak.