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.

1. LOCK IT DOWN!
SECURING YOUR PUPPET
INFRASTRUCTURE

2. WHO WAS AT
FOSDEM?

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

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

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

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

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

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

10. PUPPET IS AN
AWESOME TOOL
FOR SECURITY
PURPOSES!

11. AUDITING
LOGGING
MONITORING
FIXING CONFIGURATION DRIFT
HARDENING

12. BUT WHAT
ABOUT PUPPET
ITSELF?

14. HOW DO WE
HARDEN PUPPET
ITSELF?

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

16. LETS START WITH
BASICS...

17. REDUCING THE ATTACK
SURFACE

18. REMOVING SENSITIVE DATA
FROM LOGS

19. EASIEST WAY...

20. SHOW_DIFF =
FALSE

21. MORE COMPLEX...

22. CUSTOM TYPES AND
PROVIDERS

23. PUPPET USER
TYPE

25. YOU CAN DO
THIS TOO!

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

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

29. REMOVE DATA FROM CODE

30. ESPECIALLY ORGANISATION SPECIFIC
DATA!

31. HIERA IS HERE TO SAVE THE DAY!

32. BAD

34. GOOD

36. ROLES AND PROFILES
PATTERN FOR HELPS WITH
THIS!

37. ABSTRACTING
IMPLEMENTATON
SPECIFICS AWAY

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

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

40. THEORETICAL
SCENARIO:

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

42. ANYTHING SENSITIVE
SHOULD BE KEPT IN HIERA

43. EXAMPLE: GDS

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

46. CHECK COMMITS

48. CHECK UNIQUE STRINGS

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

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

52. SENSIBLE
DEFAULTS ARE
IMPORTANT TOO!

53. STORY TIME!

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

56. YOUR DATA SHOULD IS
NOW SEPARATED. HOORAY!

57. BUT IT'S PLAINTEXT. BOO!

58. ENCRYPTION

59. PUPPET - HIERA-EYAML

60. BAD

62. GOOD

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

65. NODE-ENCRYPT

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

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

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

70. HOW TRUSTWORTHY ARE
THOSE FACTS?

71. BASICALLY, NOT MUCH:

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

74. CSR
EXTENSIONS

75. 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)

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

77. TRUSTED FACTS FOR
HIERA-HIERACHY'S

78. BAD

80. GOOD

82. POLICY BASED
AUTOSIGNING

83. BASIC EXAMPLE

84. # 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

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

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

87. QUESTIONS?