This content originally appeared on Level Up Coding - Medium and was authored by Sarvsav Sharma
One of the solution to organize your secrets store path in vault.
NOTE: No subscription? No problem. You can access the friend link here. :) You can also access all my friend links on my GitHub repo: Friend-Links.
Articles in the series:
[Vault] Introduction to Hashicorp Vault
[Vault] Unseal your Hashicorp vault manually and using cloud key store azure
Problem statement?
How to handle the complex problem of secrets organization (designing the path for storing secrets) and applying policies to it without losing the traceability and accountability.
Solution
We will solve this problem by thinking our infrastructure in terms of coordinate systems. We will define the axes so that we will never end up in corner cases, and can extend it without any complexities. And, the path tells what service it unlocks, instead what service is going to use that credentials.
For example, if I have path starting with name jenkins, it means that it unlocks the credentials to jenkins, and it should not contain the credentials used inside the jenkins eco-system, for example the passwords stored in manage credentials settings of jenkins.
This approach will maintain the balance, uniqueness, future proofing and usability. Let’s break down into multiple steps for easy explanation.
Step 1: Identifying the axes
To start with, we will first identify how can we define our naming axes. For example, in a basic coordinate 3d systems, we have x y and z axis. Their values can be infinite. One more example, we have a graph that represents date on x-axis and time on y-axis.
With same inspiration, we will name our vault secret stores path in axes system that contains information about our infrastructure in form of coordinates.
Consider, you are developing a secrets store path for your product, that can consists of multi cloud system, bare metal machines, multiple departments, multiple user authentication methods, different databases, and all the complex stuff. To handle the secrets store path, let’s simplify it by breaking them into axes.
Naming the axes:
1. Cloud provider can be one axes as we can have values like gcp, aws, azure, oci on it.
2. Account/Subscription/Project id can be another axis.
3. Region or Location will come as next.
4. Environment will also define an axis.
5. Service, resource type running in the environment will be next axis.
6. Resource instance as another axis.
7. Secret type and secret version.
Step 2: Apply axes to our secret store path
Now, as we have defined the axes, we can arrange them and make a canonical naming for our path. So, that it can be used as a standardize path in our system.
Instead of thinking like this:
/azure/<resource-group>/<resource-name>/storage-account-key
use the below format:
/<provider>/<account>/<region>/<env>/<service>/<resource>/<secret-type>/<variant>
Let’s try to understand with some examples.
Suppose we have to store Github SSH keys for multiple users.
For example, CI bot user:
/github/my-organization/prod/workspace1/ssh/ci-bot
Now, let there is a similar user in your-org too, and it is just another coordinate, and we can simply add like this
/github/your-organization/prod/workspace1/ssh/ci-bot
You can also narrow down to different teams also. Let’s get some inspiration from arrowverse:
- Ops & Performance → Speedsters (The flash, reverse flash)
- Cybersecurity & Red Teams → Vigilantes & Rogues (Green Arrow, Deathstroke)
- AI/ML & R&D → Thinkers, Cisco, Felicity, Curtis (The Thinker, Overwatch)
- Infra & Cloud → Supergirl, Superman, Firestorm, Killer Frost
- Timeline/PMO → Sara
- UX/Engagement → Tricksters
- Risk/Compliance → Batwoman
And, imagine they have ssh keys on vault, then it can be easily added like this:
/github/cw/prod/arrowverse/ssh/cyber-security/green-arrow
/github/cw/prod/arrowverse/ssh/ops-and-performance/the-flash
/github/cw/prod/arrowverse/ssh/ops-and-performance/reverse-flash
/github/cw/prod/arrowverse/ssh/ai-and-ml/the-thinker
and, in a same way all the users can be added.
Step 3: Mapping policy to axes
We can directly apply policies to the axes. For example, it could be,
- per team policy
path "/github/cw/prod/arrowverse/ssh/cyber-security" { capabilities = ["read"] }per service policy, or
per cross service policy.
Step 4: Future proof about naming
If any of the below questions, answer into that we’d have to rename everything., then there is a missing axis.
- What if we added another region/account/provider?
- What if a resource has multiple keys/passwords?
- What if multiple consumers need different access levels?
- What if a team spans multiple services?
Step 5: Metadata
Never forget to add metadata, as it still helps.
# Metadata
owner=teamX
rotation=30d
consumers=serviceA, teamB
sensitivity=high/medium/low
As a next step, let’s prepare a decision tree, that helps us for naming future secrets store paths.
Q1. What system does this secret unlock? (It sets the provider axis)
Q2. Which account / subscription / project / tenant is it under? (sets `account` axis)
Q3. Is it a region specific?
Q4. What kind of environment is it for?
Q5. What service or resource type is this?
Q6. What is the specific resource name / instance?
Q7. What type of secret is it?
Q8. Does this secret have multiple variants?
Tabular structure for easy visualization.
Summary:
- Use coordinate systems for your secrets store path.
- It tell what service it unlocks, instead which service is going to use that credentials.
There is go code also available, if you would like to use:
https://gist.github.com/sarvsav/ce7bd63d2beb2a71e32f4c480b917767
Unlock the Magic of Knowledge — Follow & Subscribe to stay updated! 💌
You can also become a part of our WhatsApp community (focused on Go and Web Development) by scanning below QR code.
WhatsApp Channel: codingtherightway
Shower your love ❤
Clap guide in summary:
1–2 Claps — An average article
3–10 Claps — Very good article
11–20 Claps — Very helpful and value addition
21+ Claps — Supporting your efforts :)
Thank you for reading.
[Vault] Naming practices for Vault Secret Store path was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Sarvsav Sharma
Sarvsav Sharma | Sciencx (2025-09-03T15:03:28+00:00) [Vault] Naming practices for Vault Secret Store path. Retrieved from https://www.scien.cx/2025/09/03/vault-naming-practices-for-vault-secret-store-path/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.