Team we45
October 3, 2018

Docker Security Threats and Hardening Guidelines

What is 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.

Here’s a quick 101 of why the use of 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 application with components written in any languages which is a boon.
  • Dockers can run in conjunction with the host operating system, utilizing the same kernel, 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 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% 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 container security considerations. Which 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
  1. Always set container file system to read-only.
  2. Run the application with a least privileged user.
  3. Never use environment variables to share secrets.
  4. Never run a container with root privileged i.e --privileged flag.
  • Poisoned Docker Images - “
  • Not all Docker images are malware free”. Indeed the 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.
  1. Always verify Docker images with MD5/SHA1 hashing.
  • Breaking out of a container -
  • It is highly likely a 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.
  1. Defragging SETUID/SETGID binaries that might help an attacker to gain root shell.
  2. Always set container file system/Volumes to read-only as this will help a 3rd party to not gain access or execute malicious payloads.
  3. Always run a Docker with a least privileged user.
  4. Never run a container with root privileged i.e --privileged flag.
  5. It is advisable to turn off Inter-container communication unless needed.
  6. 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.
  1. Try to allot 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 :
  1. Try to allot required kernel resources from the VM level or have some kind of memory limiter in place for not over exhausting resources.
  2. Always use packages that are absolutely needed for running the application.
  3. Never run a container with root privileged i.e --privileged flag.
  4. 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.