Upload
peter-souter
View
726
Download
0
Embed Size (px)
Citation preview
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?