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.
2. 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
67. git-crypt was developed so the
secret material could be
protected without having to
remove it from the repository
(which is what Wikimedia had to
do).
- ANDREW AYER
98. ACTIVITY WHEN YOU DON'T EXPECT IT
4XX, 5XX ERRORS FROM YOUR CONFIG
MANAGEMENT INFRA
UNEXPLAINED INCREASES IN THE
TEMPERATURE OF YOUR MACHINES IN
THE DATA CENTRE
GENERAL ERRORS IN VARIOUS LOGS
106. 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
128. CONCLUSION
> Get your data out of your code
> Encrypt it and control access
> Most normal security conventions apply
> Follow best practices from communities and
organizations
> Auditing and gating help
> Work together! :)