Vault: a backend that generates random passwords.

[eedgar]

I would like a backend that generates random passwords for servers.
My thought would be along these lines.

have a password secret backend. allow some sort of parameters such as password length, number of special characters required etc so that the admin can configure this to meet company policy regarding password complexity.

then I would have a mount such as /serverfarm_root_password and then read
/serverfarm_root_password/server1/root the first time the password is read it is generated.

My plan would be to use tools like chef/puppet/salt to then set this password on the server. This way each server gets a unique password. Appropriate individuals can access vault if they need the password. If I want to roll a new password just delete the key and use the automation to push new passwords out.

[jefferai]

I think some existing Vault functionality could probably meet this need -- especially considering that you are setting this password on servers and having uses fetch them if needed, rather than having users remember them.

Take a look at https://vaultproject.io/docs/secrets/transit/index.html and specifically the datakey support, which was added in 0.3. You can use this to generate cryptographically strong passwords (as in, they are high-quality random bits of various lengths, and hex- or base64-encoded this is a high-quality password)

You could then distribute the encrypted (wrapped) version of this key to your servers and individuals, or store that value in a generic mount, and allow access to decrypt the passwords based on policies held by your users' tokens.

Regarding company complexity requirements, passwords for users usually have to meet requirements because humans have to remember them. If they don't need to remember them, a high quality random set of bytes is as random as any other password (think about how easy it is to choose strong passwords when using LastPass or 1Password so you don't have to remember them yourself). Most security departments would probably be happier with this kind of generation than any arbitrary set of character rules.

Hope that helps!

[eedgar]

Jefferai,

I see what your saying. I was just hoping I wouldnt have to write code to manage all of this. for me a simple call from the automation into vault is sufficient here. eg

set_password
vault: {{ read('/password/server1/root') }}

no other backend process is required to manipulate the things. I think others would find something like this as a valuable addition. Maybe I am wrong here, but the simpler I can make password management the easier I can get buy in for things like this.

Eric

[eedgar]

13:56 < rocket> so my idea is this.  and I have been working on an integration with saltstack if that helps
          understand
13:56 < rocket> the server joins salt with a unique hostname
13:57 < jefferai> OK
13:57 < rocket> I am using a pillar to set the root password
13:57 < jefferai> OK
13:57 < rocket> {{ vault.read('/password/<server_id>/root') }}
13:57 < rocket> the first time that I read it the password will be generated in the backend
13:58 < zirpu> unique hostname like /proc/sys/kernel/random/boot_id ?
13:58 < jefferai> rocket: OK -- I see what you're trying to do now
13:58 < rocket> something like that .. basically its up to you to set the hostnames
13:59 < rocket> that way each of my servers will have a random root password
14:00 < rocket> ideally I never need to know that password but its there in case of emergency etc
14:00 -|- pbpolar [uid12070@gateway/web/irccloud.com/x-nbsnvfmabsfhhudv] has quit [Quit: Connection closed for
          inactivity]
14:01 < rocket> so I was thinking that sometimes companies do force their employees to set certain types of
          passwords.  this password plugin could also use those rules if you have to follow them
14:02 < rocket> create a new mountpoint for various rules you have to follow
14:02 < rocket> and/or use policy to define what employees can see which passwords as well

[careyblack]

Another option solve this issue might be to use the SSH Secret Backend(http://vaultproject.io/docs/secrets/ssh/index.html) It actually looks like it is specifically designed for just this use case. :)

Basically you don't need to know the root password. You get access to it when you need it vai an audited event through your vault. ( specifically thinking about the "One-Time-Password (OTP) Type" option, but if this is really only for emergencies, then you _might_ opt for the "II. Dynamic Key Type" path. )

Either way you would be giving your vault root control of all of your hosts. You are doing that if you are storing root passwords. Maybe "less actively", but your doing it all the same.

[skyzyx]

:+1:

[jippi]

:+1:

[wmangano]

👍

[norpol]

Hi there, I'm evaluating if vault-project is fulfilling my needs for a project. For this I'm using a common provisioning tool and I'd love to see the requested feature implemented.
Right now I'm generating passphrases via. yaml/jinja2 like {{ pwgen(length=50, OnlySmallCase=True) }} in a custom script and store them in a vault.

@jefferai commented on Oct 8, 2015:
Regarding company complexity requirements, passwords for users usually have to meet requirements because humans have to remember them.

Yes, this is true. But:
I think there is an additional point of that plenty of (old) software are still having mandatory passphrase requirements in length and allowed character-sets. This can be due clear-text storing, or other obscure reasons (input validations at the wrong end, broken hash algorithms, you name it).
So a :+1: from my side for optional less secure passphrases and a big banner in the documentation telling the people only to use it if really necessary.

Regarding implementation (just to get into their mindset). I can recommend reading the man-page for apg(1), especially the sections regarding -M (mode) and -E (Exclude characters).

Looking excitedly forward! :smile:

[norpol]

Kindly pinging this here again. Is there anyone who feels like giving a reply?

[jefferai]

@norpal what would you like in a reply? :-)

