This is an old talk which I think is still fairly relevant in 2020. Apart from this talk I co-authored a book on the subject Security Automation with Ansible 2
System Hardening using Ansible
I presented this talk at AllDayDevOps 2016. It was fairly well received and the ideas presented here resonated with the audience.
If you are here for the materials, please follow the links
|Slides on Speakerdech||Slides on Speakerdeck|
|Slides as PDF for download||Slides as PDF|
|Video of the talk||YouTube Video|
![Application Deployment + Configuration Management + Continuous Delivery]()
Ansible offers a flexible approach to building a SecOps pipeline. System hardening can become just another software project. Using it we can do secure application deployment, configuration management and continuous monitoring. Security can be codified & attack surfaces reduced by using Ansible.
Ansible is tailor made for doing declarative security
- Ansible removes the need for an agent and uses SSH for all communication
- Ansible uses playbooks to execute a series of commands/modules on the target
- Managing Ansible inventory is a simple as editing a text file
- Ansible follows the concept of idempotent, which translates into describing the state that we would like the system to be in.
Ansible is for IT Security Automation
Secure Channel for data transmission and host authentication
Since Ansible is riding on SSH for transferring data and allows for ensuring that the host we are connecting to, is the host we wanted to connect to we can be assured that our data in transmission is safe and our commands are executing on the server we wanted to run them on.
Playbooks are structured instruction manuals
While each command on the server that we execute using Ansible is separate, we can define them in a sequence. Additionally we can define variables which are picked up when the playbook is running to create generic instruction manuals.
All playbooks are written in a YAML providing us with
- Structure that we can learn and train on
- Since playbooks are text files, we can use Git to do version control on them
- By using Git or another version control software, managing the playbooks is just like managing any software project.
- Therefore infrastructure as code but for security
Playbooks need to operate on hosts
Managing Ansible inventory is done by using text based files in which we define the servers and their categories. A structured text file with up to date inventory can be generated by hand (not desirable if the servers come and go), but they can be easily generated using any tool capable of giving us text output.
The concept of being idempotent
The concept that change commands should only be applied when they need to be applied, and that it is better to describe the desired state of a system than the process of how to get to that state. Our job is now to ensure that we need to define what constitutes a secure and hardened system.
By using various best practices like
- CIS Benchmarks
- NIST Guidelines
- Distribution specific guidelines
- Application security specific guidelines
Security hardening is the process where we identify insecure default configuration present on a system and apply changes that will change the configuration to secure values.
The process can be applied to all the layers
|Network||Enable firewall with restrictive rule sets|
|Transport||Enable TCP wrappers for a service/subnet matching|
|Application||Enable web server configuration to allow white listed access to administration resources|
|Kernel networking parameters||Enable defences for the networking stack that work at a host level|
Applications that get deployed using the DevOps paradigm sometimes can be insecure to begin with.
For example, a developer copies over the release folder from the
git repository without removing the
If additional hardening of the web server configuration is in place
- Disallow access to .git folder
- Disallow Directory Listing by default
Then this weakness can’t be exploited. Otherwise this can expose the entire source code of the application along with any additional secrets such as database username, passwords, API keys etc.
Configurations change from dev to staging to prod. By ensuring the change is done at the playbook and the playbook is applied, configuration management is simplified considerably. Each change can become part of a git commit and if a security incident is being investigated, the incident responders can get a fair idea which commit may have caused the issue.
By scheduling regular scanning of the state of the system, based on playbooks already created, we can create a historical time line of various parameters that should be measured for security.
A tool like Ansible Tower, although a paid tool, can be useful. We can always evaluate other free and open source options to do the same.
This talks and demo is relevant and useful for any practitioner of DevSecOps.
- It introduces the concepts of declarative security
- Showcases one of the tools (Ansible) to embrace DevSecOps in a friction free no expense required manner
- Implements security architecture principles using a structured language (YAML) as part of the framework (playbooks) which is ‘Infrastructure As Code’
- Gives a clear roadmap on how to find the best practices for security hardening
- Covers how continuous monitoring can be applied for security