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

11–20 of 109 posts

Re: Containers are tents

#11

Post by flatline »

RcouF1uZ4gsC wrote: post #5
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…

> 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. What I find interesting, is that many uses of containers are just reinventing statically linked binaries in a more complicated form.

They are different means of composition. Dynamically (I assume that’s what you meant?) linked libraries allow you to compose binary artifacts. Containers allow you to compose services.

Re: Containers are tents

#12

Post by smitty1e »

I explain that if the an Amazon Virtual Private Cloud (VPC) is a datacenter "cloud", then a container implementation is a "puff".

Virtualizing the kernel like the Amazon Machine Image (AMI) virtualizes a chip core sounds great. But now, in the "puff", all of those networking details that AWS keeps below the hypervizor line confront us. Storage, load balancing, name services, firewalls. . .

Containers can solve packaging issues, but wind up only relocating a vast swath of other problems.

Re: Containers are tents

#14

Post by kasey_junk »

adolph wrote: post #8
kasey_junk wrote: post #6

Earlier quoted context omitted.

Do you have any links to secure container runtimes that don’t either virtualize or replace all the system calls of the container such that it might as well be virtual?

Maybe Singularity? https://sylabs.io/guides/3.5/admin-guide/configfiles.html

Singularity is likely* less secure than default container runtimes.

*not a security person or an expert on singularity but it advertises that it doesn’t do file system or user isolation by default

Re: Containers are tents

#15

Post by lanstin »

flatline wrote: post #11
RcouF1uZ4gsC wrote: post #5

Earlier quoted context omitted.

> 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. What I find interesting, is that many uses of containers are just reinventing statically linked binaries in a more complicated form.

They are different means of composition. Dynamically (I assume that’s what you meant?) linked libraries allow you to compose binary artifacts. Containers allow you to compose services.

Not sure what you mean. The network lets you compose services. It has for decades been possible to do that.

Containers as a form of static linking means that you ship one thing to prod and it has everything you need locally in it and it can’t be changed without you releasing a new one thing. If someone else upgrades MySQL client version on the host, your code keeps using the version you tested with, like a static binary or like a Python venv with pinned versions or vendored dependencies. It is a lot simpler to manage dependencies this way; downside is if you one of your dependencies has a security advisory, it can’t be updated by rolling out a new version by someone else. You have to update it, so unowned code becomes more expensive in that scenario.

Re: Containers are tents

#16

Post by eVeechu7 »

>Finally, there’s the whole business of resource isolation. While cgroups are pretty neat as an isolation mechanism, they’re not hardware-level guarantees against noisy neighbors. Because cgroups were a later addition to the kernel, it’s not always possible to ensure they’re taken into account when making system-wide resource management decisions.

I don't think virtualization really offers hardware-level guarantees against noisy neighbours either.

Re: Containers are tents

#17

Post by nickelpro »

RcouF1uZ4gsC wrote: post #5
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…

> 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. What I find interesting, is that many uses of containers are just reinventing statically linked binaries in a more complicated form.

Those are two different things. If I need GCC 11 and its associated standard libraries and toolchain to build my app, and I need to build that app on CI services that ship an older version of GCC, I need some way to bundle my dependencies for arbitrary compute fabrics.

The answer to this is a container. Containers don't "reinvent" static linking, they solve problems that go beyond static linking.

Re: Containers are tents

#18

Post by encryptluks2 »

kasey_junk wrote: post #6
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.

Do you have any links to secure container runtimes that don’t either virtualize or replace all the system calls of the container such that it might as well be virtual?

First, saying it might as well be virtual is a bit of a misnomer. There are various options, and although they may act like a VM they are significantly faster than machine-based VMs like QEMU:

https://kubernetes.io/docs/concepts/policy/pod-security-poli...

> As of Kubernetes v1.19, you can use the seccompProfile field in the securityContext of Pods or containers to control use of seccomp profiles.

If you're looking for a more general abstraction, there is gVisor and others as well.

Re: Containers are tents

#19

Post by wmf »

smitty1e wrote: post #12

I explain that if the an Amazon Virtual Private Cloud (VPC) is a datacenter "cloud", then a container implementation is a "puff". Virtualizing the kernel like the Amazon Machine Image (AMI) virtualizes a chip core sounds great. But now, in the "puff", all of those networking details that AWS keeps below the hypervizor line confront us. Storage, load balancing, name services, firewalls. . . Containers can solve packag…

If you have few enough containers you can give each one an ENI.

Re: Containers are tents

#20

Post by viraptor »

kasey_junk wrote: post #6
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.

Do you have any links to secure container runtimes that don’t either virtualize or replace all the system calls of the container such that it might as well be virtual?

We can't answer that question because "secure container runtime" is not a well defined idea. Secure from what, in what way, with what guarantees? Docker is both secure and not depending how you draw the lines.
Post reply on HN