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
- Easily be able to identify what the secret unlocks
- Easily find all the secrets for a specific service
- Be able to revoke or rotate secret from a single location (so everyone/thing using the secret gets updated at once)
- Determine who is responsible for maintaining the secret
- Easily determine all the secrets that a specific person/system has access to
- Easily determine all the people/systems that have access to a specific secret (reverse of above)
- Minimize the amount of overly granular policies.
Usage Examples
- Manage Azure secrets such as storage account keys, VM credentials, service principal secrets, SSH keys, etc…
- Database accounts managed by DBA team (not ready for dynamic db secrets engine yet)
- API Keys for 3rd party services
- 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.