Configuration management is a great tool for helping with hardening and securing servers. But with any addition of new technology comes a new attack vector: Who watches the watchers?
Security is painful. Luckily the invention of configuration management tools has made this process easier, by allowing repeatable configuration for common hardening. However there comes a catch-22: How do we harden the configuration management itself?
When you have a tool that enables you to change systems at a fundamental level, it's a fairly tempting target for malicious agents, and one that would cause a lot of problems if compromised.
We'll be discussing some general patterns we can use to mitigate these problems: - Whitelisting "master" API's - Encrypting sensitive data - Adding a security element to code review
And we'll talk about some application specific options for some of most popular tools out there, such as Puppet, Chef, Ansible, cfengine and Salt.
Merge: 783d425 1743488
Author: Peter Souter <firstname.lastname@example.org>
Date: Mon April 1 23:47:43 2030 +0000
Turned off SSL, we don't need that right?
also password is now password123
USE THE SAME SECURITY BASELINE FOR
ANY SORT OF SYSTEM:
NO DIRECT INTERNET ACCESS UNLESS ABSOLUTELY NECESSARY
USE BASTION HOSTS FOR DIRECT INTERNET ACCESS
MIRROR REPOS AND ARTIFACTS
KEEP PACKAGES UP TO DATE AND PATCHED
SENSIBLE FIREWALL RULES
> Get your data out of your code
> Encrypt it and control access
> Most normal security conventions apply
> Follow best practices from communities and
> Auditing and gating help
> Work together! :)