I’ve been putting encryption in place for sensitive data in our Salt configuration lately. In other words avoid storing passwords and private SSH keys in clear text in a git repository, but store them encrypted instead.
While doing so I came across the Intothesaltmine guide, and tried to use an encrypted key, which leads to use a gpg-agent in conjunction with Salt.
Salt is GPG-ready, and the
salt-master has his its
gpg_keydir defaulting to
/etc/salt/gpgkeys. BTW, GPG is only used by the master, so
pyhon-gnupg doesn’t need to be installed on minions.
Now you have the choice:
- use a password-less key, and that’s what is recommended in the Salt documentation
- use an encrypted key, and then a gpg-agent is needed.
The rest of this post is about the case of an encrypted key.
First off, I wonder if the
salt-master should not ask for the passphrase itself: on one hand it would save the burden of starting an agent ourselves, but on the other hand the already-here GPG 2.1 client starts an agent anyway the first time a passphrase is needed.
salt-master will look for an agent socket in its
/etc/salt/gpgkeys/S.gpg-agent by default. So the trick is to start an longtime-running agent at the right place.
After having created the key and set up GPG with
I start the agent with this little script:
What we do here is start the agent with a very long caching time, and immediately use the private key to have the agent ready for Salt.
The next step is probably to have the agent started with Salt, or at least monitored. But I haven’t into that yet. Furthermore, I wonder if having the salt-master key in clear on the master is not a sufficient tradeoff : after all it’s restricted to root users on a machine with presumably limited access.