Releasing Puppet modules via Travis

Development RFCs
#1

Current situation

There are a few people who have the credentials to the Puppet forge accounts (theforeman and katello). That means only these people can do module releases.

Releasing Puppet modules via Travis

Travis CI is capable of releasing a Puppet module to the Puppet forge. The typical workflow would be on a tag.

We have an example in obal:

As can be seen the password is encrypted so it can be stored in git. Encryption of secrets is documented but here’s the gist:

Travis CI uses asymmetric cryptography. For each registered repository, Travis CI generates an RSA keypair. Travis CI keeps the private key private, but makes the repository’s public key available to everyone. For example, the GitHub repository foo/bar has its public key available at https://api.travis-ci.org/repos/foo/bar/key. Anyone can run travis encrypt for any repository, which encrypts the arguments using the repository’s public key. Therefore, foo/bar’s encrypted values can be decrypted by Travis CI, using foo/bar’s private key, but the values cannot be decrypted by anyone else (not even the encrypter, or “owner” of the foo/bar repository!).

Implications

It means that anyone with access to a Github account can release Puppet modules to the Puppet Forge. We have no granularity.

I have considered checking GPG-signatures of git tags but since the Travis configuration is also in git, this would be trivial to bypass.

An alternative could be to build a similar solution in Jenkins where we control how jobs are built but storing these secrets on Jenkins slaves might be less secure because other jobs could be abused to retrieve the password.

Work done

There is an open PR to add it to our Puppet modules.

Before I proceed I’d like a conceptual ACK. I’m especially interested in the opinion of @mmoll, @ehelms and @stbenjam because they’ve done releases in the past.

2 Likes
Release meeting 2019-07-08
#2

Any github account? Or a github account in theforeman organization? or what granularity?

#3

Access to a github account with push permissions to a repository. It means that a compromised Github account or SSH key now also gains access to publishing Puppet modules to the Forge.

#4

I’m not on the list, but I’d personally be ok with the implication. People with write access can do bad things but it never happened AFAIK

#5

I hadn’t read about the ESLint compromise when I created this RFC, but it reminds me that we should be careful and there are still a lot of bad actors around.

On a related note: all developers should check that they haven’t installed any of the compromised NPM packages.

#6

I’m generally in favor of this change, but in light of the eslint event, I agree we should tread carefully. Perhaps we should start enforcing 2FA with anyone to commit to any repo in theforeman or katello organizations. Owners of the respective orgs can view the 2FA status of members, I think.

#7

It is possible to enforce 2FA.

https://help.github.com/articles/requiring-two-factor-authentication-in-your-organization/

Require 2FA for GitHub organization members
#8

RFC: Require 2FA for GitHub organization members

#9

With https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab in mind I am wondering about this. There are upsides to separating the commit from release permission because it means it’s easier to give commit access. On the other hand, we rarely even have candidates for commit access.

Because I’m unsure, I’m opening a poll which will close in 2 weeks.

Should we allow all Puppet module commiters allow to release modules to the Forge?

  • Only with 2FA
  • No

0 voters