3 ms·

> The way you phrase that suggests that user experience is more important than security Of course it is. Steve Yegge put it best: > But I'll argue that Acces

> The way you phrase that suggests that user experience is more important than security Of course it is. Steve Yegge put it best: > But I'll argue that Accessibility is actually more important than Security because dialing Accessibility to zero means you have no product at all, whereas dialing Security to zero can still get you a reasonably successful product such as the Playstation Network. Ha ha. You can always layer security around how use use Docker, but without any usability what do you have? Chop the network cable and you get the tradeoff you are looking for.

eropple 12y ago
Your response is terrifying. Comparing core, must-not-fail infrastructural systems the same in terms of security needs as a consumer-facing video game platform is, to me, very much misguided, and I think it betrays the difference in mindset between "product people" and "platform people": as a platform people, my stuff must not fucking break and vendors that build stuff that make things more likely to break are poisonous. The continually lackadaisical approach to security and reliability (basic features around reliability being post-1.0 is unconscionably bad, and user privilege segmentation, as noted, still hasn't happened), in ways I can't patch around, is one of the reasons I'm honestly hoping for a Docker competitor to arise that would trade that growth-fuel "user experience" for security, reliability, and a less compromised ethos. (I am considering a move of my systems to OpenBSD, but in AWS that's difficult.) This leads me to thinking about a larger problem in the current ecosystem: core infrastructure being tied to a VC-backed, growth-as-a-prerequisite startup (where you really can convince yourself that making it easy is more important than making it popular) scares me deeply, because building the right thing becomes less incentivized than building the popular thing. I hope this is not the way of the future, because things already work poorly enough and are insecure enough as it is. =/
- shykes 12y ago
  I'm happy to address any specific concerns you have about security. It's an important topic for me. In this particular comment I could only spot one specific criticism: the lack of built-in user segmentation, so I will talk about that. I agree that this would be a nice feature. But we decided to not rush it, and instead tell operators to rely on the underlying system features for authentication, segmentation etc. In practice that means: * If you have an https auth infrastructure in production, drop the appropriate middleware in front of your docker daemon, and rely on that. * If you rely on ssh keys and unix access control in production, keep the default configuration of listening on a unix socket, and use regular unix users to decide who gets to talk to the socket. * If you run trusted payloads, or if you run untrusted payloads with acceptable mitigation in place (no root inside the container, apparmor/selinux, inter-container networking disabled etc.), then go ahead and pool all your machines into a single swarm. * If you run untrusted payloads, then map each trust domain to an isolated group of underlying machines. This is what Amazon, Google and others do when running customer payloads on Docker for example. It would be a nice feature to segment Docker API endpoints by user, so that different users have different views (and different levels of access) of the same underlying daemon. But that requires implementing an authentication and authorization layer, and it requires changing some aspects of the Docker API which imply privileged access to the system. For example, the 'docker run -v /foo:/bar'. This represents serious engineering work, and as much as I would like to make you happy tomorrow, I don't think you will be any happier if we ship an unfinished feature.

eropple 12y ago

Your response is terrifying. Comparing core, must-not-fail infrastructural systems the same in terms of security needs as a consumer-facing video game platform is, to me, very much misguided, and I think it betrays the difference in mindset between "product people" and "platform people": as a platform people, my stuff must not fucking break and vendors that build stuff that make things more likely to break are poisonous. The continually lackadaisical approach to security and reliability (basic features around reliability being post-1.0 is unconscionably bad, and user privilege segmentation, as noted, still hasn't happened), in ways I can't patch around, is one of the reasons I'm honestly hoping for a Docker competitor to arise that would trade that growth-fuel "user experience" for security, reliability, and a less compromised ethos. (I am considering a move of my systems to OpenBSD, but in AWS that's difficult.) This leads me to thinking about a larger problem in the current ecosystem: core infrastructure being tied to a VC-backed, growth-as-a-prerequisite startup (where you really can convince yourself that making it easy is more important than making it popular) scares me deeply, because building the right thing becomes less incentivized than building the popular thing. I hope this is not the way of the future, because things already work poorly enough and are insecure enough as it is. =/

shykes 12y ago
I'm happy to address any specific concerns you have about security. It's an important topic for me. In this particular comment I could only spot one specific criticism: the lack of built-in user segmentation, so I will talk about that. I agree that this would be a nice feature. But we decided to not rush it, and instead tell operators to rely on the underlying system features for authentication, segmentation etc. In practice that means: * If you have an https auth infrastructure in production, drop the appropriate middleware in front of your docker daemon, and rely on that. * If you rely on ssh keys and unix access control in production, keep the default configuration of listening on a unix socket, and use regular unix users to decide who gets to talk to the socket. * If you run trusted payloads, or if you run untrusted payloads with acceptable mitigation in place (no root inside the container, apparmor/selinux, inter-container networking disabled etc.), then go ahead and pool all your machines into a single swarm. * If you run untrusted payloads, then map each trust domain to an isolated group of underlying machines. This is what Amazon, Google and others do when running customer payloads on Docker for example. It would be a nice feature to segment Docker API endpoints by user, so that different users have different views (and different levels of access) of the same underlying daemon. But that requires implementing an authentication and authorization layer, and it requires changing some aspects of the Docker API which imply privileged access to the system. For example, the 'docker run -v /foo:/bar'. This represents serious engineering work, and as much as I would like to make you happy tomorrow, I don't think you will be any happier if we ship an unfinished feature.