Securing Puppet infrastructure

Certs, the master, and node trust.

Puppet’s trust model runs on TLS certificates: each agent has a cert, the master has a CA, and the agent only accepts a catalog from a master it trusts while the master only compiles for agents whose certs it has signed. This mutual authentication is the security backbone — so certificate handling is the heart of securing Puppet. Autosigning every request is convenient and dangerous; deliberate signing (or policy-based autosign) controls which nodes can ever join.

# review and sign node certificate requests deliberately
$ puppetserver ca list                 # pending requests
$ puppetserver ca sign --certname web3.acme.internal
# revoke a decommissioned or compromised node
$ puppetserver ca revoke --certname old-node.acme.internal

The master and the code are privileged

The Puppet master compiles catalogs that run as root on every node and holds the eyaml private key that decrypts all secrets — it is one of the most sensitive hosts you operate, so harden it, restrict access, and keep its code in reviewed version control. Use environments to test changes before they reach production nodes, keep node trust (trusted facts from the cert, not spoofable facts) for security decisions, and never make authorization choices on facts a node can lie about.

# trust the certname from the cert (unspoofable), NOT a node-supplied fact
if $trusted['certname'] =~ /^prod-/ {
  include profile::prod_hardening
}
# $facts can be manipulated by a compromised node; $trusted comes from the signed cert