This post was originally published here by cliff turner.
If we could call out two things that are growing in importance in 2018, it’s containers and compliance. Why? Well, penalties for data breaches are on the rise, all the while organizations are under increasing pressure to expand their DevOps practices and increase their agility, which leads teams to turn to containers.
And while containers usher in plenty of opportunities, they can lead to compliance headaches if they aren’t properly configured. Hint: automating your security will be essential for this process.
To prepare for annual compliance checks, and to avoid data breaches, enterprises must understand how containers affect security, and build a strategy to secure them. So let’s address the elephant in the room: Can you use containers in a compliant environment? Absolutely.
Here are our top 10 tips for how you can create a containerized environment that works with your compliance needs. It’s easier than you think!
1. Secure the host – All security practices should be applied to the host. Always check your hosts for misconfiguration, vulnerabilities, unapproved users, and unknown processes. And always patch your OS and Docker engine!
2. Secure the Docker engine and all images – Now that you’ve taken the necessary steps to secure your host, it’s time to secure your Docker engine. Remember that in order to pass a compliance audit, all the layers of your container workloads must be secure: from host, to engine, to image.
3. Secure the orchestrator – Whether you are using Kubernetes, Mesos, or Amazon ECR, these systems have superpowers and need to be secured. Always turn on logging and make sure they are not running as ROOT. Control access to these systems tightly.
4. Don’t use images from unknown sources – Make sure you pull base images into your private registry before building anything off of them. This ensures that your image analysis tools have a chance to run before pushing images to production.
5. Scan all images for security issues – To start, scan for misconfigurations, secrets, and vulnerabilities.
6. Enable logging and auditing – the best way to do this is to:
- Run Docker inspect and store the results for all images at start, running, and stop
- Have your host logging turned on
- Have your Docker engine logging turned on
- Have each containers’ logging turned on and exported
7. Don’t run containers as ROOT – Why? Since ROOT in a container has ROOT on the host (and thus ROOT on every container on that host), the blast radius will be huge for a breach if even just one container has this insecure setting.
8. Don’t put secrets (AWS API credentials for example) or source code into containers – As we all came to learn thanks to the VINE source code data leak, source code and secrets in images and containers can easily be exploited by criminals.
9. Run containers as ‘read only’ unless troubleshooting – Doing this will protect your containers from unauthorized changes. It will also reduce administrative overhead by preventing you from checking in runtime and dev for issues. Simply check your issues in dev.
10. Isolate hosts into different zones to separate scope – This will ensure that your auditors don’t go bonkers trying to separate ‘out of scope’ and ‘in scope’ containers.
This list may seem daunting, but I assure you, it’s straightforward, and more importantly, necessary. Taking the time to set up these basic security settings from the start will make it far easier to pass audits for your applications running in containers. There’s no time like the present to save yourself the headache.
