Organizing KV Secrets Engine

I’m looking for advice on how to organize our KV secrets to help meet our goals and minimize the amount of overly granular policies we need to define.

Goals

  1. Easily be able to identify what the secret unlocks
  2. Easily find all the secrets for a specific service
  3. Be able to revoke or rotate secret from a single location (so everyone/thing using the secret gets updated at once)
  4. Determine who is responsible for maintaining the secret
  5. Easily determine all the secrets that a specific person/system has access to
  6. Easily determine all the people/systems that have access to a specific secret (reverse of above)
  7. Minimize the amount of overly granular policies.

Usage Examples

  1. Manage Azure secrets such as storage account keys, VM credentials, service principal secrets, SSH keys, etc…
  2. Database accounts managed by DBA team (not ready for dynamic db secrets engine yet)
  3. API Keys for 3rd party services
  4. Application/Service specific secrets such as admin or service account credentials

It seems that satisfying one goal makes it hard to satisfy another goal. For example, accomplishing goal #3 makes it harder to accomplish #5 (at least from what I know about the system).

Current Structure
We are currently leaning towards using the following structure, /<service>/<sub-groupings>/<secret>. For example, /bitbucket/<workspace>/ssh-key or /azure/<resource-group>/storage-account-key.

Where this becomes difficult to manage is when we have multiple teams that need access to a specific secret within the same service sub-group. Using the bitbucket example from above, we would have ssh-key1 needed by team1 and ssh-key2 needed by team2 and ssh-key3 needed by team3 and team4. This is all possible to do with the above structure but it seems like we’d end up with a set of policies for almost every secret.