GPG renderer and salt pillar decryption

[Michael E]

I need to summarize for an auditor how the GPG renderer works for encrypting our secrets. The documentation and comments are a great start, but I'm still confused about which parts of the decryption process happen on the master and which happen on the minion.

The documentation mentions (1) The Salt master can decrypt secrets and distribute them only to the minions that need them. And (2) The gpg renderer requires python-gnupg to be installed on all minions since the decryption will happen on the minions.

So is the encrypted pillar value passed to the minion along with the private gpg key to handle the decryption there? Or is the pillar value decrypted by the master before getting passed to the minion?

These are the sources I used for reference:

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

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

[Seth Miller]

The GPG renderer decrypts on the master. The document you mentioned says...

only your Salt master can decrypt them and distribute them only to the minions that need them

The private key is stored on the master and should be kept secure (proper perms, etc).

I suppose there may be ways to decrypt on the minion but that would seem more difficult to manage. You'd need keypairs for each minion and you'd need to ensure to encrypt properly before pushing to source control. Encrypting for the wrong minion won't work and encrypting for all minions or sharing a keypair probably wouldn't be much more secure than a single keypair on the master.

Personally, I use the GPG renderer at work and decrypt on the master and send the decrypted data only to the intended minion(s). I feel fairly confident with this approach but I'm also working in a low profile environment.

--seth

[Michael E]

Thanks. The explanation you provide makes sense, since the private key is only added to the keychain on the master.

I'm still not sure I understand the full process, however. The gpg renderer requires the python-gnupg package to be installed on the minion, and the comments in the renderers/gpg.py script mention that the package is required because the decryption will happen on the minions. That seems to contradict the documentation which says that only the Salt master can decrypt the pillar values.

I'm not looking to change the way the process works. I just need to understand it well enough to describe it to a semi-technical person and be able to answer questions about it if challenged. 

[Colton Myers]

It depends on whether you're talking about pillar rendering with the gpg renderer, or state rendering.

State files render minion-side. So if you use the gpg renderer with states, then you'll need to have the gpg key (and gpg deps) installed on the minion. But this is not how most people use the gpg renderer. Rather, most use it to keep important pillar keys encrypted at rest. If you're using it in pillar files, then it will render on the master, and the minion will have no idea gpg was ever even involved, it just gets the final pillar data structure.

Hope that helps.

--

Colton Myers

Platform Engineer, SaltStack

@basepi on Twitter/Github/IRC

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments.  Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

--

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.