4 ms·

Look, I'm really glad that you're excited for docker, but name dropping companies running the risk of exposing their machines does not magically invalidate the

by _wmd 13y ago

Look, I'm really glad that you're excited for docker, but name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave. In fact I've really no idea what purpose your reply was hoping to serve. In the default configuration (and according to all docs I've seen), regardless of some imagined rosy future, today docker is a wrapper around Linux containers, and Linux containers today are a very poor general purpose security solution, especially for the kind of person who needs to ask the question in the first place (see also: the comment I was originally replying to)

shykes 13y ago
> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering a detailed argument explaining why. > In the default configuration (and according to all docs I've seen) [...] today docker is a wrapper around Linux containers Yes. > [...] regardless of some imagined rosy future [...] I only described things that are possible today, with current versions of Docker. No imagined rosy future involved :) > and Linux containers today are a very poor general purpose security solution I guess it really depends of your definition of "general purpose", so you could make a compelling argument either way. But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine. In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment.
- comex 13y ago
  > But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine. > In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment. If I understand services like Heroku correctly, they give customers standard access to run arbitrary code inside a container as a standard user. Therefore, I expect it would be standard and unavoidable to have many different customers' applications running on the same machine, leading to the ability to exploit vulnerabilities similar to the recent x32 one. If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available.
  - nl 13y ago
    >> In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment. >If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available. The parent is suggesting you can use Docker as a supplement to any additional security measure one might choose (to quote: "Docker is commonly used in combination of VMs for security, so at least some people find it useful"). In your example, a person would run Docker on top of the VM, and gain "a system for managing and distributing repeatable execution environments".
- _wmd 13y ago
  You keep saying I'm wrong, because in future docker/containers might work in a different way to how they work today, and will be used in a way entirely different to how people use them today (and utterly contrary to how docker has been marketed to date). AFAICT through the wall of text, the only problem you have with what I said is that Docker loses its value when combined with a VM. That's fair enough, but that was 1% of my comment. If you're replying, please don't quote yet another wall of text, it's almost impossible to read.
  - 1stop 13y ago
    I think the problem the parent has with you're statement is you are saying "Docker is a crap security alternative"... but docker isn't marketed as a security solution, it's a "logical" process isolation. It solves the "I want to run two apache's how do I stop them conflicting" problem. Not the "I don't trust what is being run here" problem, it has never been marketed as that, and you are presenting it as if it was. Docker is a great way to build up a machine, and logically define a machines capabilities. Your gripe about security is just completely irrelevant, it'd be like complaining that iPhoto doesn't increase OS X Security. Edit: So the answer to the original "Is docker good for security?" I would say "maybe, but that's not its intention or focus".
    - deleted 13y ago
      [deleted]

by _wmd 13y ago

shykes 13y ago

> name dropping companies running the risk of exposing their machines does not magically invalidate the specific examples I gave You're right. But what it does is provide anecdotical evidence that your views are not shared by a large and growing number of experienced engineers. > In fact I've really no idea what purpose your reply was hoping to serve. It's pretty simple: you made an incorrect statement, I'm offering a detailed argument explaining why. > In the default configuration (and according to all docs I've seen) [...] today docker is a wrapper around Linux containers Yes. > [...] regardless of some imagined rosy future [...] I only described things that are possible today, with current versions of Docker. No imagined rosy future involved :) > and Linux containers today are a very poor general purpose security solution I guess it really depends of your definition of "general purpose", so you could make a compelling argument either way. But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine. In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment.

comex 13y ago
> But it doesn't matter because if you don't trust containers for security, you can just install Docker on a bunch of machines and make sure to deploy mutually untrusted containers on separate machines. Lots of people do this today and it works just fine. > In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment. If I understand services like Heroku correctly, they give customers standard access to run arbitrary code inside a container as a standard user. Therefore, I expect it would be standard and unavoidable to have many different customers' applications running on the same machine, leading to the ability to exploit vulnerabilities similar to the recent x32 one. If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available.
- nl 13y ago
  >> In other words, Docker can be used for deployment and distribution without reducing your options for security. Respectfully, this directly contradicts your original comment. >If they instead used a VM for each application, they would have to pierce the VM implementation, potentially plus seccomp in some cases, which is the mitigation the parent was referring to. The choice to use Docker instead of VMs limits the security options available. The parent is suggesting you can use Docker as a supplement to any additional security measure one might choose (to quote: "Docker is commonly used in combination of VMs for security, so at least some people find it useful"). In your example, a person would run Docker on top of the VM, and gain "a system for managing and distributing repeatable execution environments".
_wmd 13y ago
You keep saying I'm wrong, because in future docker/containers might work in a different way to how they work today, and will be used in a way entirely different to how people use them today (and utterly contrary to how docker has been marketed to date). AFAICT through the wall of text, the only problem you have with what I said is that Docker loses its value when combined with a VM. That's fair enough, but that was 1% of my comment. If you're replying, please don't quote yet another wall of text, it's almost impossible to read.
- 1stop 13y ago
  I think the problem the parent has with you're statement is you are saying "Docker is a crap security alternative"... but docker isn't marketed as a security solution, it's a "logical" process isolation. It solves the "I want to run two apache's how do I stop them conflicting" problem. Not the "I don't trust what is being run here" problem, it has never been marketed as that, and you are presenting it as if it was. Docker is a great way to build up a machine, and logically define a machines capabilities. Your gripe about security is just completely irrelevant, it'd be like complaining that iPhoto doesn't increase OS X Security. Edit: So the answer to the original "Is docker good for security?" I would say "maybe, but that's not its intention or focus".
  - deleted 13y ago
    [deleted]