Manage access control by tagging of secrets

[FeKoerner]

Is your feature request related to a problem? Please describe. In the current state every access change has to be made from an administrator by changing the matching policy.

Describe the solution you'd like The goal is to make this more flexible and to empower the creator of a secret to share it on their own. This would solve the bottleneck of the administration.

I would like to introduce taging at secrets. Here is an example:

CorpFoo concist out of the following teams:

• HR
• Development
• Operations
• Security

CorpFoo uses a simple vault setup with only one key value store under the path secret. Every team has a folder under this path with secrets.

• secret/
  • development/
  • operations/
  • security/

Development creates a secret with the name newyork. Development knows, that Operations need read access to the secret newyork.

• Current situation: Development requests a policy change for newyork. Development has to wait for fulfillment throw administration.
• New feature: Development adds a tag operations to the secret newyork. tags can contain a set of items, which can be groups or entities

Possible realization:

• adding a parameter tags to the metadata of a secret
• tags can only be changed by entities, which have the capability create or update at the path of the secret

  ====== Metadata ======
  Key              Value  
  ---              -----  
  created_time     2021-03-17T10:52:00.708520221Z
  deletion_time    n/a
  destroyed        false
  version          2
  tags             operations, alice, bob
  ==== Data ====
  Key     Value
  ---     -----
  pass    1234

Describe alternatives you've considered Extending regular expressions of policies

[sgmiller]

Have you considered structuring your secrets path by consumer (eg operations) rather than producer? Giving the development team write but not read to a path that operations has read but not write is a common pattern.

[yahesh]

This would be an awesome feature. Structuring secrets paths by consumer leads to either duplicate data (if each consumer group gets their own path) or to a cluttering of secrets paths (if each combination of consumers get their own path). There currently does not seem to be a simple yet efficient way to do this.