what is the best way to hide passwords?

[Ming Fang]

What is the best way to avoid putting passwords in sls and roster files?
Take this example http://docs.saltstack.com/ref/states/all/salt.states.mysql_user.html
I don’t want to have password: bobcat in sls.

Are Pillars the solution? http://docs.saltstack.com/topics/tutorials/pillar.html
So for this example it would be
password: {{pillar[‘mypassword’]}}

[Tim O'Guin]

Yes, pillars are the way to go. This ensures that only the minions that match the pillar targeting rules will get the sensitive data. Unlike states, pillar data doesn't get sent to all minions.

I'm unsure of how it might work with the roster though, as I haven't used salt-ssh yet.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ming Fang]

Thanks Tim.

My concern with putting passwords in Pillars is that if I run salt pillar.items then all the passwords will be reveal to anyone using a tool like Halite.

Think it would be nice if there is a way to mark a piece of data as sensitive data and then all display of that data will be obfuscated somehow.

In other words, sensitive data would only be available to the minion in memory, but not visible as clear text in transport or logs or Halite.

Does this qualify as a feature request?

[Tim O'Guin]

Well, the master always needs to be able to read the pillar data. I'd imagine the way to deal with your issue would be to define the client_acl so that only the user that salt runs as can call the pillar.* modules. As long as your users have their own accounts they're signing into Halite with (or calling salt via the CLI with), you should be able to restrict their access.

http://docs.saltstack.com/ref/clientacl.html

[Daniel Dehennin]

"Tim O'Guin" <timo...@gmail.com> writes:

> Well, the master always needs to be able to read the pillar data. I'd
> imagine the way to deal with your issue would be to define the client_acl
> so that only the user that salt runs as can call the pillar.* modules. As
> long as your users have their own accounts they're signing into Halite with
> (or calling salt via the CLI with), you should be able to restrict their
> access.

I first ask on IRC but forresta point me here, so I expose my probably
insane idea to everyone ;-)

What about some kind of password generator mechanism?

I want to say “my application need a MySQL user named "foo" with a
password”.

Then the minion running my application will start some kind of
Diffie-Hellman with the minion managing the MySQL, though master to
authenticate the dialog.

No one need to know the password, not even the master.

This should be renewable:

- if passwords on MySQL client and server are out of synch
- when someone ask
- on a time based, for example change password every month

I'm not a crypto guy but found some infos about n-party Diffie-Hellman
exchange[1].

What do you think about this?

Footnotes:
[1] http://crypto.stackexchange.com/questions/1025/can-one-generalize-the-diffie-hellman-key-exchange-to-three-or-more-parties

--
Daniel Dehennin
Récupérer ma clef GPG:
gpg --keyserver pgp.mit.edu --recv-keys 0x7A6FE2DF

[Daniel Dehennin]

Daniel Dehennin <daniel....@baby-gnu.org> writes:


[...]

> What about some kind of password generator mechanism?
>
> I want to say “my application need a MySQL user named "foo" with a
> password”.
>
> Then the minion running my application will start some kind of
> Diffie-Hellman with the minion managing the MySQL, though master to
> authenticate the dialog.
>
> No one need to know the password, not even the master.

[...]

Thinking about it under my shower, I forgot to mention that the
generated password should be store in a non-shared local to minion
private pillar storage.

Regards.