Guide for Salt Pillar GPG Encryption/Decryption?

[Jay Ambi]

Hello,

After moving most of my orgs dev workflow to Salt, I now have management paranoid about secure data in plaintext in any repos, as multiple devs access things.

Attempting to use the GPG renderer so that pillars can be stored encrypted in the repo as mentioned here:

https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html
&

https://github.com/saltstack/salt/blob/develop/salt/renderers/gpg.py

Have the first part where I have a key setup at /etc/salt/gpgkeys on my Salt-Master, and have then tied to encrypt my existing Pillar files using that key but  I only see errors whenever im trying to compile that pillar data via the renderer.

I'm unsure of a few things from here.

1) How exactly is the GPG key specified for the Salt-Master to use... I don't see any configuration values in the master config, so I'm not even certain Salt is setup to do the correct thing.

2) Once Salt-Master knows a GPG key to use, how are you meant to encrypt the pillar files so that Salt knows how to decrypt them?

Say I have a pillar for an ssh key that I reference with a state to add the key to all my Salt-Minions authorized_keys file:

sshkey:
  minion:
    default_authorized_keys: |
      ssh-rsa yaddayaddayaddagobbledegookyaddayaddayaddaa

What do I do with it? Can anybody give me a workable example, cause its not clear to me and I am basically in a trial & error black hole...

ThanksInAdvance

[Justin Desilets]

Jay,

Listed in the documentation you can see where you need to drop your GPG keys so salt can use them.

The salt master is just setup to look to this location for the keys:

/etc/salt/gpgkeys

You will also need to update your master and minions to include the package python-gnupg. Without this package your states/pillars will fail to render. Once you have those in place, you can follow the directions:

echo -n "supersecret" | gpg --armor --encrypt -r <KEY-name>

to encrypt the secret you have. You will need to paste in all the text you want to have encrypted. GPG will return a blob of text back which you will then copy into your pillar as show in the documentation.

If you were encrypting the whole string "ssh-rsa ssh-rsa yaddayaddayaddagobbledegookyaddayaddayaddaa" you would format your pillar like this:

sshkey:
 minion:
   default_authorized_keys: |
     -----BEGIN PGP MESSAGE-----

          Version: GnuPG v1

          hQIMA/VV2IGQ+0vkARAAidcLCb0pgiSuVjoYt41vFYHJDtnvZ4v1FX1VPSF6Ckbo

          dpO+GZSJznlT9V0NLV0lQaunt+M38O8A0Q8+ecPGhXa6DnUnSPxLOZDfDSWLvv29

          ...

          WQHpibx8ImzIS7VcldRN7QygRI+aKWsXBXzXAu+7odj90auDvcgHDywX1xljLg1r

          JwEZqV28PP7RBUEvSPUYK47OZdS5edoDpBNi/GsrlX3Wh4bCKeDQm4zL

          =XnIg

          -----END PGP MESSAGE-----

It's kind of hard to line things up in the code block but hopefully you get the idea.

Now if you created the key on your salt-master and are encrypting the text there you can use:

gpg --list-keys

to view a list of keys currently available to the master. If you wish to run this on your workstation then you will need to export the salt-master gpg key you created and import it into your workstation. Then you'll just use that key name in the above command where you are echoing your "supersecret" into gpg. To test and see if it is available afterwards you can run:

salt '$target'pillar.get sshkey:minion:default_authorized_keys

this is using your above example.

[C. R. Oldham]

Note you can also look into SDB, and someone is working on an integration with Hashicorp's Vault.  There are already some other backends for SDB that might be a good fit for your use case.

--
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.

--

--cro

C. R. Oldham, Platform Engineer, SaltStack

c...@saltstack.com / 801-564-4673

[Jay Ambi]

Thanks Justin,

I was following that process but it looks like my 'gpg --gen-key' run was saving things into ~/.gnupg/ -- I had a key in /etc/salt/gpgkeys/ but I'd tried so many times there were keys everywhere, but gpg --list keys was defaulting to ~/.gnupg with me not noticing.

Seems you need to specify --homedir=/etc/salt/gpgkeys on any command run, from --gen-key to --encrypt? At least that worked when I started fresh. I'll havta look into the gpgkey config to default the homedir properly to /etc/salt/gpgkeys

[Jay Ambi]

Thanks for the note, that sounds interesting, and we've got guys working with Vault which looks great so far, so I'll definitely look into the integration going on!

[Paul Bruno]

I was having the same issue. I just resolved this in my environment by doing the following:

- installed gpg using yum on salt master

- created /etc/salt/gpgkeys

- chmod 0700 /etc/salt/gpgkeys

- set a persistant env var in .bashrc: GNUPGHOME=/etc/salt/gpgkeys

- source ~/.bashrc

- gpg gen-key 

- gpg --list-keys

- echo -n "my-big-secret" | gpg --armor --encrypt -r mykey --homedir /etc/salt/gpgkeys

- verify 'random_seed' file created in /etc/salt/gpgkeys

- add cipher text to salt pillar with #!yaml|gpg (as noted in earlier thread by Justin)

- run pillar.get from saltmaster (as noted earlier by Justin)

Paul

[Jonathan T]

Has anyone used this with a multi-master setup? It seems that the only way to have this work and be somewhat secure would be to export the key from the original master, password protect it, copy it to the additional master(s), then import it without password protection. Has anyone tried this or have another method?

[Chad Geary]

For those that need it (tested CentOS 7.6)

 # Implement an encryption / decryption scheme for storing and accessing sensitive data (e.g. passwords) using a SaltStack salt master

# SaltMaster

# one time setup (gpg key + dirs)

# follow prompts to generate key

# real name: saltmaster1.chadg.net

# never expires / no passphrase

sudo gpg --gen-key

# list

sudo gpg --list-keys

# copy to salt dir

sudo mkdir -p /etc/salt/gpgkeys

sudo chmod 0700 /etc/salt/gpgkeys

sudo cp ~/.gpg/* /etc/salt/gpgkeys/

# encrypt a string with key, paste/type then hit enter to pass to gpg

{ stty -echo; head -n 1; stty echo; } | sudo /usr/bin/gpg --armor --batch --trust-model always --encrypt -r 'saltmaster1.chadg.net' | sudo tee /srv/pillar/encryptedstring.sls

# format sls file for jinja/yaml/gpg

sudo sed -i -e 's/^/  /' /srv/pillar/encryptedstring.sls

sudo sed -i -e '1i encryptedstring: |' /srv/pillar/encryptedstring.sls

sudo sed -i -e '1s/^/\n/' /srv/pillar/encryptedstring.sls

sudo sed -i -e '1i #!jinja|yaml|gpg' /srv/pillar/encryptedstring.sls

# assign to minion(s)

sudo tee -a /srv/pillar/top.sls << EOM

  'someminion.chadg.net':

    - match: list

    - encryptedstring

EOM

# Confirm pillar accessible from someminion, but not someother

sudo salt -L someminion.chadg.net saltutil.refresh_pillar

sudo salt -L someminion.chadg.net pillar.get encryptedstring

sudo salt -L someother.chadg.net saltutil.refresh_pillar

sudo salt -L someother.chadg.net pillar.get encryptedstring

# reference in a state

sudo mkdir /srv/salt/sometest

sudo tee /srv/salt/sometest/init.sls << EOM

expose-encryptedstring:

  cmd.run:

     - name: echo {{ salt['pillar.get']('encryptedstring') }}

EOM