Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Docker Security and Best Practices

blog.docker.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Understanding Docker Security and Best Practices

#11

Post by zaroth »

A large part of the document boils down to 'run with defaults', 'setup auditing', and 'check file permissions', 'drop unneeded capabilities', 'define sane limits', 'centralize and rotate logs', and 'make backups'. These are all really great baseline steps. There were also I think a few Docker-specific points worth highlighting;

- Run with -icc=false. This should have been the default but isn't for legacy reasons I think. By default there is no firewall between containers. icc=false turns the inter-container firewall on. This is a pretty basic one, but easy for new docker users to miss.

- Host port mapping (e.g. -p 80) by default binds to 0.0.0.0:80 on the host container. This could inadvertently expose your internal services to unexpected interfaces. Specify the host IP you want to bind to explicitly (e.g. -p 127.0.0.1:49123:8080)

- Run inside containers as non-root. Most Dockerfiles you come across will run as root inside the container. In your base image, 'RUN useradd' and in your Dockerfiles add a 'USER' directive, and start the container with -u .

- Set root file system as read-only inside the container. It enforces the best practice that the container should be immutable anyway.

- Instead of --restart:always, try --restart=on-failure:5 to avoid a possible DoS or excessive flapping. Not sure if I 100% agree with this, but it's an interesting suggestion.

Re: Understanding Docker Security and Best Practices

#12

Post by kentonv »

ams6110 wrote: post #3

Why do I need to take any action to securely deply Docker containers? Why aren't they secure by default. What I should need to study is how to run them insecurely, should I have that need. Secure should be the default mode.

Docker aims to run arbitrary off-the-shelf Linux apps (and even entire distros) with no modification. Such apps are largely authored to work in traditional environments where security is fairly ad hoc and requires fiddly user configuration. Although in many cases it would not be hard to adapt them to a uniform security model, any such requirement would mean that Docker would only support apps that have been "ported" to that model, which would make it a very different kind of platform not suited for the same use cases.

For an example of the opposite approach, look at Sandstorm.io. It forces apps to conform to a strict platform-defined security model where things are isolated "by default" and from there the user can use friendly UI to grant permissions as necessary. This means that currently there are only some 30 apps available on Sandstorm but they are (or will be, when Sandstorm reaches 1.0) "secure by default", or at least much more so than other platforms could claim.

(Disclosure: I'm the lead developer of Sandstorm.)

Re: Understanding Docker Security and Best Practices

#13

Post by bkeroack »

This document says essentially nothing of significance--it is a marketing piece. There are no details of exactly how resilient a containerized process is to attack, how to prevent "escaping", etc. The general consensus (if I'm not mistaken) is that containers are for deployment/operational convenience and should not be relied upon for security, but you would have no idea if you only read this so-called whitepaper.

Re: Understanding Docker Security and Best Practices

#14

Post by oskarpearson »

yarrel wrote: post #10
markbnj wrote: post #7

Earlier quoted context omitted.

I'm with you. See a link to a white paper on Docker security. Oh boy! Click on link. See registration form. Bummer.

I just downloaded the whitepaper without registering. Maybe they stopped requiring it? Discouraging people from following security best practice would be counter-productive.

It seems they have stopped requiring registration. Clicking on the "Introduction to Container Security" page takes you straight to cloudfront.

Re: Understanding Docker Security and Best Practices

#15

Post by general_failure »

zaroth wrote: post #11

A large part of the document boils down to 'run with defaults', 'setup auditing', and 'check file permissions', 'drop unneeded capabilities', 'define sane limits', 'centralize and rotate logs', and 'make backups'. These are all really great baseline steps. There were also I think a few Docker-specific points worth highlighting; - Run with -icc=false. This should have been the default but isn't for legacy reasons I th…

I have never managed the readonly container to work.

/var/run needs to be writable. /tmp needs to be writable and so on. I gave it a shot again today:

$ docker run --read-only=true -ti ubuntu:14.10 touch /tmp/foo

touch: cannot touch '/tmp/foo': Read-only file system

How is this supposed to work? There is little to no information on how this feature works. Can you give me a pointer?

In addition, restart:on-failure appears to have issues if docker itself crashes.

Re: Understanding Docker Security and Best Practices

#17

Post by kentonv »

general_failure wrote: post #15
zaroth wrote: post #11

A large part of the document boils down to 'run with defaults', 'setup auditing', and 'check file permissions', 'drop unneeded capabilities', 'define sane limits', 'centralize and rotate logs', and 'make backups'. These are all really great baseline steps. There were also I think a few Docker-specific points worth highlighting; - Run with -icc=false. This should have been the default but isn't for legacy reasons I th…

I have never managed the readonly container to work. /var/run needs to be writable. /tmp needs to be writable and so on. I gave it a shot again today: $ docker run --read-only=true -ti ubuntu:14.10 touch /tmp/foo touch: cannot touch '/tmp/foo': Read-only file system How is this supposed to work? There is little to no information on how this feature works. Can you give me a pointer? In addition, restart:on-failure app…

Once inside the container, you need to mount a tmpfs at /tmp, and another one at /run (which /var/run usually links to).

E.g.:

    mount -t tmpfs -o size=256M tmpfs /tmp
(I'm not sure if/how you can make Docker do this automatically. I'd imagine there's a flag or something.)

Re: Understanding Docker Security and Best Practices

#18

Post by doomrobo »

kentonv wrote: post #17
general_failure wrote: post #15

Earlier quoted context omitted.

I have never managed the readonly container to work. /var/run needs to be writable. /tmp needs to be writable and so on. I gave it a shot again today: $ docker run --read-only=true -ti ubuntu:14.10 touch /tmp/foo touch: cannot touch '/tmp/foo': Read-only file system How is this supposed to work? There is little to no information on how this feature works. Can you give me a pointer? In addition, restart:on-failure app…

Once inside the container, you need to mount a tmpfs at /tmp, and another one at /run (which /var/run usually links to). E.g.: mount -t tmpfs -o size=256M tmpfs /tmp (I'm not sure if/how you can make Docker do this automatically. I'd imagine there's a flag or something.)

You could use the CMD keyword in the Dockerfile to ensure that that's run every time the container is started

Re: Understanding Docker Security and Best Practices

#19

Post by dordoka »

zaroth wrote: post #11

A large part of the document boils down to 'run with defaults', 'setup auditing', and 'check file permissions', 'drop unneeded capabilities', 'define sane limits', 'centralize and rotate logs', and 'make backups'. These are all really great baseline steps. There were also I think a few Docker-specific points worth highlighting; - Run with -icc=false. This should have been the default but isn't for legacy reasons I th…

Regarding the -icc=false option, if you want to do it by default to all containers, just modify the docker daemon's options adding --iptables=false [0] and restart the daemon.

[0] https://docs.docker.com/articles/networking/#between-contain...

Re: Understanding Docker Security and Best Practices

#20

Post by steilpass »

zaroth wrote: post #11

A large part of the document boils down to 'run with defaults', 'setup auditing', and 'check file permissions', 'drop unneeded capabilities', 'define sane limits', 'centralize and rotate logs', and 'make backups'. These are all really great baseline steps. There were also I think a few Docker-specific points worth highlighting; - Run with -icc=false. This should have been the default but isn't for legacy reasons I th…

> - Run with -icc=false. This should have been the default +1

But I would add: not just form a security perspective but also from a architecture perspective to enforce encapsulation.

Have been wondering about this too: http://stackoverflow.com/questions/29952937/why-is-inter-con...

Post reply on HN