1.
LOCK IT DOWN!
SECURING YOUR PUPPET
INFRASTRUCTURE

2.
WHO WAS AT
FOSDEM?

3.
THERE MIGHT BE
A TOUCH OF
DEJA VU...

4.
QUICK SUMMARY OF THE
POINTS OF GENERAL
CONFIG MANAGEMENT
HARDENING:

5.
MOVE DATA OUT OF CODE
ENCRYPT SENSITIVE DATA
MINIMISE SURFACE AREA
MONITOR, DON'T JUST LOG
FIND OUT WHAT A NORMAL STATE OF
YOUR MACHINES ARE, AND DETECT
INTRUSIONS

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

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

8.
WHAT IS THIS
ALL ABOUT?HTTPS://FLIC.KR/P/BHYT8B

9.
PUPPET IS AN
AWESOME TOOL
FOR SECURITY
PURPOSES!

10.
AUDITING
LOGGING
MONITORING
FIXING CONFIGURATION DRIFT
HARDENING

11.
BUT WHAT
ABOUT PUPPET
ITSELF?

12.
HOW DO WE
HARDEN PUPPET
ITSELF?

13.
WHAT I'M NOT
GOING TO TALK
ABOUT...

14.
LETS START WITH
BASICS...

15.
REDUCING THE ATTACK
SURFACE

16.
REMOVING SENSITIVE DATA
FROM LOGS

17.
EASIEST WAY...

18.
SHOW_DIFF =
FALSE

19.
MORE COMPLEX...

20.
CUSTOM TYPES AND
PROVIDERS

21.
PUPPET USER
TYPE

22.
YOU CAN DO
THIS TOO!

23.
TAKEN FROMhttps://github.com/
openstack/puppet-barbican/
blob/master/lib/puppet/
provider/barbican_config/
ini_setting.rb

24.
NODE-ENCRYPT(WE'LL COME BACK TO THIS IN THE
ENCRYPTION PART!)

25.
REMOVE DATA FROM CODE

26.
ESPECIALLY ORGANISATION SPECIFIC
DATA!

27.
HIERA IS HERE TO SAVE THE DAY!

28.
BAD

29.
GOOD

30.
ROLES AND PROFILES
PATTERN FOR HELPS WITH
THIS!

31.
ABSTRACTING
IMPLEMENTATON
SPECIFICS AWAY

32.
ORGANISATION SPECIFIC
DATA IN HIERA
ORGANISATION SPECIFC
SETUP IN ROLE AND
PROFILE WRAPPERS

33.
ADVANTAGE:
NOT ONLY MORE SECURE:
CLEANER CODE THAT'S
MORE REUSABLE!

34.
THEORETICAL
SCENARIO:

35.
YOU SHOULD BE ABLE TO
RELEASE MOST CODE YOU
WRITE PUBLICALLY
WITHOUT ANY SORT OF
SECURITY ISSUES

36.
ANYTHING SENSITIVE
SHOULD BE KEPT IN HIERA

37.
EXAMPLE: GDS

38.
SOME AWESOME SHELL
COMMANDS TO CHECK
YOUR CODE...

39.
CHECK COMMITS

40.
CHECK UNIQUE STRINGS

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

42.
HTTPS://
GDSTECHNOLOGY.BLOG.GO
V.UK/2016/01/19/
OPENING-GOV-UKS-
PUPPET-REPOSITORY/

43.
SENSIBLE
DEFAULTS ARE
IMPORTANT TOO!

44.
STORY TIME!

45.
IF YOU'RE INTERESTED IN THE STEPS TO
RELEASE YOUR PUPPET MODULES, I
HIGHLY RECOMEND WATCHING
ELIZABETH'S TALK! :D

46.
YOUR DATA SHOULD IS
NOW SEPARATED. HOORAY!

47.
BUT IT'S PLAINTEXT. BOO!

48.
ENCRYPTION

49.
PUPPET - HIERA-EYAML

50.
BAD

51.
GOOD

52.
WHAT ABOUT THE AGENT
DECRYPTING THE
INFORMATION FROM THE
MASTER?

53.
NODE-ENCRYPT

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

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

56.
TRUSTED FACTS
IF YOU'RE CLASSIFING
FACTS OR USING THEM AS
PART OF YOUR HIERACHY...

57.
HOW TRUSTWORTHY ARE
THOSE FACTS?

58.
BASICALLY, NOT MUCH:

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

60.
CSR
EXTENSIONS

61.
AWS EXAMPLE
#!/bin/sh
if [ ! -d /etc/puppetlabs/puppet ]; then
mkdir /etc/puppetlabs/puppet
fi
cat > /etc/puppetlabs/puppet/csr_attributes.yaml << YAML
custom_attributes:
1.2.840.113549.1.9.7: mySuperAwesomePassword
extension_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)

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

63.
TRUSTED FACTS FOR
HIERA-HIERACHY'S

64.
BAD

65.
GOOD

66.
POLICY BASED
AUTOSIGNING

67.
BASIC EXAMPLE

68.
# Spin through attributes and find our custom attribute to check against
atts.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
end
end
# If the key for the attribute matches, sign
# Otherwise, exit 1 and don't sign
if key == "EXAMPLE_TRUSTED_KEY"
print "Matchn"
exit 0
else
print "No matchn"
exit 1
end

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

70.
DON'T FORGET TO CHECK
https://
puppetlabs.com/
security

71.
QUESTIONS?