Add Vault Pillar/SDB Module

[arnisoph]

Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing. Vault presents a unified API to access multiple backends: HSMs, AWS IAM, SQL databases, raw key/value, and more.

• https://vaultproject.io/
• https://docs.saltstack.com/en/latest/topics/sdb/
  External Pillar for encrypted repositories #11147
  Managing secrets / secure data with Saltstack in a bigger team #26236

[jfindlay]

@bechtoldt, thanks for the report.

[techhat]

@bechtoldt that sounds fantastic!

[eedgar]

@bechtoldt do you have any implementation ideas for this?

[eedgar]

https://github.com/ianunruh/hvac

[arnisoph]

@eedgar Nope, I haven't planned to provide a patch so far.

[eedgar]

I did a little research and there are a few problems with the sdb implementation that make this challenging. currently sdb allows for module/key where modules are defined inside the minion or master config. this does not allow you to specify the full path within the vault very easily .. eg myvault/secret/hello ... sdb would only pass secret to the vault module and loose the hello parameter. Additionally vault secrets can store more than one key value pair inside them .. How can we support which one to retrieve. I think this functionality would be better served creating a vault module with read and write methods.

then use them inside a jinja template like this. {{ salt.vault.read('myvault/secret/hello', key='value1') }}
key can be an optional parameter.

[techhat]

SDB is designed to be simple to call; long URIs defeat the purpose. The intent is that an sdb:// URI would be just enough to refer to a profile configuration which can be much more complex, if necessary.

My suggestion here would be to implement full paths inside the profile, not the URI. Think of the profiles like stored procedures, rather than just connection parameters.

[eedgar]

the only thing I was thinking was that the number of profiles could get to be quite numerous depending on the number of paths you need to traverse. I think a more feature complete vault module is the way to go here. maybe implement a subset of that for sdb if the demand is there.

[eedgar]

eg think dynamic paths such as /secret/server1/auth /secret/aws_domain1/credentials /secret/aws_domain2/credentials .. these things can add up fast.

[DanyC97]

@eedgar have you made any progress on it or you hit a dead end with the sdb? (asking as i'm trying to do the same thing but i'm a bit limited by the options )

[jbussdieker]

+1 for a vault module

[coen-hyde]

I hate to just add another +1, but this would be good.

[ketzacoatl]

Would there be interest in a modules implementation that is not using SDB?

If only as a first pass, I believe it would be more valuable to get this working in a simple form, and leave the SDB interface questions for a later date. The simplest form I can see would have a vault module that could get a key, similar to pillar.get, and which could be used in a template like:

{%- set my_secret = salt['vault.get']('path/to/key') %}
{{ my_secret }}

This could also keep it simple (on first pass), by using VAULT_TOKEN from the environment.

EDIT: to implement this as a pillar module would put the secrets in the salt log (right?)

[dmangot]

@ketzacoatl I had always envisioned vault as just another pillar back end (like hiera, mysql, s3, etc.) so I'm interested whether it's implemented using SDB or not.

[techhat]

A pillar or execution module would be awesome.

[ketzacoatl]

An execution module means the secrets don't inadvertently end up in the salt log, but a pillar module means users can make use of this more seamlessly (retain loose coupling with salt formula).. but maybe the pillar module could use the execution module, so that both are available?

One thing I am not sure of is how you would retrieve all child keys from a parent path in Vault. I will look into that.

If that sounds good, I would be willing to take a first pass on this. I would use https://github.com/ianunruh/hvac, and keep authentication bare-minimum (use token to start).

[tspecht]

Any progress on this? Would be awesome if we could get vault as a pillar backend for Salt!

[ketzacoatl]

@tspecht, I have it on my todo list, but I have not started on it. I hope to do so in the next week or two. Anyone else is welcome to as well, I'm not looking to block, I am just interested in meeting this need but also tied up at the moment.

[thatch45]

@techhat would be the best one to implement this one, but if you start before he does @ketzacoatl let us know. I will slate this for the Carbon release, since the boron release has been frozen

[ketzacoatl]

