8 simple Tips to make your Docker Container more Secure
Remember when it was enough to install PHP on your Apache server? Take care of your scripts, take care of your server. That’s it!
I noticed that people become overwhelmed with the number of new topics and technologies. Now you are expected to know Docker, Serverless, Kubernetes, AWS, and many more.
“The more components your software has, the more difficult it becomes to keep everything secure.”
That’s why I have put together eight simple tips to step up your container game.
TIP 1: USE SECURE IMAGES
Secure images are a simple but effective method to make your deployments more secure. You “just” have to pick the right images. But when you go to the Docker Hub you can find tons of images and might be overwhelmed.
An easy way to avoid problems is to only use verified and official images unless you know exactly what you’re doing.
Everyone can upload images to the Docker Hub. And malicious software can easily build into these images. This can even happen when not intended by the creator.
There are three tags that help you to choose the image:
- Docker Certified: the gold standard, tested, build with best practises and passed security requirements
- Verified publisher: images which are published and maintained by a commercial entity, e.g. MySQL Server EE.
- Official images: images which are officially provided by Docker. This includes base OS repos or other open source software.
On top of the verification by Docker, you can test the image by using a vulnerability scanner. Trivy or clair are good starting points.
TIP 2: Change the default user
So you’re looking for a tip that you can apply directly to your containers? Well, here you go:
Please change the default user inside your container. When you create a Docker container you are root by default — unless you change it manually.
If someone is able to break your application and it runs with root privileges, the chances are high that the attacker will also inherit these privileges. So it is better to disable them with a few lines of code!
You can define this either in your Dockerfile, Docker run command, or in the docker-compose file.
TIP 3: Container Hardening
Your container is probably running any kind of web server. Therefore, it’s necessary to apply the same security standards on containers as you would apply on any other server.
To harden your container you can use the same tools and best practices you would on a virtual machine. If you are new to this topic, you can take a closer look at the following links: AppArmor, SELinux or grsecurity.
The good thing with containers is that you can set up a base image with best practices and re-use it to build all your applications!
TIP 4: Secret management
Everyone who is working with containers sooner or later asks themselves the same question: where should I store my credentials? Where should I enter the passwords for my database?
I hope you’re not just pasting them in your source code and uploading them to GitHub. You might have previously entered them manually when you started your application or stored them in the environment variables.
However, on a container landscape you need a more sophisticated solution, especially because you constantly restart your containers when scaling up or down.
What you should use instead are secrets.
The easiest way to use them is direct with your cloud provider for example with the AWS Secrets Manager or the Key Vault on Azure. But there are also self-hosted options like the HashiCorp Vault. You can even automatically rotate or renew the secrets and certificates.
When you are hosting your containers with Kubernetes you should also use Kubernetes Secrets, which are a native Kubernetes resource.
TIP 5: Updates
I know what you think: updates are not that interesting. But updates in containers are still as important as on every other server!
You don’t want your website to get hacked just because you were too lazy to rebuild your images!
That doesn’t mean you should always go with the latest images. Take your time to consider which version is appropriate for you and check if there were security updates — especially when you use containers that contain applications like WordPress.
Therefore, you should visit Docker Hub from time-to-time and check for updates!
TIP 6: Monitoring
I think this is a tough one. You can invest a lot of time in monitoring. Maybe nothing happens — if you’re lucky.
But unfortunately that is not always the case.
A few weeks ago, I had an incident on a personal blog. As I hadn’t enabled the monitoring function, I wasn’t aware that users were unable to visit the website anymore!
The upshot was that someone called me out on Twitter and said that the website is down, meaning the whole situation was a little embarrassing.
So make sure you set up your monitoring system!
Good starting points are Grafana and Prometheus, the Elastic Stack, and also the standard monitoring tools of your cloud provider.
TIP 7: Resource Limiting
Resource limiting should be the 101 of container orchestration — but despite this, a lot of people forget to implement it. This means that you specify how much memory or CPU can be consumed by your app.
The topic becomes more relevant when you start to work with a container orchestration like Kubernetes because the platform needs to know how to distribute the load.
What a lot of people don’t know is that you can do this with Docker and docker-compose too!
TIP 8: Bonus Tip
Secure your host system. It may seem obvious, but once the system is up and running, people tend to stop caring about the host.
Make sure you have all the updates installed, check your configuration, and check your firewalls.
And most importantly — take your time. Don’t rush when setting it up and keep your system clean. Because if the host is screwed up, your containers will probably be gone, too!