[norpol]

Hi @jefferai,
depends I guess it would be good to know if:

• under which circumstances the feature is considerable for vault (especially if the opinion on complexity filters changed)
• the feature is considered to be implemented at all / would merged if someone creates code
• for which vault release we could have this as earliest
• in which part of the code this should be implemented

I don't know if I'm capable of contributing something like this, especially since I'm a little scared of dealing with anything that has to do with the creation of credentials.

[jefferai]

Hi @norpol

under which circumstances the feature is considerable for vault (especially if the opinion on complexity filters changed)

Unknown currently

the feature is considered to be implemented at all / would merged if someone creates code

Unknown currently

for which vault release we could have this as earliest

No current plans

[otakup0pe]

We've added this to the tool we are using to provision secrets into vault https://github.com/autodesk/aomi - one of the "secret types" it supports is generated data. We've been keeping a pretty clean separation between "where the secrets live" and "what the secrets are"

[schulzh]

Let me add another use case:
We have multiple microservices communicating with basic-auth. They use vault to get all credentials they need (theirs and the ones to call) at startup.
Currently we just generate the credentials of the service we are deploying, but this is not ideal, as the service tries to fetch the other credentials immediately and does not start. If the service however does ignore the error and starts anyway, it will not have the secrets to call the other services (and would need to fetch them later/periodically). Since we don't know which service calls which other service at deploy time, it is not possible to create all needed secrets before deploying the service.
Now if the secrets would be generated on the first read, we would not need to create the secrets beforehand at all, essentially avoiding the problem altogether.

[meirish]

This was recently released as a vault plugin: https://github.com/sethvargo/vault-secrets-gen which I think would satisfy the use case.

[jefferai]

@meirish is right, closing!

[Garagoth]

Um, maybe I misread, but this plugin just generates new password every time, while there is a need to password be generated and stored on first secret READ, and consecutive READs will provide same password.
I am interested in this functionality as well.

[norpol]

Maybe create an issue @sethvargo's proejct repo, I suppose it would be possible to add this functionality to their project :+1:.

[sethvargo]

$ vault kv put secret/app/password value="$(vault read gen/password)"
$ vault kv get secret/app/password

You can then version the passwords too. I don't really see value in adding the "storing" functionality to the plugin since complicates the interface at the exchange of something that's already possible with Vault's generic KV store.

[Garagoth]

Yes, but it is not possible to use this two step process from for example
Consul template (which includes Nomad templates as well) - Consul template
can only query for secrets...

On Mon, May 14, 2018 at 4:59 PM, Seth Vargo [e-mail]
wrote:

$ vault kv put secret/app/password value="$(vault read gen/password)"
$ vault kv get secret/app/password

You can then version the passwords too. I don't really see value in adding
the "storing" functionality to the plugin since complicates the interface
at the exchange of something that's already possible with Vault's generic
KV store.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/vault/issues/683#issuecomment-388848142,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA36wYnpkajTruAET3dPcZUGk19lI1-Pks5tyZvAgaJpZM4GLd1J
.

[sethvargo]

Untested, but this is definitely possible with Consul Template:

{{ with secret "secret/app/password" }} 
{{ .value }}
{{ else }}
{{ with secret "gen/password" }}
{{ secret "secret/app/password" .password }}
{{ secret "secret/app/password" }}
{{ end }}
{{ end }}

[Garagoth]

I stand corrected. 8 lines instead of 3 lines, but should work.
Thanks!