3 ms·

I think the three usages of containers often get conflated. 1) Packaging 2) Isolation 3) Secure isolation Containers have dong a good job of packaging and iso

I think the three usages of containers often get conflated. 1) Packaging 2) Isolation 3) Secure isolation Containers have dong a good job of packaging and isolating applications. This is has been a boon to development. Particularly with testing and deploying applications in a more or less consistent state and managing those applications. Note that these benefits have nothing to do with security. Containers have done a poor job of being secure against malicious actors but that doesn't mean the isolation is useless. From a security point of view you just have to treat it the same as if it was running outside the container(s). One day we'll hopefully get something better from a security POV but that doesn't mean packaging and isolation are worthless in themselves, even if they don't add any security. The problem comes when people assume containers add more security than they do.

rhn_mk1 7y ago
Can you point out something that reveals how security is failing in containers today?
- eyberg 7y ago
  The issue here with containers in general is that they break well known security boundaries. This is exacerbated by things like k8s cause it is inherently built to orchestrate many of them and assumes that there is a multi-tenant deployment by default. Most recently Google themselves wrote about this just a few weeks ago: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-engine-features-and-guidance-to-help-lock-down-your-containers https://cloud.google.com/blog/products/containers-kubernetes... but the issues have been present forever: https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/ https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/ https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/ https://www.zdnet.com/article/doomsday-docker-security-hole-... https://www.zdnet.com/article/alpine-linux-docker-images-ship-a-root-account-with-no-password/ https://www.zdnet.com/article/alpine-linux-docker-images-shi...
meowface 7y ago
Exactly, this is what has me so confused. The value I get from containers is the series of steps that create the container, not the underlying implementation. I don't really care what substrate the software sits in, be it a unimicronanofirecrackerkernelVM or LXC or a chroot jail, besides security implications of isolation escapes. I just like having a deterministic Dockerfile-like file. If I can keep that, sure, I'll buy into your Containers But Not But Really Cloud Native For Actual schtick and use it, especially if it actually is more secure (I'm sure it very likely is). It's the abstraction and model that makes containers easier to work with, not the implementation. I find it very irritating and deceptive that the author wildly equivocates between containers and Kubernetes almost every sentence. And it's incredibly condescending that they suggest people buying the container Kool-Aid are simply too young to have done development and operations on regular servers/VMs, "duh!" Or that they're just trying to pad their resumes. No, I've had plenty of years of experience doing that, and I find containers far simpler to develop with, deploy, maintain, and update. And I've never used Kubernetes. As most others have said, this comes across as extremely patronizing and demeaning marketing FUD from a company so certain that they're obviously right and almost everyone else is mind-numbingly wrong that even if that's actually the case, no one is ever going to believe them; and very justifiably. This is not how you do marketing, or write prose or communicate in general.
- topspin 7y ago
  > wildly equivocates between containers and Kubernetes The conflation of containers and K8s is pretty damning. I personally believe k8s is an early realization of orchestration and will be superseded by better ones. Building yet another orchestration system is a cottage industry at the moment and I've noticed that the existence of k8s hasn't impeded it. And "spin up a linux box" is deeply naive. It is the habit of spinning up linux instances that leave companies and other institutions with huge collections of neglected, mis-configured, vulnerable linux VMs spread all over the planet with 0.1% average utilization. Developers popularized containers, independent of the cloud or the troubles of operations. Containers solve tough development and packaging problems and have value whether the ultimate deployment abstraction is 'docker' or some microVM system. The most likely use case for whatever microVM product one might imagine is running containers.

rhn_mk1 7y ago

Can you point out something that reveals how security is failing in containers today?

eyberg 7y ago
The issue here with containers in general is that they break well known security boundaries. This is exacerbated by things like k8s cause it is inherently built to orchestrate many of them and assumes that there is a multi-tenant deployment by default. Most recently Google themselves wrote about this just a few weeks ago: https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-engine-features-and-guidance-to-help-lock-down-your-containers https://cloud.google.com/blog/products/containers-kubernetes... but the issues have been present forever: https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/ https://capsule8.com/blog/oomypod-nothin-to-cri-o-bout/ https://www.zdnet.com/article/doomsday-docker-security-hole-uncovered/ https://www.zdnet.com/article/doomsday-docker-security-hole-... https://www.zdnet.com/article/alpine-linux-docker-images-ship-a-root-account-with-no-password/ https://www.zdnet.com/article/alpine-linux-docker-images-shi...

meowface 7y ago

Exactly, this is what has me so confused. The value I get from containers is the series of steps that create the container, not the underlying implementation. I don't really care what substrate the software sits in, be it a unimicronanofirecrackerkernelVM or LXC or a chroot jail, besides security implications of isolation escapes. I just like having a deterministic Dockerfile-like file. If I can keep that, sure, I'll buy into your Containers But Not But Really Cloud Native For Actual schtick and use it, especially if it actually is more secure (I'm sure it very likely is). It's the abstraction and model that makes containers easier to work with, not the implementation. I find it very irritating and deceptive that the author wildly equivocates between containers and Kubernetes almost every sentence. And it's incredibly condescending that they suggest people buying the container Kool-Aid are simply too young to have done development and operations on regular servers/VMs, "duh!" Or that they're just trying to pad their resumes. No, I've had plenty of years of experience doing that, and I find containers far simpler to develop with, deploy, maintain, and update. And I've never used Kubernetes. As most others have said, this comes across as extremely patronizing and demeaning marketing FUD from a company so certain that they're obviously right and almost everyone else is mind-numbingly wrong that even if that's actually the case, no one is ever going to believe them; and very justifiably. This is not how you do marketing, or write prose or communicate in general.

topspin 7y ago
> wildly equivocates between containers and Kubernetes The conflation of containers and K8s is pretty damning. I personally believe k8s is an early realization of orchestration and will be superseded by better ones. Building yet another orchestration system is a cottage industry at the moment and I've noticed that the existence of k8s hasn't impeded it. And "spin up a linux box" is deeply naive. It is the habit of spinning up linux instances that leave companies and other institutions with huge collections of neglected, mis-configured, vulnerable linux VMs spread all over the planet with 0.1% average utilization. Developers popularized containers, independent of the cloud or the troubles of operations. Containers solve tough development and packaging problems and have value whether the ultimate deployment abstraction is 'docker' or some microVM system. The most likely use case for whatever microVM product one might imagine is running containers.