Conventions for path hierarchy

[Nicholas Chammas]

Are there any emerging patterns for how people structure their Vault path hierarchy? Why do you follow the pattern that you use?

I’m just starting to use Vault and am wondering how best to structure my secrets.

I’ve considered the following two patterns:

schema: service/host/[scope/]user

examples:
 - postgres/host1.internal/db1/batch_user
 - postgres/host2.internal/db1/nick
 - ftp/ftp-host.internal/ftp_user
 - posix/posix-host1.internal/root

In the above pattern, things are roughly organized in a network hierarchy. This just seems intuitive to me, but perhaps others feel the same way too.

schema: friendly-name/user

examples:
 - production-db/batch_user
 - dev-db/nick
 - stock-prices-ftp/ftp_user
 - monitoring/root

In this pattern, every access point just gets a friendly name and then the user. The friendly name could refer to a database, FTP, or anything really. You’d query the details of how to access a given resource by looking up the same friendly name in a configuration service like Consul.

Do you use either of these patterns for organizing your secrets, or perhaps something else? More importantly, why do you use the pattern that you use?

I’m just starting out with Vault, so I don’t have the experience of using it with hundreds of resources over many months to know what is gonna work better.

Nick

​

[Clay Bowen]

I would suggest that you determine what is important to you (based on your use cases), like "shorter paths" or "fewer items".  Consider the back end -- does it have any limitations that will affect your architecture?  Draw up an architecture diagram (tree diagram) and examine it -- imagine what it will look like when 10,000 values are stored.  How will you manage it?  How will you support it?  Consider every foolish thing a person has ever done to one of your systems and think about how you'd fix it or prevent it.

Every person will have their own answers for these questions/situations so it's tough to recommend a particular solution.  If you have more specific questions, though...

Thanks,

Clay

[Nicholas Chammas]

Thanks Clay. That’s a good mental exercise to go through to test out any proposed schema: What will I think of this schema when it’s pushed to the limit?

As a good as an exercise as that is, however, my mental abilities are limited. I’d prefer to complement any mental design exercise I do with examples from people who have had experience using Vault.

Every person will have their own answers for these questions/situations so it’s tough to recommend a particular solution. If you have more specific questions, though…

Let me rephrase my original question, in case it helps elicit some examples from people: I’m not asking for a recommendation for what I should do. :) I’m asking what others have done and why it worked for them. It may or may not apply in my case, but I can determine that on my own. The examples that people share, however, can be useful as a resource that Vault newbies can review when first getting up to speed. Does that make sense?

[Clay Bowen]

OK.  In my case I wrote a program that allows users to store, retrieve, remove, and list information to Vault.  It's all based on their LDAP credentials (which means I don't have to store a lot of auth values in my structure).  The first time a user logs in, the program creates a path for them on "secret/usr/<ADNAME>" and creates and assigns a template allowing them to access that area.  The policy is also named for their Active Directory Login name (ADNAME).

Whenever a value is stored under a key name they provide (this can be a text string or a file), the key name is added to an index at "secret/usr/ADNAME".  This allows me to provide to them a list of the keys they've stored (but not the value).  Likewise, when they remove a key the name is also removed from the index.

In my case, therefore, much of my data is being stored in the generic backend under "secret/usr" in a very flat configuration.

Thanks,

Clay

[Jeff Mitchell]

Just to chime in:

If you're just starting out, I wouldn't set anything up to generate
indexes as Clay has done. Vault 0.5 will have list support for the
generic and cubbyhole backends.

--Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/71a5ec20-763c-4e1b-b6f6-c03080114837%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Nathan Basanese]

Nicholas, this is an "oldie but a goodie." Excellent question for discussion. 

You might end up seeing "emerging patterns" of security models, not Vault paths, though.

I think to be able to see any kind of emerging patterns could lead us astray, because of the following: 

1. Some patterns will be underreported, some overreported, because some will choose a path naming convention that reveals more sensitive info than others will, often for pretty good reasons (ahem)

