Puppet Continuous Integration Appliance - Week 2

Puppet Continuous Integration Appliance - Week 2

Week 1 was filled with lots of excitement as well as really cool and interesting design decisions. Week 2 was filled with lots of work and troubleshooting but was still lots of fun. It's an amazing thing to see something so rapidly transform from an idea in your head to something that could remotely be of use to someone.

One of the primary focuses of the second week of the project has been getting release 0.0.1 ready and out the proverbial door. Let's go ahead and rundown what happened this week.


In addition to architecting the security of the solution this week has seen significant changes in the UI to a more modern looking interface.

  • UI changes
  • Jenkins credential creation
  • Container migration to Centos 7
  • Security design decisions

UI Changes

One of the most rewarding changes this week was the decision to ditch the previous UI and change to a new Bootstrap template that brings a very modern looking interface to the appliance as seen in the image below.

Automate Jenkins Credentials Creation

One of the major tasks for the week was to automate the creation of Jenkins credentials. The appliance will need at least two credentials created dynamically, one is the credential for accessing the repositories for Puppet modules and the control repo. The other credential is for connecting with the dynamic Jenkins slaves that are spun up on the underlying Docker host.

The final solution utilizes the Jenkins REST API to create the necessary credentials.

From the Jenkins CI Server Configuration page we're able to enter our SSH key that will be used for downloading repositories into the designated field. Once we click the submit button we can jump over to the Jenkins instance to see the magic that has taken place.

The Jenkins instance can be accessed on port 8080 of the appliance and as seen in the picture below the SSH key we entered into the text box has been added to our Jenkins CI server.

Migrate Containers to CentOS 7

My initial plan was to utilize as many official or existing container images as possible to avoid a lot of work that someone else has already done. There were two primary reasons for the decision to move the majority of the containers to a CentOS 7 base, one of them being taking advantage of Docker's image layering which utilizes the single base image for all images built on CentOS 7. The other reason was the need to customize the images so much that it made sense to just start over from a base image an glean from the other existing images. While it's certainly more work I like the added level of control regarding what is and isn't in the image.

Security Design Considerations

The following covers some of the design decisions I'm thinking through as part of the solution buildout.

  • Internal certificate authority
  • All components must communicate over SSL/TLS
  • All passwords and secrets must be encrypted in transmission as well as at rest
  • Certificate based authentication will be utilized by services for accessing secrets and passwords
  • All connections must be audited to an external log server

  • CFSSL (https://github.com/cloudflare/cfssl)
    CFSSL is a certificate tool created by CloudFlare that is extremely lightweight and offers a very easy to use API which is critical to automation.

    CFSSL would leveraged to provide encrypted communication between all components of the solution as well allow certificates to be leveraged for authentication as well.

  • Hashicorp Vault (https://www.vaultproject.io/)
    Vault is a secrets management tool created by HashiCorp which is known for other tools such as Vagrant and Packer.

    Vault would be leveraged to encrypt all secrets within the solution such as SSH keys, passwords, etc.

In addition to the security aspects covered above I'm always pondering about where security can be improved.

All in all it's been a pretty productive week all culminating in the 0.0.1 release of the Puppet CI Appliance.

Subscribe to