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

My VM is lighter (and safer) than your container (2017)

dl.acm.org

Post reply on HN
Print view View original

151–160 of 184 posts

Re: My VM is lighter (and safer) than your container (2017)

#151

Post by Aardwolf »

zokier wrote: post #137
BobbyTables2 wrote: post #115

Earlier quoted context omitted.

You mean for the container launcher to not require root? Root isn’t required — look at Podman. Docker spent so much on marketing, the world is too blind to pivot to a superior alternative!

People were running containers for a decade before rootless podman came around. There has been lot of sharp corners around userns and related tech that needed to get resolved. Notably Debian& Ubuntu disabled unprivileged userns for some legitimate security concerns

I really don't get that: having to run something substantial as root seems a much bigger security concern, than what it is shielding from user space (example: hosting a web server at port 80)

Re: My VM is lighter (and safer) than your container (2017)

#152

Post by bigstrat2003 »

oneplane wrote: post #66
kkfx wrote: post #61

Earlier quoted context omitted.

NixOS and Guix System offer a far lighter and more reproducible approach, who also not push many running images build by unknown on the internet direct in production, full of outdated deps, wasting in the meantime storage and cpu resources...

Yet it doesn't even come close to a fraction of the adoption scale of containers, no matter how good it is. Ecosystems matter more than individual quality.

I think that's a gross overstatement. Ecosystems matter, yes. But they don't matter more than quality.

Re: My VM is lighter (and safer) than your container (2017)

#153

Post by epr »

zokier wrote: post #137
BobbyTables2 wrote: post #115

Earlier quoted context omitted.

You mean for the container launcher to not require root? Root isn’t required — look at Podman. Docker spent so much on marketing, the world is too blind to pivot to a superior alternative!

People were running containers for a decade before rootless podman came around. There has been lot of sharp corners around userns and related tech that needed to get resolved. Notably Debian& Ubuntu disabled unprivileged userns for some legitimate security concerns

Funny, the original commit message for that suggests it was simply a precaution. It's not out of the ordinary to avoid newer kernel features just in case.

> This is a short-term patch. Unprivileged use of CLONE_NEWUSER is certainly an intended feature of user namespaces. However for at least saucy we want to make sure that, if any security issues are found, we have a fail-safe.

from: https://web.archive.org/web/20211022013829/https://kernel.ub...

Re: My VM is lighter (and safer) than your container (2017)

#154

Post by ajross »

bayindirh wrote: post #150
ajross wrote: post #146

Earlier quoted context omitted.

All security boundaries are "incidental" in that sense, though. Virtualization isn't a "purpose-designed" security boundary either, most of the time it's deployed for non-security reasons and the original motivation was software compatibility management. The snobbery deployed in this "containers vs. VMs" argument really gets out of hand sometimes. Especially since it's almost never deployed symmetrically. Would you m…

> All security boundaries are "incidental" in that sense, though X86 protected mode, processor rings, user isolation in the multi user operating systems, secure execution environments in X86 and ARM ISAs, kernel and userspace isolation, etc. are purpose built security boundaries. Virtualization is actually built to allow better utilization of servers, which is built as a "nested protected mode", but had great overhea…

The motivation for MMU hardware was reliability and not "security". Basically no one was thinking about computer crime in the 1970's. They were trying to keep timesharing systems running without constant operator intervention.

Re: My VM is lighter (and safer) than your container (2017)

#155

Post by surajrmal »

FridgeSeal wrote: post #140
__jonas wrote: post #121

Earlier quoted context omitted.

I thought that’s what fly.io is, although I’m not familiar with it, am I missing something?

Fly: takes your docker image, converts it into a Firecracker VM and runs that: kernel boundaries etc are all the same as before (and the same as running your container locally). Kraft Cloud: takes your docker image, and turns it into a “unikernel”, and runs that. In a unikernel, your application _is_ the kernel. There’s no process boundary, no kernel-space/userspace split there’s a single address-space etc. I believe…