2. Antipatterns are difficult to see without context, context that people posting on a public forum are unlikely to reveal. See #1.

3. It may be difficult to tell how much of the "emerging pattern" is due to choices that generalize to other use cases, and how much of it is due to how common a specific application or security model is.

That said, I've pored over the source code and documents for you, and this is what I've found so far on the internet for Path Open-Ended Guidelines: 

Paths are open ended. The HashiCorp docs say that we "should decide on the naming convention that makes most sense". 

The workflow for a path naming convention probably looks like the diagram below, except that you only get to do it once or twice, at the start of setting up Vault.

Replace the word "policy" with "path naming convention":

That said, what makes sense is likely a combination of design to invariants (paths should change less), and the fact that the path & key names should not reveal especially sensitive information.

1. Keep it consistent, to avoid creating unnecessary complexity and security hazards. Policies are designed for more frequent change.
2. Keep it simple. Avoid high depth in your path names, and aim for a flat hierarchy. Paths should not go more than 2 or 3 deep. 
3. Paths are for quick lookup. Match Topology, stay the same.
4. Policies are for access segregation. Match security concerns and security model, change as frequently as access changes.
5. Policies can have more complexity than Paths. If you have a choice between putting complexity in a Vault Policy or in a Vault Path, I'm biased toward recommending to put it in a Vault Policy. For example, policies that allow access to multiple specific paths would be preferable to simpler policies that allow access to 1 path, but require secrets to go in multiple places or have a higher path depth. Policies allow more fine grained control anyway. Rather than using paths for different teams, separate teams, roles, users, groups, and other items, use policies across secrets for these, to avoid a situation where you're tempted to symlink secrets. E.g. IMO, all other things being equal, giving a complex team1policy.hcl policy access to a shallow-depth secrets/db/a_mysqlpass may be better than giving a simple team1policy.hcl access to path  secrets/team1/db/a_mysqlpass. However, this is just a trivial example. Actual use will all depend on the security model and how the organization changes who has access to what.

Looks like what you want to avoid is a situation where you need to change access or identity stuff, and are thereby required to change paths because of it.

Path Examples: 

Example path names (Used by examples in HashiCorp docs)

secret/dev/config/mongodb

Example naming conventions (Used by examples in HashiCorp docs)

secret/<OWNER>/apikey/<APP> for API keys

secret/eng/apikey/Google

secret/<ENVIRONMENT>/cert/<SYSTEM>

To store the root certificate for production MySQL, the path becomes


secret/prod/cert/mysql

To store the root certificate for Staging PostGRES, the path becomes

secret/staging/cert/postgres


Example naming convention (made up)

secret/<PRODUCT>/<ENVIRONMENT>/<TYPE>/<SYSTEM>

Where type is something like apikey or cert

secret/cart/dev/apikey/Azure

Example path names (Made up)

secret/db/mysql

secret/db/mysql/pass

secret/team1/db/mysql

secret/product/

secret/cart

Example naming convention (Used by PIPES)

secret/db/<project>/<secretnames>

secret/<project>/<secretnames>

Example naming convention (Used by Infinum)

#<technology>/#<git_repo_name>/#<environment>

rails/#<git_repo_name>/#<environment>

rails/awesome-app/#<environment>

rails/awesome-app/production

Paths for lookup (what, where), policies for access (who, when, how, why... which?)

I kind of said the same thing over and over by paraphrasing. 

Anyway, would any of you read a blog post on this?

[Nicholas Chammas]

Thank you for sharing this Nathan. It’s a great read, and I think many new Vault users trying to consciously design a path scheme would be interested in reading what you wrote here. Point 5 and the examples at the very end are especially helpful.

2018년 6월 11일 (월) 오후 2:09, Nathan Basanese <nbas...@gmail.com>님이 작성:

You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/poPIzKtDOEY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/db480101-401b-42b7-a274-a3f36858f9f2%40googlegroups.com.