Containers are tents • Hacker News Board

Re: Containers are tents

#21

Post by catlifeonmars » Sat, Jun 12, 2021, 3:45 AM UTC

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.

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.

Re: Containers are tents

#22

Post by habeebtc » Sat, Jun 12, 2021, 3:53 AM UTC

eVeechu7 wrote: post #16

>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 a…

It offers the opportunity to throttle noisy neighbors in hopes the party isn't too big.

Re: Containers are tents

#23

Post by 0xCMP » Sat, Jun 12, 2021, 3:54 AM UTC

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.

I think of Docker as a universal static compiler. And I mean that in a positive way: static compiling makes a lot of sense with the incredible complexity we're often finding ourselves in. There really are no other ways to distribute node/ruby/python apps in a static way and when there is it's limited in serious ways beyond often being ONLY for a specific ecosystem (e.g. wheels for python).

Re: Containers are tents

#24

Post by Helmut10001 » Sat, Jun 12, 2021, 4:18 AM UTC

I place all my tents in a house (Docker VMs inside unprivileged LXC containers on Proxmox - yes, unprivileged = not a brick house, more like wood).

The only reason I use Docker is that I can access the system design knowledge that is available with docker-compose.yml's. Last example: Gitlab. Could not get it running on unrivileged LXC using the official installation instructions, with Docker it was simply editing the `.env` and then `docker-compose up -d`. All of this in a local, non-public (ipsec-distributed) network. I often find myself creating a single, separate unprivileged LXC container->Docker nesting for each new container, because I do not need to follow the complicated and error prone installation instructions for native installs.

Re: Containers are tents

#25

Post by kasey_junk » Sat, Jun 12, 2021, 4:43 AM UTC

encryptluks2 wrote: post #18

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?

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 f…

Again, not an expert but security policies aren't immune from container breakouts right?

Which leaves you to either use something like firecracker or gvisor which are either virtualization solutions or the next closest thing in that they intermediate all of your syscalls?

Re: Containers are tents

#26

Post by kasey_junk » Sat, Jun 12, 2021, 4:59 AM UTC

viraptor wrote: post #20

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?

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.

Sure. I mean as secure as a traditional virtualization environment.

Re: Containers are tents

#27

Post by encryptluks2 » Sat, Jun 12, 2021, 5:00 AM UTC

kasey_junk wrote: post #25

encryptluks2 wrote: post #18

Earlier quoted context omitted.

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 f…

Again, not an expert but security policies aren't immune from container breakouts right? Which leaves you to either use something like firecracker or gvisor which are either virtualization solutions or the next closest thing in that they intermediate all of your syscalls?

Almost all container breakout concerns rely on running containers as a privileged user:

https://stackoverflow.com/questions/53024790/kubernetes-supp...

There is an issue that I've been tracking, and there has been a new PR that will hopefully land soon to implement this in Kubernetes in a simplified manner:

https://github.com/kubernetes/enhancements/issues/127

As for whether security policies prevent breakouts, it really depends on what the exploit is but they can significantly help. The idea of user namespace remapping solves a secondary issue though... if there is a breakout, what user privileges will they have.

Re: Containers are tents

#28

Post by Sparkyte » Sat, Jun 12, 2021, 5:37 AM UTC

I was totally expecting this to go in the direction about tech debt with a homeless analogy, but it was about destructability. Yes we know this already and if you catch people treating it as a persistent host, slap their hands and say no.

Re: Containers are tents

#29

Post by Sparkyte » Sat, Jun 12, 2021, 5:42 AM UTC

unethical_ban wrote: post #4

Container tech can be used for small scale "pet" deployment, but my understanding is that the true benefit of containers come with seeing them as "cattle". You should never login to the shell of a container for config. All application state lives elsewhere, and any new commit to your app triggers a new build. If that's not for you, then while containers like proxmox/LXC can still be handy, you're just doing VM at a d…

Only time it should be utilized as a small scale "pet" is when you externalize the storage mounts and it is an on-demand non-persistent virtual environment not directly connected to a data sensitive environment. That's mainly my take on it. I will often use docker locally to test out some kubernetes service connectivity, but never bring my Frankenstein stuff into an environment any higher than local.

Re: Containers are tents

#30

Post by jb_gericke » Sat, Jun 12, 2021, 5:45 AM UTC

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?

Pod security policies and seccomp for call filtering at an OCI level