It sounds like consequences of bugs like memory corruption are far more challenging to deal with in the Kraft cloud situation. Sometimes isolation has other benefits.

Re: My VM is lighter (and safer) than your container (2017)

#156

Post by jetbalsa »

sureglymop wrote: post #136
fhuici wrote: post #96

Earlier quoted context omitted.

Maybe try out kraft.cloud: we take Dockerfiles as input and automatically convert to lightweight VMs/unikernels when deploying (disclaimer: I'm one of the paper's authors and one of the people behind KraftCloud).

I recently built a similar thing for learning purposes using firecracker + the firecracker go api. I wrote a small init system in rust and combined that with filesystem images derived from the Debian, Ubuntu etc. container images (that can be extended with more layers). What really surprised me the most, is how quick and simple it is to compile the linux kernel. Cloned a tag with --depth 1, configured it and then it…

it /used/ to take forever back in the Core 2 Duo days, with the amount of cores and the sheer speed of the IPC its gotten a ton better.

Re: My VM is lighter (and safer) than your container (2017)

#157

Post by DEADMINCE »

zerof1l wrote: post #80

Docker has a big community, lots of guides, and ready-to-use containers. It became pretty much a de facto standard for self-hosting things. You also have a very high chance of getting a piece of software to work out of the box as intended with Doker. The only way this or some other way of running stuff will overtake Doker is if it will match the Docker in these aspects. As much as I'd love to try this lightweight VM…

> making my existing setup more secure and robust.

The first step should be to not be so entirely reliant on Docker.

Re: My VM is lighter (and safer) than your container (2017)

#158

Post by Melatonic »

internetter wrote: post #116
fhuici wrote: post #53

Earlier quoted context omitted.

Check out kraft.cloud and the accompanying LF OSS project www.unikraft.org :) (disclaimer: I'm one of the authors of the paper and one of the people behind that cloud offering). On KraftCloud we use Dockerfiles so users can conveniently specify the app/filesystem, and then at deploy time transparently convert that to a unikernel (specialized VMs). With this in place, NGINX cold starts in 20 millis, and even heavier a…

Is the entire kraft stack open source? Can I run this on my own hardware?

Also was my question.

Re: My VM is lighter (and safer) than your container (2017)

#159

Post by bluGill »

cesarb wrote: post #85
bluGill wrote: post #60

Earlier quoted context omitted.

There is no such thing as a reproducible build environment anymore. You can get a temporary reproducible build environment, but any sane security policy will have certificates that expire and that in turn means that in a couple years your build environment won't be reproducible anymore.

> but any sane security policy will have certificates that expire and that in turn means that in a couple years your build environment won't be reproducible anymore. "Reproducible" is usually defined as "identical output except for the cryptographic signature at the end" (and that should be the only use for a certificate in your build environment, a high-quality build environment should be self-contained and have no…

I said environment not build.

Re: My VM is lighter (and safer) than your container (2017)

#160

Post by nailer »

kevincox wrote: post #38
nailer wrote: post #31

Earlier quoted context omitted.

> If there is some additional isolation required, just run the container in a VM. No. Running a container in a VM gets you no additional isolation. Containers share kernel space and as such have limited isolation to VMs, which have isolated kennels. In exchange for this Lack of additional isolation, you’ve added a Bunch of extra Complexity. Pardon the extra caps I am using iOS voice dictation.

I think they mean run a VM with one container inside. So you do get strong isolation. This is similar to how managed container IaaS works. They launch a VM and run your container in it. It is extra complexity but has a few advantages. 1. People already have a convenient workflow for building container images. 2. The base OS can manage hardware, networking and whatever other low-level needs so that the container doesn…

> So you do get strong isolation.

No, you don’t. There is no benefit the container is providing, because The only feature of the container is isolating you from the zero other containers running on the VM.

Post reply on HN