Autosigning of Puppetmaster and agents

This blog deeply discusses the autosigning feature of Puppet. During my journey to implement auto sign in our production environment, I came across various challenges related to security and making it as tight as possible and I was finally reached the last resort to achieve autosigning as per my requirement.

Autosign is a feature of Puppet, configuration management tool, to enable administrators to auto sign SSL requests of puppet agents  without bothering for manually signing each and every request. The feature has various pros and cons. Pros are that it saves manual work of administrator to sign each and every request but cons are that it may result into serious security issues if it  signs every incoming request irrespective of whether admin wants them to be signed or not. There are various techniques to control the autosigning behaviour of Puppet to improve its usability and have less security vulnerability. Puppet is still working on autosigning to make it even more useful. As of today, there exist three types of auto signing.

Naive Autosigning:
Naive autosigning can be enabled by simply writing a parameter in /etc/puppet/puppet.conf as “auto sign = true” or by making an entry * in /etc/puppet/autosign.conf. This will sign all the request that are coming from any agent without looking at their hostname. The flaw with this approach is that, if a fraudulent machine somehow manages to reach puppetmaster, it can easily fetch the catalogue as puppetmaster will auto sign without probing for its identity.

Basic Autosigning:
This is one good way to control autosigning using regular expressions. In this method, hostnames of puppetagents are generated in a pattern and that pattern can be included in /etc/puppet/auto sign.conf using regex i.e. regular expression. It often seems difficult to understand way of writing regular expression for Puppet. Puppet follow ruby format of regular expression. This link can be referred for more insights of Puppet regex. A few examples are listed below,

1) Regex to allow FQDN with any domain name and any hostname is simply *

2) Regex to identify a group of machines with hostname www12 or www34 etc can be /^www(\d+)\./

3) Regex to identify a group of machines with hostnames like ip-10-0-0-24 or ip-10-0-3-39 etc. as we have in our ec2 servers can be /^ip-10-0-(\d+)-(\d+)\./

Policy based Autosigning:
In this approach, some attributes are passed in puppet agents CSR (Certificate signing request). These Custom attributes can be used by the CA server (puppetmaster) to decide whether to sign the certificate or discard it. To achieve this functionality, create a csr_attributes file at /etc/puppet/ location on the agents. This file should be in YAML format and contain key-value pairs. Two keys that can be used in this file can be “custom_attributes” key and/or an “extension_requests” key. Each key is an OID (object identifier). Content of csr_attributes file are as shown below,

Now, to sign it automatically at the master’s end, we need to put a script at master in /etc/puppet/autosign.conf file that checks and allows these custom attributes so that puppetmaster can sign it accordingly. The script will only allow parameters those are mentioned in ‘valid_values’ attribute.

If implemented successfully, the master will check the UUID value passed in csr_attributes file in the agent and if that matches, it will auto sign the request of that agent. Above shown custom attribute is a test example, to implement it in the real environment, we need to declare UUID as a variable instead of a fixed value as we did in this case.

Best Regards
Sharad Aggarwal