ansible-galaxy: Check OpenPGP signatures of roles

[ypid]

Proposal: ansible-galaxy: Check OpenPGP signatures of roles

Author: Robin Schneider <@ypid>

Date: 2016-10-31

• Status: New
• Proposal type: ansible-galaxy improvement
• Targeted Release: future release
• Associated PR: none yet
• Estimated time to implement: ~4 days

Motivation

Ansible roles are used to manage core infrastructure and therefore MUST be trustworthy. This can only be ensured by end-to-end authentication. The most widely used tool for this is GnuPG and OpenPGP signatures.

The majority of GNU/Linux package management tools are doing it for ages, various package/module managers for programming languages are starting to do it (example: PIP/PyPI).

The Ansible Galaxy and the ansible-galaxy command should also support it.

Also refer to the DebOps Code Signing Policy

Problems

Most people install Ansible roles either from https://galaxy.ansible.com/ or from https://github.com/. No third party can/should be trusted. Currently if GitHub or Ansible Galaxy get compromised or content on either of them is otherwise modified, users will happily run modified roles which can lead to all their infrastructure getting compromised.

Solution proposal

Best practices for software development already recommend OpenPGP signed releases (ref: https://github.com/ansible/ansible/issues/16871) so we can build on that. To solve this, I would propose the following:

• Extend Ansible Galaxy to show signed git tags or signed tarballs in the web UI and pass signatures on to ansible-galaxy
• Extend ansible-galaxy to verify signatures using the GnuPG keyring managed by the user.
• If the key is not present show a help message like "You have never downloaded/installed a role from that author before. He/She uses the OpenPGP key with this fingerprint: XXXX. Do you want to trust this OpenPGP key from now on?" and then allow download the key using gpg --recv-keys.
• Save the level of trust ansible-galaxy puts into a key into a separate configuration file to not allow everyone in one’s keyring to sign roles.
• Save the role to key mapping and check it.
• Assume that when a role was signed once, all subsequent releases are also signed. If not, make ansible-galaxy show a warning and abort.

This would reduce the problem to trust on first use, the same as for example OpenSSH does it.

Testing (optional)

Requires testing. Can be implemented using unit/integration tests to avoid regressions.

Documentation (optional)

Requires documentation.

[bcoca]

This would also pave the way for possible autodownload, it is better than a 'whitelist' configuration.

[ghost]

Maybe consider using TUF, that has a python library available and a lot of potential kinks worked out.

[chouseknecht]

I have to ask, what does "trustworthy" mean, when we state, "Ansible roles are used to manage core infrastructure and therefore MUST be trustworthy."

Agree, that getting to "trustworthy" content is a good goal, but it's a broad term.

If content is signed, what does that actually mean? How do we make it more valuable than just checking the checksum of the downloaded file?

Should content be signed by the distributor, Galaxy, and not the content creator? In the case of community contribution, probably yes, for two reasons. One, signing content is a PITA workflow, that most community contributors probably don't care about, or want to do. Two, most community contributors aren't doing a whole lot of QE, if any, on their content, so is there any real value in having them sign it? Probably not.

It seems like, IMHO, that to make the signature valuable, and provide some notion of trustworthiness, in a lot of cases Galaxy should be the signer of the content. Galaxy should have an automated process of testing, and calculating some level of goodness or trustworthiness, and if the content passes this bar, then Galaxy signs it, and distributes it.

In the case of content coming from trusted 3rd parties, i.e. vendors, should the vendor do the signing? Probably yes, in which case Galaxy should provide tooling, and a solid workflow to help with signing. It would need to be something like rpm.

That last part of course leads to the obvious question... Should Galaxy have a mechanism of delivering content via RPM, Debian secure archives, etc., and take advantage of existing archive creation and signing tooling.

[chouseknecht]

I think what's described in this proposal is some automation around this workflow: https://wiki.debian.org/Creating%20signed%20GitHub%20releases, which results in an archive file, and a separate or detached signature file. It's basically no more valuable than a checksum file, when measuring trustworthiness.

The signature file can be used on the client side to verify the downloaded archive file received matches what's expected, but it provides no indication regarding the quality or trustworthiness of the archive's contents. Maybe that's OK, and all anyone expects, but I don't think it would supplant the need for a whitelist or some form of QE that actually touches and analyzes the content.

[amenonsen]

… which results in an archive file, and a separate or detached signature file. It's basically no more valuable than a checksum file, when measuring trustworthiness.

Anyone who breaks in and manages to alter the archive can also alter the contents of a checksum file to match. A PGP signature can be forged only if you also gain access to the signer's private key.

If I understand correctly, you are saying that someone can validly sign a (malicious or just broken) pile of junk, but still, "no more valuable" than a checksum file doesn't sound right to me.

[chouseknecht]

Yes, a signature is better than a checksum. However, I can calculate a checksum or sign a "malicious pile of junk." Either way, it's still a "malicious pile of junk." We haven't upped the trustworthiness factor, imho.

I think the community would be better served, and the process would be easier for content creators, if Galaxy actually ingests the content, inspects it, tests it, calculates a checksum, signs it, and hosts it. Then we would be reasonably assured that the downloaded content is not a signed, malicious pile of junk.

[amenonsen]

I think the community would be better served, and the process would be easier for content creators, if Galaxy actually ingests the content, inspects it, tests it, calculates a checksum, signs it, and hosts it.

Something like an app store approvals process, then?

[jozef-dudas]

Please keep in mind, that github can host also private repositories. Ansible-galaxy could use them to install depending roles for playbooks. As such, the ansible-galaxy should be checking limited number of GPG keys used by internal developers "approved" by given company. This would greatly improve the workflow