Puppet is an awesome tool to automate the configuration of your infrastructure, but it's also a potential attack vector. In this talk, we'll discuss some common patterns and changes you can make to harden your Puppet infrastructure, from the basic good practises such as data abstraction in modules, to some advanced customisation you might need in a high-security setup.
"THE PUPPET MASTER WILL ENCRYPT
THE CONTENT OF THE FILE USING THAT
AGENT'S PUBLIC KEY. ONLY THAT
AGENT WILL BE ABLE TO DECRYPT IT--
USING ITS PRIVATE KEY, OF COURSE.
THE ACTUAL PLAIN-TEXT CONTENT OF
THE FILE WILL NEVER EXIST IN THE
CATALOG OR IN ANY REPORTS."
A few special trusted facts appear in a $trusted hash.
They can be accessed in manifests as
$trusted['fact_name']. The variable name $trusted is
reserved, so local scopes cannot re-use it.
Normal facts are self-reported by the node, and nothing
guarantees their accuracy. Trusted facts are extracted
from the node’s certificate, which can prove that the CA
checked and approved them. This makes them useful for
deciding whether a given node should receive sensitive
data in its catalog.
# Spin through attributes and find our custom attribute to check against
atts.each do |a|
val = a.value.value.first.value.first.value
if val.value == "188.8.131.52.4.1.343184.108.40.206" #pp_preshared_key
key = val.value.strip
# If the key for the attribute matches, sign
# Otherwise, exit 1 and don't sign
if key == "EXAMPLE_TRUSTED_KEY"
print "No matchn"
IF YOU EMBED A UNIQUE PRE-SHARED KEY IN EACH NODE WHEN
YOU PROVISION IT, AND PROVIDE YOUR POLICY EXECUTABLE WITH
A DATABASE OF THESE KEYS, YOUR AUTOSIGNING SECURITY WILL
BE AS GOOD AS YOUR HANDLING OF THE KEYS — AS LONG AS IT’S
IMPRACTICAL FOR AN ATTACKER TO ACQUIRE A PSK, IT WILL BE
IMPRACTICAL FOR THEM TO ACQUIRE A SIGNED CERTIFICATE.
DON'T FORGET TO CHECK