9 ms·

The Docker security philosophy is “secure by default”

63 points by pella 10y ago

merb 10y ago
without docker the software is even safer. Actually for all people below, here are my reasons: Docker adds another Layer. This also adds another attack target (docker). Saying a software is more secure while adding another layer is just naiv. Docker is good for some companies and it definitiv is true that you can make it to run a PaaS, it's still not more secure as the world before. Also some other people also pointed out other things. With docker you add a lot of complexity to your actual software, that is negligible if your big since you have a total different set of problems. Still when it comes to docker it's mostly buzzword bingo. I mean just looking at the table... oh god it's like half the things there could just be done without docker in a way more secure way, without LXC, Docker or RKT. Also I always tought that docker should make the deployment easier, which would be a hugh bonus in security since the process of understanding and everything beyond would be more understandable. however the more docker grows the worse the complexity gets. Docker once looked shiny but than the enterprise hit it and it's direction more and more makes it less secure since they try to add more and more stuff and stops focusing on the stuff docker was firstly invented. How could adding a ton of abstraction (which grows every release) making something more secure? I just keep that as an open question to everybody.
- ralmeida 10y ago
  Why, exactly? The article's argument is that containerization limits the vulnerable area - even if an attacker gains root access to a container, they still can't do as much damage as they would had they gotten root access in a host machine. I don't mean to sound adversarial - but what's your counterpoint to that?
  - api 10y ago
    Is that really true? I have always read that cgroups based containerization on Linux is kind of a joke and that root in the container more or less equals root on the host. Has there been significant improvement in this area lately?
    - ralmeida 10y ago
      I'm not familiar with that perception, any good reads on that?
      - raesene9 10y ago
        tends to be much older articles that had that perception, pre userns, seccomp, extended cgroup support etc.
    - wmf 10y ago
      The fix for that is user namespaces which is (finally) included in Docker. So yes, it has gotten better.
  - fapjacks 10y ago
    There isn't one. It's just a narrative regurgitated by people with an axe to grind. The anti-Docker crowd. User namespacing arrived in 1.10, which brought a lot of great possibilities for further compartmentalization with it. Alpine is the default base image. Lots of great, positive changes have gone into this blog post.
    - officialchicken 10y ago
      > Lots of great, positive changes have gone into this blog post. I'm not sure I agree, I'd offer some improvements: - Gartner "studies" are usually paid advertisements - The comparison table is missing columns for DOM0/1 VM's and BSD jails - Encryption in-transit or at-rest isn't mentioned - Nothing about key management or key rotation - Non-mutable / exported log files aren't in the defaults
      - bigmac 10y ago
        Great points, we're working on a bunch of this stuff. Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required. Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system. Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications. In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.
        rmoriz 10y ago
        How is the overlay network encrypted? I couldn't find any information. https://github.com/docker/docker/issues/24253 https://github.com/docker/docker/issues/24253 says it's not encrypted by default and must be enabled manually.
        10y ago
  - codemac 10y ago
    The bundling of all your software's dependencies into your container means that you can't upgrade 1 .so on a machine, and all software be updated. Great example recently was libgcypt's security bugs. You have to upgrade all containers, which requires figuring out which ones need upgrading. The concern isn't generally that someone will escalate and then delete some other container's filesystem.. it's that once they get remote execution in a container that has connections to your database, http to your discovery service etc, they can steal your customer information. I will say however that this post is showing that by using docker or frankly other well manicured execution enviroments, large swaths of attacks will hopefully not work (selinux & seccomp being great examples).
    - riskable 10y ago
      Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much. The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.
      - pmontra 10y ago
        I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?
        tayo42 10y ago
        Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...
