DEV Community

Cover image for Docker security essentials
Kevin Naidoo
Kevin Naidoo

Posted on • Updated on

Docker security essentials

Docker and docker-compose make life super easy - just using a declarative YAML file. You can easily spin up services that are portable and will work just about anywhere.

What about production; are you using docker-compose?

In this article, I will discuss some common security flaws to watch out for.

The firewall bypass

In docker-compose you usually would do something similar:

ports:
  - 6379:6379
Enter fullscreen mode Exit fullscreen mode

If you run this command on your host:

netstat -tupln | grep 6379
Enter fullscreen mode Exit fullscreen mode

You should get this output:

tcp        0      0 0.0.0.0:6379            0.0.0.0:*       
Enter fullscreen mode Exit fullscreen mode

Docker usually manages its own firewall rules. Depending on your host system this would bypass your host's firewall, and expose this port to the entire internet, thereby allowing anyone to connect to your server on that port and run malicious code.

How to get around this issue?

At a basic level, just don't expose ports externally - usually, you would just need to expose ports: 443 and 80. If this is not an option - you can try the following:

  • Add a cloud firewall in front of your server, so even if your OS firewall is bypassed - traffic will be blocked on a network level.
  • Prefix your port with : 127.0.0.1:
    ports:
      - 127.0.0.1:6379:6379
Enter fullscreen mode Exit fullscreen mode

Running as root

The root user inside a Docker container is not necessarily a security risk in itself, as Docker isolates containers. Still a vulnerability in your: mounts, your application, the docker daemon, the kernel, and so forth could allow attackers to break out of this isolation and run root-level exploits.

This is why as a best practice, you should change the user that your docker containers run as, and give that user as little permission as possible.

Here is an example:

FROM golang:1.20.4-buster

ENV USER=docker
ENV UID=1000
ENV GID=1000

RUN addgroup --gid 1000 $USER

RUN adduser \
    --disabled-password \
    --gecos "" \
    --gid "$GID" \
    --uid "$UID" \
    "$USER"

USER $USER
Enter fullscreen mode Exit fullscreen mode

Podman - podman.io

Well, this is not exactly a security hole, however since Podman runs containers without a daemon process, and these containers are essentially rootless - this by very nature will improve security overall.

Podman is compatible with the OCI standard. Therefore, it can be a drop-in replacement for the docker cli commands you are already used to.

Pulling images

Pulling images from a third party just like with any other type of software, is a risk - it's always possible that these can be compromised.

You should scan all images before utilizing them in your stack. There are many services and tools out there for this very purpose. One such tool is Scout.

Even with a clean image, it's still possible for there to be a breach in your containers - due to some unpatched security loophole.

To get around this issue - I strongly suggest scanning your containers often using something like Synk or an open-source alternative such as : falco

Conclusion

Make sure you are frequently pulling in the latest patches for your system so that loopholes are plugged in as soon as possible.

No modern system is 100% secure. You have to proactively ensure that you follow best practices such as regular security updates, regular security scans, having a solid firewall, and ensuring your host system is always running a supported, preferably LTS version of whatever distro you are using.

Top comments (0)