GPG support in ansible-vault

Hi list!

After seeing the 1.5 release of ansible-vault I immediately wanted it to support GPG so that we can avoid sharing a pre-shared key amongst admins and instead use the existing GPG keys.

As such I have spent a few hours this week throwing together the basics and have had success porting all functions to use GPG.

There are a number of downsides to the python-gnupg implementation, most obviously;

  1. Decryption requires the use of gpg-agent otherwise you will never get to the interactive shell in the subprocess
  2. I have not been able to successfully wrap the decrypt calls in a Timeout block that would help catch the above point 1, I believe this may be due to the subprocess hanging
  3. The only way to get visibility is to turn on verbosity which is nasty
    None the less I feel that being able to switch over to GPG will allow groups who are interested to make use of the tool while defaulting to the traditional pre shared keys for everyone else,

I will clean up the code (currently at https://github.com/Kahn/ansible/commit/c264b1367391b9d5152201192b0eb960fed78148) and prepare to submit the PR. In the meantime all comments and criticism is very welcome!

Cheers,

Sam

​Hi Sam,

+1 for gpg vault support!

I have not been able to successfully wrap the decrypt calls in a Timeout
block that would help catch the above point 1, I believe this may be due to
the subprocess hanging

​This is probably due to the fact that host/group vars get (re-parsed) each
time the runner​ encounters a new host it hadn't touched yet (which indeed
spawns several subprocesses, and it might try to open the same file more
than once concurrently)
I'm working on moving this out of runner, into inventory initialization,
which might help for your issue here.

I'm still working on this patch, and it's far from ready, but you *might*
want to test your patch set on top of this commit:

https://github.com/sergevanginderachter/ansible/commit/91e5464637f8357f1dc911da8bee19705bda4e09

Keep in mind that this branch is WIP, and will probably get rebases or
other forced updates!

Serge

So

(A) Serge’s refactoring cleanup should have absolutely zero impact on an additional ciphers on VaultLib. Don’t wait for that patch.

(B) VaultLib is already pluggable, it would just need additional cipher classes as options. It was designed this way in the beginning so I’m interested in seeing what you might do with it.

(C) The existing cipher additions cannot be removed. Changing any cipher names or defaults will not be accepted.

(D) Start off with a new Cipher class that VaultLib case use + unit tests, and let’s go from there.

It does not appear to be obvious to me, but it does not seem to be
designed to be pluggable for different encryption methods, i.e. it
assumes that symmetric password based encryption is used. Also
VaultEditor contains hard checks whether symmetric crypto modules are
present (e.g. in VaultEditor.decrypt_file()). I am looking at
lib/ansible/utils/vault.py as of commit
225eca6311cc559c3cc9eb0cb3e64b184929cec5 - is there some other code you
are writing about?

Regards
Till

The cipher class system is modular.

I’ve been able to reuse the cipher call but as Till points out you do need to suppress the password prompting from the VaultLib class. I’ve done this by adding a [vault] and cipher=AES256 default to ansible.cfg so it’s easy to switch between symmetric and asymmetric modes.

I am very busy at the moment but working on patches upstream to be able to better handle pass phrase input and timeout cases before submitting anything to ansible

Cheers,

Sam

Having it configured there sounds reasonable and good to me.

And patches to not prompt if that was the cipher would also be reasonable. Bonus points for it being an attribute of the cipher class about whether to prompt or not.