LOCK IT DOWN!SECURING YOUR PUPPET

INFRASTRUCTURE

WHO WAS AT FOSDEM?

THERE MIGHT BE A TOUCH OF DEJA VU...

QUICK SUMMARY OF THE POINTS OF GENERAL CONFIG MANAGEMENT

HARDENING:

MOVE DATA OUT OF CODEENCRYPT SENSITIVE DATAMINIMISE SURFACE AREA

MONITOR, DON'T JUST LOGFIND OUT WHAT A NORMAL STATE OF YOUR MACHINES ARE, AND DETECT

INTRUSIONS

BUT WE'RE GOING TO FOCUS MORE ON PUPPET SPECIFIC THINGS HERE!

WHO AM I?

> Peter Souter > @petersouter

> @petems - IRC/GitHub> Professional Services Engineer at

Puppet Labs> Work with customers when they buy

services and teach Puppet Classes!

WHAT IS THIS ALL ABOUT?

HTTPS://FLIC.KR/P/BHYT8B

PUPPET IS AN AWESOME TOOL FOR SECURITY

PURPOSES!

AUDITINGLOGGING

MONITORINGFIXING CONFIGURATION DRIFT

HARDENING

BUT WHAT ABOUT PUPPET

ITSELF?

HOW DO WE HARDEN PUPPET

ITSELF?

WHAT I'M NOT GOING TO TALK

ABOUT...

LETS START WITH BASICS...

REDUCING THE ATTACK SURFACE

REMOVING SENSITIVE DATA FROM LOGS

EASIEST WAY...

SHOW_DIFF = FALSE

MORE COMPLEX...

CUSTOM TYPES AND PROVIDERS

PUPPET USER TYPE

YOU CAN DO THIS TOO!

TAKEN FROMhttps://github.com/

openstack/puppet-barbican/blob/master/lib/puppet/

provider/barbican_config/ini_setting.rb

NODE-ENCRYPT(WE'LL COME BACK TO THIS IN THE

ENCRYPTION PART!)

REMOVE DATA FROM CODE

ESPECIALLY ORGANISATION SPECIFIC DATA!

HIERA IS HERE TO SAVE THE DAY!

BAD

GOOD

ROLES AND PROFILES PATTERN FOR HELPS WITH

THIS!

ABSTRACTING IMPLEMENTATON SPECIFICS AWAY

ORGANISATION SPECIFIC DATA IN HIERA

ORGANISATION SPECIFC SETUP IN ROLE AND PROFILE WRAPPERS

ADVANTAGE:NOT ONLY MORE SECURE: CLEANER CODE THAT'S

MORE REUSABLE!

THEORETICAL SCENARIO:

YOU SHOULD BE ABLE TO RELEASE MOST CODE YOU

WRITE PUBLICALLY WITHOUT ANY SORT OF

SECURITY ISSUES

ANYTHING SENSITIVE SHOULD BE KEPT IN HIERA

EXAMPLE: GDS

SOME AWESOME SHELL COMMANDS TO CHECK

YOUR CODE...

CHECK COMMITS

CHECK UNIQUE STRINGS

HTTPS://GITHUB.COM/ALPHAGOV/GOVUK-

PUPPET

HTTPS://GDSTECHNOLOGY.BLOG.GO

V.UK/2016/01/19/OPENING-GOV-UKS-

PUPPET-REPOSITORY/

SENSIBLE DEFAULTS ARE

IMPORTANT TOO!

STORY TIME!

IF YOU'RE INTERESTED IN THE STEPS TO RELEASE YOUR PUPPET MODULES, I

HIGHLY RECOMEND WATCHING ELIZABETH'S TALK! :D

YOUR DATA SHOULD IS NOW SEPARATED. HOORAY!

BUT IT'S PLAINTEXT. BOO!

ENCRYPTION

PUPPET - HIERA-EYAML

BAD

GOOD

WHAT ABOUT THE AGENT DECRYPTING THE

INFORMATION FROM THE MASTER?

NODE-ENCRYPT

"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."

http://binford2k.com/content/2015/12/sharing-secrets-puppet-secretly

TRUSTED FACTSIF YOU'RE CLASSIFING

FACTS OR USING THEM AS PART OF YOUR HIERACHY...

HOW TRUSTWORTHY ARE THOSE FACTS?

BASICALLY, NOT MUCH:

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.

https://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_vars.html#trusted-facts

CSR EXTENSIONS

AWS EXAMPLE#!/bin/shif [ ! -d /etc/puppetlabs/puppet ]; then mkdir /etc/puppetlabs/puppetficat > /etc/puppetlabs/puppet/csr_attributes.yaml << YAMLcustom_attributes: 1.2.840.113549.1.9.7: mySuperAwesomePasswordextension_requests: pp_instance_id: $(curl -s http://169.254.169.254/latest/meta-data/instance-id) pp_image_name: $(curl -s http://169.254.169.254/latest/meta-data/ami-id)

if !empty( $trusted['extensions']['pp_role'] ) { include "role::${trusted['extensions']['pp_role']}"}

TRUSTED FACTS FOR HIERA-HIERACHY'S

BAD

GOOD

POLICY BASED AUTOSIGNING

BASIC EXAMPLE

# Spin through attributes and find our custom attribute to check againstatts.each do |a| if (a.oid=="extReq") val = a.value.value.first.value.first.value if val[0].value == "1.3.6.1.4.1.34380.1.1.4" #pp_preshared_key key = val[1].value.strip end endend

# If the key for the attribute matches, sign# Otherwise, exit 1 and don't signif key == "EXAMPLE_TRUSTED_KEY" print "Match\n" exit 0else print "No match\n" exit 1end

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.

https://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html#security-implications-of-policy-

based-autosigning

DON'T FORGET TO CHECKhttps://

puppetlabs.com/security

QUESTIONS?