- bigmac 10y ago
  This couldn't be further from the truth. Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArmor, SELinux), and capability dropping. These are all common sense security controls that aren't widely available because they're typically hard to use. Docker makes them defaults for everyone. This makes classes of remote attacks against applications far more difficult. Tangible example: read-only filesystems + mount namespacing make vulns that require filesystem modification or directory traversal far more difficult. At this point arguing against running in Docker is like arguing in favor of IE6's security model instead of Chrome's. Disclaimer: I manage security at Docker.
  - yid 10y ago
    You guys are doing a great job! Some security-related sandboxing options to docker run that people may not be aware of, which are hard to assemble individually from Linux pieces: * --read-only * --security-opt="no-new-privileges" * --cap-drop=ALL * --net="none" * --cpu-period= * --cpu-quota=
    - redtuesday 10y ago
      Is it intended that the last two have nothing after the equal sign? If yes, what does that do? There is also --pids-limit=<some number> against fork bombs. EDIT - this git repo has more links to security related articles etc. https://github.com/wsargent/docker-cheat-sheet#security https://github.com/wsargent/docker-cheat-sheet#security
  - nwmcsween 10y ago
    I argue against using docker but simply due to the fact that docker encompasses too much when everything docker does could be accomplished by simple single use tools like unshared, cgexec, etc. Git does this and it works very well.
  - cpuguy83 10y ago
    More detail on actual security issues (real CVE's) prevented just by using docker: https://docs.docker.com/engine/security/non-events/ https://docs.docker.com/engine/security/non-events/
- ralmeida 10y ago
  Reply to the edited comment: The reasoning that "more layers of abstraction necessarily equals less security" does not seem true to me. Granted, it increases the "surface area" that is exposed to attacks, and there's indeed a tradeoff involved, but this tradeoff may swing either way - either it does pay off or not. Taking this reasoning to the extreme, there are plenty of abstractions that pay off for secutiry. One simple example is that software written in Java (for example) is by default more buffer-overflow-resistant than software written in C, due to managed memory/bounds-checking. In this case, the tradeoff was performance vs security. > How could adding a ton of abstraction (which grows every release) making something more secure? One example is the "buffer overflow resistence" in Java vs C mentioned above.
  - merb 10y ago
    Actually we are a 100% Java Shop but the JVM has a lot of Bugs, Bugs that you won't have in C. Yes you can run into your own code smell, Bugs or whatever, but the same could happen on Java, too. The biggest problem with docker is the tone of stuff they try to put into. While most stuff is just possible without docker and the big abstraction. Hell you can start your programs under Linux with user namespaces just without docker. Actually trust me it's way easier to control a single stack instead of managing a stack on top of another. Especially networking is no fun. Maybe it's cool and easy / shiny if you can have everything in the cloud, but that just won't apply to everybody.
    - ralmeida 10y ago
      > the JVM has a lot of Bugs, Bugs that you won't have in C There will be different classes of bugs, of course, but I find it hard to believe that it will be more bugs, or more serious bugs, or most costly-to-fix bugs. Otherwise, your own company would have decided to use C instead of Java, right? > Hell you can start your programs under Linux with user namespaces just without docker Sure you can, but if Docker (or any other solution, for that matter) makes it easier or faster to do that, more people would do that. There's a more or less fixed number of work units to dedicate on a certain project, if you have to use them all to set up security solutions, your lunch will be eaten by other people. > most stuff is just possible without docker and the big abstraction Most stuff is "just possible" without any abstraction at all. However, one has to learn to leverage abstracted-away stuff, otherwise one will spend a lot of time and accomplish very little valuable stuff. > trust me it's way easier to control a single stack instead of managing a stack on top of another Easier does not equal safer, faster, or more business-valuable. > it's cool and easy / shiny if you can have everything in the cloud Not sure where "the cloud" enters the equation? You can use Docker (or whatever else) to manage even your on-premises stack. --- I don't know the specifics of your situation at all, but if your only argument against a particular piece of tech is "it abstracts away stuff, therefore it is worse", you might want to consider some self-reflection on whether you're not just suffering of NIH Syndrome (https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here)
shiftoutbox 10y ago
Umm they misspelled "you are a sucker by default" they had a brain fart and actually wrote "secure by default". I think someone was dreaming of OpenBSD.
hinkley 10y ago
If Docker is Secure By Default, then why is this issue 15 months old with no forward progress? https://github.com/docker/docker/issues/13490 https://github.com/docker/docker/issues/13490 It's not 'secure by default' if secrets are flying around through the system with no formal way to prevent it.
- bigmac 10y ago
  We are on the case right now. The solution is going to be really, really good. We had to get cryptographic node identity rolled out first and we're designing secrets management on top of that.
  - btreesOfSpring 10y ago
    this is a very nice and better than expected answer to hear.
  - hinkley 10y ago
    Why haven't you been forthcoming about this? If you're playing to the 'secure by default' crowd, they aren't going to just trust that you're on the case if you don't communicate. Platitudes are something people watch out for when security is on the line, and they'll chose another solution if they think you're full of shit. You have to show, at all times and all things, how you're thinking about the problem. 15 months of dead air is a lot to atone for.
- Feuilles_Mortes 10y ago
  I'm building a secret management solution for my team right now that will work securely with docker. I think it's pretty cool - I'll write how I'm doing it later today.
- dlandis 10y ago
  Docker is not secure by default (not even close). Their philosophy is "secure by default", which I suppose means it is something they strive for.
- kozikow 10y ago
falcolas 10y ago
"Secure by default" is a great philosophy to have. I hope Docker continues to push into this direction. However, where is image signing? Where is pulling images by their hash instead of mutable tags? Where is restricting what images run according to their hashes? Where is Docker not running a daemon as root? How about Docker doing more hardening releases and fewer feature releases? There's a lot of low hanging, security related fruit which haven't been picked. Why not? Process isolation is a fantastic. There just really needs to be more, in my opinion.
- bigmac 10y ago
  We've done a ton of work on image signing. Look in to Docker Content Trust (https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/) and Notary (https://github.com/docker/notary https://github.com/docker/notary). Our signing system is an implementation of The Update Framework (https://theupdateframework.github.io/ https://theupdateframework.github.io/), which many folks feel pushes the security of signing systems past any other currently deployed systems out there. The coolest bit here is to be able to do threshold signing. Essentially k-of-n signing for containers and verification gates that only allow containers with enough signatures in order to deploy. For some more background check out the blogpost here: https://blog.docker.com/2016/08/securing-enterprise-software-supply-chain-using-docker/ https://blog.docker.com/2016/08/securing-enterprise-software... Disclaimer: I manage security at Docker.
- shykes 10y ago
  Docker founder here. > "Secure by default" is a great philosophy to have. I hope Docker continues to push into this direction. Thank you. We will absolutely keep pushing. > However, where is image signing? Docker supports image signing out-of-the-box. It's based on TUF which is the state if the art in secure content distribution. Along the way we open-sourced our underlying TUF implementation so thaf others can reuse it: https://github.com/docker/notary https://github.com/docker/notary > Where is pulling images by their hash instead of mutable tags? That's also available out of the box: "docker pull NAME@DIGEST" > Where is restricting what images run according to their hashes? That's not available out of the box, but a popular way to implement it is to funnel images through a trusted private registry, only allow pulls from that registry, and then controlling what you push to it. Another possibility is to use the new auth plugin system, although I haven't tried. > Where is Docker not running a daemon as root? Docker runs unprivileged by default, but only on relatively recent kernels with user namespace support (it drops itself to "fake root" so it can still create containers without actually having uid0). On older systems (or if you don't trust user namespaces) I agree we could break up some parts of the daemon (for example push/pull) to drop privileges further. That requires serious refactoring which we have been working on gradually for some time. > How about Docker doing more hardening releases and fewer feature releases? We follow the linux methodology: every release includes many hardening improvements, as well as whatever features have been deemed stable enough to merge. We don't control what pull requests the community sends, but we work hard to maintain a high quality bar and encourage quality-oriented contributions. The Docker core engineering team invests more time on hardening than features. > There's a lot of low hanging, security related fruit which haven't been picked. Why not? I'm sure there are :) Security is a process, we will never be done. The important thing for us is to take it seriously, invest appropriately (Docker core team employs 6 full time security engineers and funds various third-party security efforts), and make sure we are perpetually improving. On top of that, Docker is known for making powerful technology more accessible to more people. We want to use that "superpower" to make security more usable by non-experts. We think that contributes to making everyone more secure. > Process isolation is a fantastic. There just really needs to be more, in my opinion. Docker security is about much, much more than process isolation. Thanks for the feedback. We hope to see you on the github repo, we value bug reports :)
general_failure 10y ago
We use Docker to containerize apps in cloudron. One issue we have faced is that --readonly and user namespaces don't work together. Is there any on-going effort on this front? I can't find a link now but this limitation is hidden somewhere deep inside the docker docs :/ For cloudron apps, we simply decided that readonly was more important than user namespaces for now. edit: found the link - https://docs.docker.com/engine/reference/commandline/dockerd/#/user-namespace-known-restrictions https://docs.docker.com/engine/reference/commandline/dockerd...
- cpuguy83 10y ago
  Work is being done here: https://github.com/docker/docker/pull/25540 https://github.com/docker/docker/pull/25540
mjg59 10y ago
The chart is very out of date. rkt has support for userns, the capability set is identical to that of Docker, and so is the default seccomp configuration. The SELinux policy used by rkt has always been identical to the one used by Docker (I have no idea why the chart claims there was a difference), and it's used by default if SELinux is enabled on the system. Rkt has no apparmor policy support, the set of files under /proc restricted by rkt is still slightly smaller than that restricted by Docker, and the cgroup difference doesn't actually appear to be discussed in the NCC paper so it's hard to comment on the difference there. I don't want to criticise Docker here from a security perspective - several security features in rkt are based on the implementation in Docker, and running your apps isolated under Docker is definitely more secure than running them all on the same unconfined host. (Disclaimer: I work at CoreOS, though not primarily on rkt)
- raesene9 10y ago
  The chart will be a bit old now coming from a white paper that was published 4 months back and was in the works for some time before that. (disclaimer - I work for NCC but didn't work on that paper) One of the big challenges with the containerization landscape is keeping up with changing product capabilities as there's a lot of movement all over the place.
- justincormack 10y ago
  The default seccomp configuration in rkt is not the same. It is based on the Docker one, yes, but as it does not support parameter filtering it is significantly weaker, eg it allows namespace creation, and all use of the personality syscall, allowing users to disable ASLR.
  - mjg59 10y ago
    True, I'd forgotten that aspect. Thanks for the correction.
finid 10y ago
“Gartner asserts that applications deployed in containers are more secure than applications deployed on the bare OS” Gartner is like a financial ratings agency. I wouldn't rely on their recommendation if I were concerned about the security of any application or platform.
Perceptes 10y ago
Can anyone from Docker speak to the status of content trust? The fact that I can still `docker pull whatever` without explicitly trusting the source seems to conflict with the chart in this post. Will/shouldn't content trust be turned on by default at some point?
- justincormack 10y ago
  Yes that is the plan, once everything is in place. The next step is to turn it on for official images (which are all signed now).
  - endophage 10y ago
    To add to Justin's comment, we merged what we've called "trust pinning" into Notary. We're still iterating on exactly the right scopes to pin to, but anticipate that making it into docker in the not too distant future. That will enable you to hard fail when pulling images not signed by an explicitly approved source.
raesene9 10y ago
From what I've seen Docker has added a lot of security functionality in the last couple of releases which is great, although I'd like to see more work at the Docker engine level on authentication and authrorization which still feels kind of all or nothing (I know there's a plugin framework, but there's not a load of good options there at the moment). Also at the moment implementing additional security options is a bit bitty, as the planned security profile work hasn't landed yet. the other thing to note is that when deploying Docker engine the defaults tend to go towards making everything work and aren't necessarily the most secure, so its very much worth doing some additional hardening where possible. Specfically things like - enabling user namespacing - disabling icc - removing capabilities (e.g. NET_RAW) - not using the default docker0 network - disabling userland proxy There is a CIS standard which is pretty much up to date and has some, hopefullly, decent sets of things to look at hardening (disclaimer I helped work a bit on the latest version...)
bruxis 10y ago
Does anyone know of a guide to using Docker, or an alternative, on Windows to help isolate various software (say, Steam games, multiple Visual Studio installations, .NET and Java runtimes/SDKs)?
fulafel 10y ago
Both the Docker blog post and the Gartner piece seem to be silent on the topic of out of date and vulnerable software in Docker images, which has been much talked about. Looks like Docker have put out a content scanner service to mitigate the problem this still seems to be a weakness relative to the pre-Docker way of building VMs.

63 points by pella 10y ago

merb 10y ago

without docker the software is even safer. Actually for all people below, here are my reasons: Docker adds another Layer. This also adds another attack target (docker). Saying a software is more secure while adding another layer is just naiv. Docker is good for some companies and it definitiv is true that you can make it to run a PaaS, it's still not more secure as the world before. Also some other people also pointed out other things. With docker you add a lot of complexity to your actual software, that is negligible if your big since you have a total different set of problems. Still when it comes to docker it's mostly buzzword bingo. I mean just looking at the table... oh god it's like half the things there could just be done without docker in a way more secure way, without LXC, Docker or RKT. Also I always tought that docker should make the deployment easier, which would be a hugh bonus in security since the process of understanding and everything beyond would be more understandable. however the more docker grows the worse the complexity gets. Docker once looked shiny but than the enterprise hit it and it's direction more and more makes it less secure since they try to add more and more stuff and stops focusing on the stuff docker was firstly invented. How could adding a ton of abstraction (which grows every release) making something more secure? I just keep that as an open question to everybody.

ralmeida 10y ago
Why, exactly? The article's argument is that containerization limits the vulnerable area - even if an attacker gains root access to a container, they still can't do as much damage as they would had they gotten root access in a host machine. I don't mean to sound adversarial - but what's your counterpoint to that?
- api 10y ago
  Is that really true? I have always read that cgroups based containerization on Linux is kind of a joke and that root in the container more or less equals root on the host. Has there been significant improvement in this area lately?
  - ralmeida 10y ago
    I'm not familiar with that perception, any good reads on that?
    - raesene9 10y ago
      tends to be much older articles that had that perception, pre userns, seccomp, extended cgroup support etc.
  - wmf 10y ago
    The fix for that is user namespaces which is (finally) included in Docker. So yes, it has gotten better.
- fapjacks 10y ago
  There isn't one. It's just a narrative regurgitated by people with an axe to grind. The anti-Docker crowd. User namespacing arrived in 1.10, which brought a lot of great possibilities for further compartmentalization with it. Alpine is the default base image. Lots of great, positive changes have gone into this blog post.
  - officialchicken 10y ago
    > Lots of great, positive changes have gone into this blog post. I'm not sure I agree, I'd offer some improvements: - Gartner "studies" are usually paid advertisements - The comparison table is missing columns for DOM0/1 VM's and BSD jails - Encryption in-transit or at-rest isn't mentioned - Nothing about key management or key rotation - Non-mutable / exported log files aren't in the defaults
    - bigmac 10y ago
      Great points, we're working on a bunch of this stuff. Docker 1.12 in swarm mode, for example, does automatic key rotation and issuance of the TLS certs assigned to every node in the cluster. These certs are used for automatic TLS between every node in the control plane of the Docker Swarm. This is all automatic and transparent to the user -- no manual management of certificates is required. Now that we have cryptographic identities assigned to every node in the cluster we can use that to build secrets/key management in to the system. Additionally Docker 1.12 is swarm mode has overlay networking with encryption possible for container to container communications. In terms of logs, Docker supports log drivers that allow all logs within Docker containers to be exported to off-host logging services.
      - rmoriz 10y ago
        How is the overlay network encrypted? I couldn't find any information. https://github.com/docker/docker/issues/24253 https://github.com/docker/docker/issues/24253 says it's not encrypted by default and must be enabled manually.
        10y ago
- codemac 10y ago
  The bundling of all your software's dependencies into your container means that you can't upgrade 1 .so on a machine, and all software be updated. Great example recently was libgcypt's security bugs. You have to upgrade all containers, which requires figuring out which ones need upgrading. The concern isn't generally that someone will escalate and then delete some other container's filesystem.. it's that once they get remote execution in a container that has connections to your database, http to your discovery service etc, they can steal your customer information. I will say however that this post is showing that by using docker or frankly other well manicured execution enviroments, large swaths of attacks will hopefully not work (selinux & seccomp being great examples).
  - riskable 10y ago
    Well, Docker containers are really meant to be short-lived. On the order of milliseconds (e.g. run a batch operation) to days (run a web server application). They're also meant to be mostly immutable. So a vulnerability in a particular library that allows an attacker access to the container won't necessarily allow them to do much. The other benefit of short-lived containers is that any given vulnerability only lasts as long as the container (assuming you're rebuilding your image with the latest & greatest software/libs before each deployment). Whereas with a full OS/VM you have to find down time to patch that sucker and that might take a month or even a quarter or longer.
    - pmontra 10y ago
      I'm not sure I understand this. Even if you keep deploying new versions of containers every few days because you use them to deploy new features, how about the db and web server containers? And how about the vulnerabilities that won't be patched until you make a new deploy? We should build a new container after each apt-get for security patches, right?
      - tayo42 10y ago
        Why are websevers a big deal to redeploy? Why do you want to run a db in a container? That always seemed crazy to me...
bigmac 10y ago
This couldn't be further from the truth. Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArmor, SELinux), and capability dropping. These are all common sense security controls that aren't widely available because they're typically hard to use. Docker makes them defaults for everyone. This makes classes of remote attacks against applications far more difficult. Tangible example: read-only filesystems + mount namespacing make vulns that require filesystem modification or directory traversal far more difficult. At this point arguing against running in Docker is like arguing in favor of IE6's security model instead of Chrome's. Disclaimer: I manage security at Docker.
- yid 10y ago
  You guys are doing a great job! Some security-related sandboxing options to docker run that people may not be aware of, which are hard to assemble individually from Linux pieces: * --read-only * --security-opt="no-new-privileges" * --cap-drop=ALL * --net="none" * --cpu-period= * --cpu-quota=
  - redtuesday 10y ago
    Is it intended that the last two have nothing after the equal sign? If yes, what does that do? There is also --pids-limit=<some number> against fork bombs. EDIT - this git repo has more links to security related articles etc. https://github.com/wsargent/docker-cheat-sheet#security https://github.com/wsargent/docker-cheat-sheet#security
- nwmcsween 10y ago
  I argue against using docker but simply due to the fact that docker encompasses too much when everything docker does could be accomplished by simple single use tools like unshared, cgexec, etc. Git does this and it works very well.
- cpuguy83 10y ago
  More detail on actual security issues (real CVE's) prevented just by using docker: https://docs.docker.com/engine/security/non-events/ https://docs.docker.com/engine/security/non-events/
ralmeida 10y ago
Reply to the edited comment: The reasoning that "more layers of abstraction necessarily equals less security" does not seem true to me. Granted, it increases the "surface area" that is exposed to attacks, and there's indeed a tradeoff involved, but this tradeoff may swing either way - either it does pay off or not. Taking this reasoning to the extreme, there are plenty of abstractions that pay off for secutiry. One simple example is that software written in Java (for example) is by default more buffer-overflow-resistant than software written in C, due to managed memory/bounds-checking. In this case, the tradeoff was performance vs security. > How could adding a ton of abstraction (which grows every release) making something more secure? One example is the "buffer overflow resistence" in Java vs C mentioned above.
- merb 10y ago
  Actually we are a 100% Java Shop but the JVM has a lot of Bugs, Bugs that you won't have in C. Yes you can run into your own code smell, Bugs or whatever, but the same could happen on Java, too. The biggest problem with docker is the tone of stuff they try to put into. While most stuff is just possible without docker and the big abstraction. Hell you can start your programs under Linux with user namespaces just without docker. Actually trust me it's way easier to control a single stack instead of managing a stack on top of another. Especially networking is no fun. Maybe it's cool and easy / shiny if you can have everything in the cloud, but that just won't apply to everybody.
  - ralmeida 10y ago
    > the JVM has a lot of Bugs, Bugs that you won't have in C There will be different classes of bugs, of course, but I find it hard to believe that it will be more bugs, or more serious bugs, or most costly-to-fix bugs. Otherwise, your own company would have decided to use C instead of Java, right? > Hell you can start your programs under Linux with user namespaces just without docker Sure you can, but if Docker (or any other solution, for that matter) makes it easier or faster to do that, more people would do that. There's a more or less fixed number of work units to dedicate on a certain project, if you have to use them all to set up security solutions, your lunch will be eaten by other people. > most stuff is just possible without docker and the big abstraction Most stuff is "just possible" without any abstraction at all. However, one has to learn to leverage abstracted-away stuff, otherwise one will spend a lot of time and accomplish very little valuable stuff. > trust me it's way easier to control a single stack instead of managing a stack on top of another Easier does not equal safer, faster, or more business-valuable. > it's cool and easy / shiny if you can have everything in the cloud Not sure where "the cloud" enters the equation? You can use Docker (or whatever else) to manage even your on-premises stack. --- I don't know the specifics of your situation at all, but if your only argument against a particular piece of tech is "it abstracts away stuff, therefore it is worse", you might want to consider some self-reflection on whether you're not just suffering of NIH Syndrome (https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here)

shiftoutbox 10y ago

Umm they misspelled "you are a sucker by default" they had a brain fart and actually wrote "secure by default". I think someone was dreaming of OpenBSD.

hinkley 10y ago

If Docker is Secure By Default, then why is this issue 15 months old with no forward progress? https://github.com/docker/docker/issues/13490 https://github.com/docker/docker/issues/13490 It's not 'secure by default' if secrets are flying around through the system with no formal way to prevent it.

bigmac 10y ago
We are on the case right now. The solution is going to be really, really good. We had to get cryptographic node identity rolled out first and we're designing secrets management on top of that.
- btreesOfSpring 10y ago
  this is a very nice and better than expected answer to hear.
- hinkley 10y ago
  Why haven't you been forthcoming about this? If you're playing to the 'secure by default' crowd, they aren't going to just trust that you're on the case if you don't communicate. Platitudes are something people watch out for when security is on the line, and they'll chose another solution if they think you're full of shit. You have to show, at all times and all things, how you're thinking about the problem. 15 months of dead air is a lot to atone for.
Feuilles_Mortes 10y ago
I'm building a secret management solution for my team right now that will work securely with docker. I think it's pretty cool - I'll write how I'm doing it later today.
dlandis 10y ago
Docker is not secure by default (not even close). Their philosophy is "secure by default", which I suppose means it is something they strive for.
kozikow 10y ago

falcolas 10y ago

"Secure by default" is a great philosophy to have. I hope Docker continues to push into this direction. However, where is image signing? Where is pulling images by their hash instead of mutable tags? Where is restricting what images run according to their hashes? Where is Docker not running a daemon as root? How about Docker doing more hardening releases and fewer feature releases? There's a lot of low hanging, security related fruit which haven't been picked. Why not? Process isolation is a fantastic. There just really needs to be more, in my opinion.

bigmac 10y ago
We've done a ton of work on image signing. Look in to Docker Content Trust (https://docs.docker.com/engine/security/trust/content_trust/ https://docs.docker.com/engine/security/trust/content_trust/) and Notary (https://github.com/docker/notary https://github.com/docker/notary). Our signing system is an implementation of The Update Framework (https://theupdateframework.github.io/ https://theupdateframework.github.io/), which many folks feel pushes the security of signing systems past any other currently deployed systems out there. The coolest bit here is to be able to do threshold signing. Essentially k-of-n signing for containers and verification gates that only allow containers with enough signatures in order to deploy. For some more background check out the blogpost here: https://blog.docker.com/2016/08/securing-enterprise-software-supply-chain-using-docker/ https://blog.docker.com/2016/08/securing-enterprise-software... Disclaimer: I manage security at Docker.
shykes 10y ago
Docker founder here. > "Secure by default" is a great philosophy to have. I hope Docker continues to push into this direction. Thank you. We will absolutely keep pushing. > However, where is image signing? Docker supports image signing out-of-the-box. It's based on TUF which is the state if the art in secure content distribution. Along the way we open-sourced our underlying TUF implementation so thaf others can reuse it: https://github.com/docker/notary https://github.com/docker/notary > Where is pulling images by their hash instead of mutable tags? That's also available out of the box: "docker pull NAME@DIGEST" > Where is restricting what images run according to their hashes? That's not available out of the box, but a popular way to implement it is to funnel images through a trusted private registry, only allow pulls from that registry, and then controlling what you push to it. Another possibility is to use the new auth plugin system, although I haven't tried. > Where is Docker not running a daemon as root? Docker runs unprivileged by default, but only on relatively recent kernels with user namespace support (it drops itself to "fake root" so it can still create containers without actually having uid0). On older systems (or if you don't trust user namespaces) I agree we could break up some parts of the daemon (for example push/pull) to drop privileges further. That requires serious refactoring which we have been working on gradually for some time. > How about Docker doing more hardening releases and fewer feature releases? We follow the linux methodology: every release includes many hardening improvements, as well as whatever features have been deemed stable enough to merge. We don't control what pull requests the community sends, but we work hard to maintain a high quality bar and encourage quality-oriented contributions. The Docker core engineering team invests more time on hardening than features. > There's a lot of low hanging, security related fruit which haven't been picked. Why not? I'm sure there are :) Security is a process, we will never be done. The important thing for us is to take it seriously, invest appropriately (Docker core team employs 6 full time security engineers and funds various third-party security efforts), and make sure we are perpetually improving. On top of that, Docker is known for making powerful technology more accessible to more people. We want to use that "superpower" to make security more usable by non-experts. We think that contributes to making everyone more secure. > Process isolation is a fantastic. There just really needs to be more, in my opinion. Docker security is about much, much more than process isolation. Thanks for the feedback. We hope to see you on the github repo, we value bug reports :)

general_failure 10y ago

We use Docker to containerize apps in cloudron. One issue we have faced is that --readonly and user namespaces don't work together. Is there any on-going effort on this front? I can't find a link now but this limitation is hidden somewhere deep inside the docker docs :/ For cloudron apps, we simply decided that readonly was more important than user namespaces for now. edit: found the link - https://docs.docker.com/engine/reference/commandline/dockerd/#/user-namespace-known-restrictions https://docs.docker.com/engine/reference/commandline/dockerd...

cpuguy83 10y ago
Work is being done here: https://github.com/docker/docker/pull/25540 https://github.com/docker/docker/pull/25540

mjg59 10y ago

The chart is very out of date. rkt has support for userns, the capability set is identical to that of Docker, and so is the default seccomp configuration. The SELinux policy used by rkt has always been identical to the one used by Docker (I have no idea why the chart claims there was a difference), and it's used by default if SELinux is enabled on the system. Rkt has no apparmor policy support, the set of files under /proc restricted by rkt is still slightly smaller than that restricted by Docker, and the cgroup difference doesn't actually appear to be discussed in the NCC paper so it's hard to comment on the difference there. I don't want to criticise Docker here from a security perspective - several security features in rkt are based on the implementation in Docker, and running your apps isolated under Docker is definitely more secure than running them all on the same unconfined host. (Disclaimer: I work at CoreOS, though not primarily on rkt)

raesene9 10y ago
The chart will be a bit old now coming from a white paper that was published 4 months back and was in the works for some time before that. (disclaimer - I work for NCC but didn't work on that paper) One of the big challenges with the containerization landscape is keeping up with changing product capabilities as there's a lot of movement all over the place.
justincormack 10y ago
The default seccomp configuration in rkt is not the same. It is based on the Docker one, yes, but as it does not support parameter filtering it is significantly weaker, eg it allows namespace creation, and all use of the personality syscall, allowing users to disable ASLR.
- mjg59 10y ago
  True, I'd forgotten that aspect. Thanks for the correction.

finid 10y ago

“Gartner asserts that applications deployed in containers are more secure than applications deployed on the bare OS” Gartner is like a financial ratings agency. I wouldn't rely on their recommendation if I were concerned about the security of any application or platform.

Perceptes 10y ago

Can anyone from Docker speak to the status of content trust? The fact that I can still `docker pull whatever` without explicitly trusting the source seems to conflict with the chart in this post. Will/shouldn't content trust be turned on by default at some point?

justincormack 10y ago
Yes that is the plan, once everything is in place. The next step is to turn it on for official images (which are all signed now).
- endophage 10y ago
  To add to Justin's comment, we merged what we've called "trust pinning" into Notary. We're still iterating on exactly the right scopes to pin to, but anticipate that making it into docker in the not too distant future. That will enable you to hard fail when pulling images not signed by an explicitly approved source.

raesene9 10y ago

From what I've seen Docker has added a lot of security functionality in the last couple of releases which is great, although I'd like to see more work at the Docker engine level on authentication and authrorization which still feels kind of all or nothing (I know there's a plugin framework, but there's not a load of good options there at the moment). Also at the moment implementing additional security options is a bit bitty, as the planned security profile work hasn't landed yet. the other thing to note is that when deploying Docker engine the defaults tend to go towards making everything work and aren't necessarily the most secure, so its very much worth doing some additional hardening where possible. Specfically things like - enabling user namespacing - disabling icc - removing capabilities (e.g. NET_RAW) - not using the default docker0 network - disabling userland proxy There is a CIS standard which is pretty much up to date and has some, hopefullly, decent sets of things to look at hardening (disclaimer I helped work a bit on the latest version...)

bruxis 10y ago

Does anyone know of a guide to using Docker, or an alternative, on Windows to help isolate various software (say, Steam games, multiple Visual Studio installations, .NET and Java runtimes/SDKs)?

fulafel 10y ago

Both the Docker blog post and the Gartner piece seem to be silent on the topic of out of date and vulnerable software in Docker images, which has been much talked about. Looks like Docker have put out a content scanner service to mitigate the problem this still seems to be a weakness relative to the pre-Docker way of building VMs.