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

Containers are tents

increment.com

Post reply on HN
Print view View original

51–60 of 109 posts

Re: Containers are tents

#51

Post by effie »

encryptluks2 wrote: post #2

Starts off saying VMs are like brick and mortar houses and containers are like tents. I agree somewhat but there has been significant progress to sandbox containers with the same security we'd expect from a VM. It isn't a ridiculous idea that VMs will one day be antiquated, but probably won't happen for a few more years.

You can't make the Linux kernel isolation of processes as secure as Xen or Firecracker or SEL4 can. Yes, processes can be restricted to subset of syscalls and system resources but Linux is just too big and its attack surface is too big to put it on the same level of confidence as above hypervisors.

Re: Containers are tents

#52

Post by vladvasiliu »

rualca wrote: post #50
catlifeonmars wrote: post #21

Earlier quoted context omitted.

Exactly! I don’t see this as a criticism of containerization so much as it is a praise of static linking. What containerization enables is that it allows you to confer some of the advantages of static linking to languages and libraries that don’t natively support it.

> Exactly! I don’t see this as a criticism of containerization so much as it is a praise of static linking. Not really. It seems the keyword "static linking" is being abused to refer to stand-alone executables, because that's what some people know. Yet, calling containers a kind of "static linking" is simplistic and incorrect, even taking the standalone executable interpretation info account. If anything, container i…

I'd say that the static linking metaphor refers to the container image itself, in that it's standalone and (fairly) "universal".

All the other things you talk about could be set up for standalone binaries as some form of orchestration, after installation, as you say.

To me, the analogy doesn't have to be 1:1 for it to work. Yes, that means there are edge cases which should be taken into account, but that doesn't make it useless.

Especially if you look at how most developers see containers: "I'll give you this image, which I know works [in a given way] and you can run it with something that understands it". You can go ahead and set up a full K8S cluster to run it, or you can run it on Docker Desktop on a random Windows / Mac laptop. "It just works", and it's in this I think the "universal static binary" analogy works.

I get the feeling that all those fancy orchestration tools (health checks, blue / green deployment / fancy network setup / etc) have seen an impressive growth around container runtimes, and therefore often thought of as belonging together, but I don't think that one requires the other and couldn't exist without the other.

I'm curious to see what kind of ecosystem will grow around new developments such as Firecracker and "unikernel containers". I seem to remember a post on HN the other day about some effort by google to run go binaries directly on some VM kernel.

Re: Containers are tents

#54

Post by jsiepkes »

Should be noted that a portion of this (valid) criticism applies specifically to the most prominent "container" implementation; Docker. Not containers as a whole.

For example resources isolation with the Solaris / Illumos container implementation (zones) works just as well as full blown virtualization. You are just as well equipped to handle noisy neighbors with zones as you are with hardware VM's.

> Much as you’d likely choose to live in a two-bedroom townhouse over a tent, if what you need is a lightweight operating system, containers aren’t your best option.

So I think this is true for Docker but doesn't really do justice to other container implementations such as FreeBSD jails and Solaris / Illumos zones. Because those containers are really just lightweight operating systems.

In the end Docker started out and was designed to be a deployment tool. Not necessarily an isolation tool in all aspects. And yeah, it shows.

Re: Containers are tents

#55

Post by belter »

jsiepkes wrote: post #54

Should be noted that a portion of this (valid) criticism applies specifically to the most prominent "container" implementation; Docker. Not containers as a whole. For example resources isolation with the Solaris / Illumos container implementation (zones) works just as well as full blown virtualization. You are just as well equipped to handle noisy neighbors with zones as you are with hardware VM's. > Much as you’d li…

I can not agree more. It is the saddest thing the appalling implementation of Docker, and the whole lack of security around the ecosystem, made people think Containers equal to Docker. Docker is what happens when you put your security implementation in the hands of your Developer team and not in the hands of your DevSecOps people.

Re: Containers are tents

#56

Post by eyeyeyerg »

containers are cattle, VMs were pets. If one does not get the operational differences nor understands that these are completely two different usescases then probably should not work in IT industry

Re: Containers are tents

#57

Post by detaro »

eyeyeyerg wrote: post #56

containers are cattle, VMs were pets. If one does not get the operational differences nor understands that these are completely two different usescases then probably should not work in IT industry

VMs can be cattle. Physical machines can be cattle. This is not tied to the runtime technology, but to how you design and manage your machines and applications.

Re: Containers are tents

#58

Post by 1vuio0pswjnm7 »

globular-toast wrote: post #47
tptacek wrote: post #3

That's a valid way to look at it, but there are other ways. Containers are also a simple, practical way to bundle applications and their dependencies in a relatively standardized way, so they can be run on different compute fabrics. That sense of the term isn't loaded with any specific notion of how attack surfaces should work. I think modern "Docker"'s security properties are underrated†. But you still can't run mul…

Technically what you're describing is an image. Might sound pedantic but interchanging container and image does often cause confusion in my experience.

I was making these all the time on NetBSD for dd'ing to USB sticks long before "Docker". FFS images containing only a bootloader and alternate kernels with embedded userlands. One was the "update" kernel and the other was the running kernel. I could pull out the stick after booting; I could also mount the stick and edit the update kernel. The userland was generally a single statically compiled binary, like busybox, but better. I thought about the possibilities of distributing software by bootable USB stick but not the possibilty that people might run the images in VM's.

Re: Containers are tents

#59

Post by Saint_Genet »

tptacek wrote: post #3

That's a valid way to look at it, but there are other ways. Containers are also a simple, practical way to bundle applications and their dependencies in a relatively standardized way, so they can be run on different compute fabrics. That sense of the term isn't loaded with any specific notion of how attack surfaces should work. I think modern "Docker"'s security properties are underrated†. But you still can't run mul…

Your first paragraph pretty much sums up what docker is, it’s a convenient way to design and build a system, but it is not a security mechanism.

If you’re building a system that’s handling classified information, there is probably not an accreditation authority in the world that would let you use containers or even hypervisors as a way to separate different information classes.

Re: Containers are tents

#60

Post by johbjo »

I'd be curious to see services designed to run as PID 1 inside containers, and contain or run nothing else other than the required binaries. Maybe someone is doing this.
Post reply on HN