Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What security concerns should I have with Docker? How should I go about locking it down? #17

Open
BretFisher opened this issue Mar 18, 2018 · 4 comments

Comments

@BretFisher
Copy link
Owner

@BretFisher BretFisher commented Mar 18, 2018

A common question I get.

@BretFisher

This comment has been minimized.

Copy link
Owner Author

@BretFisher BretFisher commented Jun 26, 2018

Security recommendations for Docker on Linux servers, in order of priority.

First, research and learn

  1. Watch my DockerCon session on production Docker concerns. This gives you a good baseline of production things before you dive into specific security concerns.
  2. Read the Docker security guide.
  3. Read some blog posts on security tools and topics. These skims a lot of things I list here: https://blog.sqreen.io/docker-security/ and https://sysdig.com/blog/20-docker-security-tools/

Then consider each of these a project to implement. Easier ones at top:

  1. Just use Docker. Running an app in a default-settings Docker Linux container greatly reduces your risk profile vs. just running that app on a full Linux VM OS. It applies default apparmor and seccomp profiles, and also uses a small whitelist of Linux Kernel capabilities.
  2. Scan your hosts for proper Docker config. Run https://github.com/docker/docker-bench-security and see if you can improve things with your setup. It checks the host config and how Docker is installed and gives you red/green metrics. Note the goal isn't to have all green, but to understand the reds you have and decide if you're OK with that.
  3. Don't run apps in containers as root. Use USER <appname> to prevent your app from running as the root user in the container. Often there is already a user created in official images, but just not enabled until you add the USER line in your own downstream Dockerfile.
  4. App and OS dependency scanning. You want to scan for CVE's in both your app dependencies (npm, pip, composer, etc.) and OS dependency's (apt, apk, yum). There are three main stages where you can do this: git commits, image build, and after image build:
    • For app dependency-only CVE scanning in your git repos, use something like Snyk (or just GitHub built-in) to scan your git repos for known vulnerabilities. This is great for shift-left security.
    • Scan during image build. Aqua Security Microscanner does OS CVE scanning inside a container build, which I think is very handy, but doesn't look for app dependencies and doesn't have the full Alpine support if you need it. Compliments the git-repo scanning above.
    • Scan images after build or on servers. Docker Hub used to do this for a fee, now you'll need Docker EE or 3rd party. I think the best open-source scanner right now might be Aqua Security's Trivy which claims to have the most complete scanner, especially for Alpine-based images. It scans images from outside Docker. This could replace the above two methods.
  5. Don't Expose the Docker TCP Socket - This is hard to get right, and mostly ends in tears (see below comments). As of 2018 you can now use docker's built-in SSH connection method to remotely control the Docker Engine without exposing anything other than SSH. This is perfect for remote docker admin and CI/CD solutions. Here's a demo of using it with the DOCKER_HOST=ssh://user@host environment variable, and here's a demo of using it with the new docker context in 2019.
  6. Enable "user namespaces" so even the root user in a container isn't really root on the host. (so even if a hacker broke out of the container they are just limited user on host OS.) This won't work in all use cases, so consider having different sets of servers where the high-security set has user namespaces enabled and runs all your apps that still work in that setup. Then run the rest on the default Docker config on a different set of servers.
  7. Runtime Bad Behavior Monitoring Sysdig Falco has the great idea of watching your containers for unusual behavior, like an exec command, or bind-mounting sensitive host files in /etc, or something trying to mess with certain files in a container... it will watch the system and log these actions (based on a default set of rules that you can add to). You can run this small binary on every host, and have it log to a central location.
  8. Content Trust, which has to do with signing your code, and then the images all the way through the CI/CD pipeline and finally making certain your servers won't deploy new containers on images you didn't cryptographically trust. Docker does this, Docker Enterprise makes it easier, also other platforms may do this.
  9. Later, check out AppArmor, SELinux, Seccomp, and Linux "capabilities" for locking down what a container can access/do on host. There are already defaults running in Docker, but they can be customized per container if you want that next-level hardening. It's something you'll need to customize for each image you want to run, so I don't recommend them as a first step, but good for systems you really want to lockdown.
  10. Docker root-less. This is an option for running the dockerd daemon as a normal user on the host. It's new in 2019 and if you already do all the above, it may be more work then it's worth to use this, but it can also be handy when you don't have local admin, or you're interested in CI automation without local admin. See Docker's blog post. Note the biggest limitation is lack of virtual networking (which still requires root). Watch this DockerCon session on it, and install it with a script as a normal Linux user https://get.docker.com/rootless
  11. Besides Docker EE, there are 3rd party platforms that cover many of these features like https://www.blackducksoftware.com , https://www.aquasec.com/, https://sysdig.com/, and https://www.twistlock.com/
@BretFisher

This comment has been minimized.

Copy link
Owner Author

@BretFisher BretFisher commented Oct 18, 2018

For questions about "is docker secure" (what does that even mean, nothing is perfectly secure unless it's turned off and removed from the internet):

Realize that a default Docker install on Linux doesn't open ports to expose Docker remotely. This is a good thing. Even Swarm Mode only opens ports for cluster communications and requires mutual TLS auth in all cases. In version 18.09 we can even remotely control Docker Engine through SSH, preventing 90% of the reasons for exposing TCP ports for remote management in the first place, which is very exciting.

The headlines we see about container security concerns largely revolve around two things:

  1. Point in time issues around bugs: Linux bugs, like Dirty COW, which was a Linux Kernel bug that allowed something running in a container to break out of the container. It was a privilege escalation. This was a big deal but was not docker-specific. It was also not remotely executable.
  2. Ongoing issues around improper config: Enabling the Docker Engine for remote TCP connectivity without authentication (the fault of a bad admin), or deploying Kubernetes and not enabling proper explicit auth and RBAC. You can google and see lots of cases where Kubernetes was improperly configured and you could control the cluster without a password.
@BretFisher

This comment has been minimized.

Copy link
Owner Author

@BretFisher BretFisher commented Oct 23, 2019

Internet news: Graboid: First-Ever Cryptojacking Worm Found in Images on Docker Hub

This goes back to the same things I'm saying above:

  1. Don't run other people's images unless you trust the source. Docker Hub, like most package managers and app stores, doesn't scan every upload to ensure safety.
  2. Don't enable the Docker TCP socket unless you secure it. Docker warns and educates you on the proper TLS auth for it, and disables it by default. Generally, it's not needed anyway, as we can now use SSH for Docker CLI-to-Engine connections, which is easier to setup, harder to mess up, and should work in 90% of remote management cases. Note that there are authz plugins for Docker Engine like Docker Enterprise, https://portainer.io, and more that will provide remote TCP HTTPS access to the API, and protect it properly. These are fine too.
@BretFisher

This comment has been minimized.

Copy link
Owner Author

@BretFisher BretFisher commented Nov 6, 2019

I did a whole YouTube Live Show on this!

Docker Security Top 10
https://www.youtube.com/watch?v=rqsrmeLn65w

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.