Masking passwords in config file generation with Jinja

[Matt]

Hi all,
I'm generating multiple configuration files off of jinja templates. Most of them contain some type of passwords. If there is a change to a password, running my state file will display a diff with both the old and the new passwords in the output and logs. Is there a way to hide passwords from showing up in the logs?

Thanks,
Matt

[Colton Myers]

There's no way to only remove the passwords from the output. However, you can hide the diff altogether by adding `show_diff: False` to your file.managed state.

--
Colton Myers
Core Engineer, SaltStack
@basepi on Twitter/Github/IRC

Registration for SaltConf 2016 is open! http://saltconf.com/register/

> --
> 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/d/optout.

[Matt]

Colton,
Thanks for the response. I'm aware of the show_diff flag, it's not ideal as I like seeing what changed with a new code deployment. I'll set it False for now.

Matt

[Justin Lloyd]

I don't know if this helps, but I have a shell script for backing up mysql that requires the root mysql password. What I do is store a base64-encrypted version of the mysql root password in Pillar and then write that value into the script, which in turn gets decrypted on the fly by another script, so something like this is in the script template:

MYSQL_ROOT_PASSWORD=`/usr/local/sbin/b64crypt -d "{{ salt.pillar.get("mysql:encrypted-root-password") }}"`

The b64crypt script works by encrypting (-e) with this command:

echo $PLAINTEXT_PASSWORD | gpg --symmetric --passphrase "`dmidecode -s system-uuid`" --no-use-agent --no-mdc-warning | base64 --wrap=0

and decrypting (-d) with this:

echo $PLAINTEXT_PASSWORD | base64 -d | gpg --quiet --decrypt --passphrase "`dmidecode -s system-uuid`" --no-use-agent --no-mdc-warning

The use of the dmidecode command ensures the password can only be decrypted on the server where the password was encrypted, i.e. the mysql backup server in this case (unless someone has that systems uuid, of course). So I manually encrypt the root password using the script and store the resulting base64-encoded string in Pillar.

I haven't touched this code in quite a while (originally set it up back when I was using Puppet), but I could see writing some custom Salt extension (execution module?) to deal with the crypto stuff "natively", eliminating the need for an independent shell script and factoring in use cases where you don't have complete control over the programs that require an unencrypted password string in a configuration file.

[Matt]

Justin,
I will take your suggestion into account if this becomes a higher priority requirement. Thanks for the idea.

Matt

[Colton Myers]

I suppose we could modify file.managed and give it a list of pillar keys, whose values should be obfuscated in the output. Just do a search and replace on the diff for those values and remove them....

Because the primary issue is recognizing what's sensitive and what's not.

--
Colton Myers
Core Engineer, SaltStack
@basepi on Twitter/Github/IRC

Registration for SaltConf 2016 is open! http://saltconf.com/register/

[Matt]

Colton,

This would be the perfect (and cleanest) solution if such feature could be added to Salt!

[John Hicks]

+1 for that idea Colton but I think the logic has to be in the output renderers so that if they are used in cmd.run or somewhere other than file.managed they are still obfuscated.

For example, we trying to use pgp encoded passwords in the pillar (so encoded at rest) but by the time jinja gets hold of them they have been decoded to plain text and are still seen in the salt output especially if passed to a command line script.

[Ryan Lane]

I opened a bug about this same issue a while back, but with a different solution:

https://github.com/saltstack/salt/issues/28006

It would be great for the file.managed state to not show diffs by default or for it to be possible to change that globally via a pillar or minion config. It's difficult to write sls code that will never leak secrets because once someone forgets to disable diffs (or forgets to mask pillar keys) you've leaked a credential. The situation is much worse if you send you salt logs into ELK or splunk or something like that.

[Colton Myers]

Hmmm, interesting idea. It would be pretty trivial to add a global toggle for those diffs, actually. If the kwarg is None, then use the config value. If the kwarg is True or False, use the kwarg value.

If people like the other idea with the list of pillar keys to be obfuscated, please open an issue and link it here!

--

Colton Myers

Core Engineer, SaltStack

@basepi on Twitter/Github/IRC

Registration for SaltConf 2016 is open! http://saltconf.com/register/