Docker Security Threats and Hardening Guidelines

What’s a Docker?

Docker is a virtualized scalable solution that is currently replacing classic virtualization solutions like hypervisors. Why? Because Docker requires far fewer resources, is easy to deploy and starts fast. This allows you to have higher density, meaning that it allows you to run more services on the same hardware unit, thereby reducing costs.

Why Docker Can Be Beneficial to You

• It comes as a containerized standalone package, which makes it easy to build, manage, and deploy at ease.
• Dockers are multi-versatile, meaning we can build and containerize an application with components written in any languages, which is a plus.
• Dockers can run in conjunction with the host operating system, utilizing the same kernel and system resources, which minimizes the complexity of other virtualization solution, i.e running on top of the host operating system instead of working with it.
• Dockers can be effectively orchestrated with Kubernetes (an orchestration solution), which helps in managing multiple Docker containers much less complex.

This is why the use of Docker or container technology, in general, is on the rise. Since the advent of Docker in 2013, according to a datadog report, 20 percent of all hosts across environments run on Docker. But, technologies with such rapidly growing adoption rates invite high volumes of malicious intent, thereby mandating robust security considerations. This is why, further to our previous Docker security listicle, I’ve penned down the five most pertinent security threats to your Docker deployments and ways in which you can secure it best.

• Stolen Sensitive Secrets: It's always a bad idea to store API keys and passwords of critical infrastructure unencrypted. Some hardening tips are:

• Always set container file system to read-only.
• Run the application with a least privileged user.
• Never use environment variables to share secrets.
• Never run a container with root privileged i.e --privileged flag.

• Poisoned Docker Images: “Not all Docker images are malware free." Indeed, this statement is true. Obtaining Docker images from untrusted sources would eventually be malware infected or might have outdated versions of software which might have known-vulnerabilities.

• Always verify Docker images with MD5/SHA1 hashing.

• Breaking out of a container: It is highly likely an attacker could break out of a container to gain access onto the host if the Docker is misconfigured with weak ACL, SETUID/SETGID binaries etc.

• Defragging SETUID/SETGID binaries that might help an attacker to gain a root shell.
• Always set container file system/Volumes to read-only, as this will help a third party to not gain access or execute malicious payloads.
• Always run a Docker with a least privileged user.
• Never run a container with root privileged i.e --privileged flag.
• It is advisable to turn off Inter-container communication unless needed.
• Always use packages that are absolutely needed for running the application.

Here’s Why This Would Work

Defragging  SETUID/ SETGID binaries  -Setuid/setgid  binaries are the endpoints for the attackers to privilege escalate to root, i.e leading to a complete compromise of the host.

Disable them by  ```RUN find / -perm +6000 -type f -exec chmod a-s {} \; \ || true``` 

• Denial Of Service (DOS): All containers share the same kernel resources as the host does. It is quite possible to over exhaust resources, hence the fellow Dockers would starve out, which would lead to denial of service.

• Try to allow required kernel resources from the VM level or have some kind of memory limiter in place for not over exhausting resources.

• Kernel Exploit: It is crucial to not use old/obsolete kernels on Dockers as they would induce the risk of using exploits that may lead to a kernel attack that would cause instability or privilege escalation, which would end up having the host compromised. Some ways to mitigate the attack can be :

• Try to allow required kernel resources from the VM level or have some kind of memory limiter in place for not over exhausting resources.
• Always use packages that are absolutely needed for running the application.
• Never run a container with root privileged, i.e --privileged flag.
• Always run a Docker with a least privileged user.

In case you run into roadblocks implementing these safeguards drop a comment here, and I promise you a response!