@carlpett, to put in voice in for those with ultra-simplified (or non-existent) salt-masters - I generally run consul + salt-call in a way that avoids the HA burdens for a salt-master. While I like the architectural options available with salt-minions retrieving temp tokens from vault, through their salt-master, a solution that explicitly requires the salt-master can be problematic, and where possible, I like to advocate for the minion retaining the same capabilities. FWIW.

[carlpett]

@ketzacoatl Interesting point, had not thought of that one. The issue with that is how to manage what the minions can read? Configuring all the minions with a Vault root token would sort of default the point of using Vault? If the machine is compromised, it is capable of reading or altering anything within Vault, and even locking everyone else out.

Do you agree, or am I missing something? Is there a benefit of using Vault over just having the credentials in pillar?

[ketzacoatl]

@carlpett, well, with ACLs, you are not required to use a root token - https://www.vaultproject.io/docs/concepts/tokens.html.

[carlpett]

@ketzacoatl Yes, but non-root tokens expire, though, so you'll need to have a system that renews them periodically (you can do mount-tunes to make the expiry time longer, but still something to be aware of). And it might be a pain to manually generate all those tokens with the correct policies.

But if this is a common thing, I could add some support for setting the token in the minion config as well, instead of going to the master, shouldn't be very complicated. I probably wouldn't recommend using it to anyone, though.

[carlpett]

@ketzacoatl I just pushed a branch for masterless, care to have a look if it looks like it would fill you requirements? https://github.com/carlpett/salt-vault/tree/f/masterless

[ketzacoatl]

@carlpett, It's a tiny bit difficult for me to see the details (not sure if that's end of week or something else). Maybe you can add a short doc example for how that would be used with the minion or salt-call?

[carlpett]

@ketzacoatl Sorry about that. I've updated the README (last section) with instructions for masterless.

[ketzacoatl]

LGTM, thanks for all your work on this!

[eliasp]

is there a good way to share code between state and execution modules?

@carlpett You might want to move common code to a utils module…

[carlpett]

@eliasp That sounds like just the thing :) Does that work for modules that are not distributed along with salt itself, though? Inhouse, we add our custom modules by adding their git-repos as gitfs_remotes; but this may not be the best way to do it?

[carlpett]

@techhat Since I took my time in getting this ready and you built a module in the meantime, what are the plans for this issue?

[techhat]

@carlpett, I don't mind my code being replaced with superior code.

[eliasp]

@carlpett The best way to distribute custom modules (including utils) is to use Dynamic Module Distribution.
For this reason I maintain a local salt-dynmods repo containing the corresponding module directories.

Although it's not perfect yet (#24488), it's quite useful for distributing newer or development versions of specific modules.

[carlpett]

@eliasp Aha, didn't know about _utils. I had already put the state, exec and runners in underscored directories. I'll extract the shared logic to _utils then.

[carlpett]

Took quite some time again between work and refactoring to get _utils to work, but I've pushed the changes now. What's the process of getting it into "mainline salt"? Just create a PR?

[DanyC97]

@carlpett yes

[ahammond]

+1 for anything which allows me to use decentralized vault as an alternative to pillars for secrets management.

[carlpett]

Sorry - I totally forgot to create the PR for this. Got stuck with some linting problem or similar. I'll try to get it done during the weekend!

[mchugh19]

@carlpett Has there been an update? Is your module releasable?

[carlpett]

@mchugh19 Wow, good reminder... Sorry about being so slow. We've been using it internally for over half a year without any problems, so I guess so. With 2016.11 having support for utils-syncing on the master it should actually be pretty simple to just add it as another file_root (or gitfs remote, that is what we are doing). For 2016.3 you need to do a manual copy of the util to the master's extmod, which is a bit of a bother.

Anyway, it would be better to get it into the distribution. I'll give it a go and hope I can finish it up this time.

[carlpett]

@mchugh19 As an update, I've merged the code into a branch on the main saltstack repo now, and removed the majority of linting issues. I'm still working on minimizing the breakage from the existing code, hopefully I can finalize it tomorrow.

[carlpett]

This has now been merged, a year later. There were a few fixes on the separate repo just the last days, which I'll port over in a separate PR.
But I think this issue can be closed now?