Puppet Users Group Meetup 12032014

Hiera Custom Backends | Compliance reporting

Transcript

1. Richard Hailstone • Security Architect • 15+ years in the IT industry performing engineering and or UNIX related roles. • Puppet builds and deployments within Finance, Telco, Govt sectors and some other boutique companies.
2. Hiera and the ENC A brief discussion on how to externalise your data and more importantly, managing that data via custom backends
3. What’s an ENC ? ENC’s methods : • LDAP - puppet has a supported schema • Shell/Exec - bash scripts that pull RESTful data out of cloud mgmt platforms • The Dashboard. The default ! most of these seemed cumbersome and just a little bit uninventive.
4. Hierarchy of values that are resolved at compilation time. Typically based on system facts • module specific variables make it visually understandable to your user base base:: params::variable • Resolve your class definitions via heira $PUPPET/manifests/site.pp node default { hiera_include('classes','') }
5. Having Hiera supply values via .yaml files is ok. Using a custom backend might be better ? • Custom Hiera Backends http://docs.puppetlabs.com/hiera/1/custom_backends.html • puppet supports custom back ends written in ruby.
6. I like REDIS :) REDIS is a key and value store, often referred to as a NoSQL database. http://redis.io/ - in memory. - fast variable resolution times. - minimise IO :)
7. there is a custom Hiera backend that uses REDIS. https://github.com/reliantsecurity/hiera-redis How do we hook it up ?
8. The Hierarchy :hierarchy: - %{::clientcert} # node name - %{::operatingsystem} # subset - %{::sig_pod} # datacentre specifics - common # all nodes common.yaml, sig4_sgs.yaml, Redhat.yaml, wwwserve01.yaml You can use standard or custom facter facts in your hierarchy. We use sig_pod to denote the DC and its associated settings.
9. In common.yaml we set the classes applied to all nodes : This is our base node config. --- classes: ['base', 'mcollective', 'ntp', 'profile', 'ssh', 'cron'] In sig4_pod, we set dns, ntp, ldap, ipv6 dns: [‘1.1.1.1’, ‘8.8.8.8’] ipv6: yes In RedHat.yaml, we set the classes applied to all Red Hat systems : --- classes: ['yum']
10. In wwwserve01.yaml, we set the classes applied to this specific host : --- classes: ['rabbitmq', 'redis', 'zabbix::client'] And in your site manifest on your master : node default { hiera_include('classes','') } ' ' means the failback. use failback when you retrieve your hiera variables. Saves the compilation from failing in the event that hiera resolution doesn’t work. $varname = hiera('mymodule::varname', 'default' } $ntpservers = hiera("ntpservers", “1.1.1.1”)
11. Switch the backend to redis %gem install redis %gem install hiera-redis In /etc/puppet/hiera.yaml, add or switch to the new backend : :backends: - redis :redis: :password: nil Some versions require you to set at least one value. In this case it’s the account password to log into redis.
12. The mapping between puppet classes and nodes is done like this : # Default classes for all nodes redis-cli<<'EOF' sadd common:classes core sadd common:classes mcollective sadd common:classes ntp sadd common:classes profile sadd common:classes ssh sadd common:classes vim smembers common:classes EOF
13. Pod Specifics # Custom classes for the hostname wwwserve01 redis-cli<<'EOF' sadd sig4_sgs:nameservers 8.8.8.8 sadd sig4_sgs:nameservers 9.9.9.9 sadd sig4_sgs:ntp 1.1.1.1 smembers sig4_sgs:nameservers EOF Node Specifics # Custom classes for the hostname wwwserve01 redis-cli<<'EOF' sadd wwwserve01:classes rabbitmq sadd wwwserve01:classes redis smembers wwwserve01:classes EOF
14. What Next Create a WebUI. Give it access controls. What happens if REDIS is unavailable ? - build with redundancy, redis replica’s etc - how do we resolve variables without REDIS
15. Compliance and audit reporting Audits don’t have to be painful. Puppet Enterprise gives you confidence that you’re meeting regulatory requirements by enforcing a desired state and provides full reporting capabilities for when the auditors arrive.
16. Patching via mcollective Currently looks like this mco rpc package checkupdates mco rpc package update package=openssh -F "hostname=mytesthost01" ultimately we would like to patch using a mcollective agent that understands yum mco rpc yum install yum-security; mco rpc yum update --security;
17. Codebase • Have PCI compliant code base ◦ RHEL Stig project has some great examples, DISA, NSA,DoD • Aqueduct describes some secure manifests that include classification references
18. Change Management • introduce change via a standard workflow - no ad hoc changes • Have a workflow for releases. • Use revision control, svn, cvs,mercurial,cvs • Ensure you can show which release is currently deployed. Tag a release. • Have your baseline module perform all the usual stuff, assign it to common. Add pci compliance code after that.
19. Using the Dashboard to report compliance • Allow auditors to gain visibility into your configuration, point them at the current release and • say 'that's the version we are running' • Show the auditors your puppet manifests and then point them at the dashboard. ◦ - The Sea of Green :) ◦ - The sea of green means compliance !
21. #!/bin/bash echo "hiera classes" hiera classes echo "" echo 'hiera classes ::clientcert="wwwserve01" -a' hiera classes ::clientcert="wwwserve01" -a echo "" echo 'hiera ntp ::sig_pod=sig4_sgs -a' hiera ntp ::sig_pod=sig4_sgs -a echo "" echo "" echo "ntp values in common with no extra facts" redis-cli<<EOF smembers common:ntp EOF echo "ntp values ::sig_pod=sig4_sgs" redis-cli<<EOF smembers sig4_sgs:ntp EOF