Live data from Hacker News

Unfashionably secure: why we use isolated VMs

blog.thinkst.com

121–130 of 256 posts

Re: Unfashionably secure: why we use isolated VMs

#121
post #6

Earlier quoted context omitted.

For me it's about the ROAC property (Runs On Any Computer). I prefer working with stuff that I can run. Running software is live software, working software, loved software. Software that only works in weird places is bad, at least for me. Docker is pretty crappy in most respects, but it has the ROAC going for it. I would love to have a "docker-like thing" (with ROAC) that used VMs not containers (or some other isolat…

Vagrant / Packer?

Wouldn't work here, they have software on each VM that cannot be reimaged. To use Packer properly, you should treat like you do stateless pod, just start a new one and take down the old one.

Re: Unfashionably secure: why we use isolated VMs

#122
post #105

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

I've always hated the docker model of the image namespace. It's like those cloud-based routers you can buy. Docker actively prevents you from having a private repo. They don't want you to point away from their cloud. Redhat understood this and podman allows you to have a private docker infrastructure, disconnected from docker hub. For my personal stuff, I would like to use "FROM scratch" and build my personal contain…

One of the first things I did was set up a my own container registry with Docker. It's not terribly difficult.

Re: Unfashionably secure: why we use isolated VMs

#123
post #107
post #105

Earlier quoted context omitted.

I've always hated the docker model of the image namespace. It's like those cloud-based routers you can buy. Docker actively prevents you from having a private repo. They don't want you to point away from their cloud. Redhat understood this and podman allows you to have a private docker infrastructure, disconnected from docker hub. For my personal stuff, I would like to use "FROM scratch" and build my personal contain…

> Docker actively prevents you from having a private repo. In what ways? I use private repos daily with no issues.

If you reference a container without a domain, you pull from docker.io

With podman, you can control this with

  $HOME/.config/containers/registries.conf 
or

  /etc/containers/registries.conf
with docker, not possible (though you can hack mirrors)

https://stackoverflow.com/questions/33054369/how-to-change-t...

Re: Unfashionably secure: why we use isolated VMs

#124
post #93
post #90

Earlier quoted context omitted.

So… Lambda, Fargate, and EC2. The only thing you can't really do this with is EKS. Like Firecracker was made by AWS to run containers on their global scale KVM, EC2.

Lambda and Fargate are implementations of the idea, not a way for you yourself to do any kind of KVM container provisioning. You can't generally do this on EC2; you need special instances for it. For a variety of reasons, I'm pretty familiar with Firecracker.

What I'm I missing? AWS offers (virtual) hardware backed containers as a service, I would go so far as to say that a significant number of people are running vm backed containers.

And I've been at a few shops where EC2 is used as the poor-man's-firecracker by building containers and then running 1(ish) per VM. AWS's architecture actively encourages this because that's by far the easiest security boundary to manipulate. The moment you start thinking about two privilege levels in the same VM you're mostly on your own.

The number of people running production workloads who, knowingly or not, believe that the security boundary is not between containers but between the vms enclosing those containers is probably almost everyone.

Re: Unfashionably secure: why we use isolated VMs

#125
post #99

Earlier quoted context omitted.

OpenBSD is not secure by any measure. That Theo happens to be right about the endless clown parade is independent of his ability to develop a secure operating system. I mean, jeez, even Joanna Rutkowska acknowledges the foundations are iffy enough to only justify claiming “reasonably secure” for Qubes OS. You are making a extraordinary claim of security which stands diametrically opposed to the consensus that things…

So far all I'm seeing here are appeals to the names of people who I don't believe agree with your take. You're going to need to actually defend the argument you made.

You mean your argument that it is hard to find a vulnerability, despite the fact that commercial systems in Unix kernel lineage have historically been easy to hack and have never once demonstrated high robustness?

You have not even established what level of security you are arguing has been achieved. This is not even moving the goalposts, this is Calvinball.

I contend that a major cloud service, that runs trillions of dollars of commerce is at least as important as a fighter jet. The F-35 demanded a operating system certified according to the SKPP which follows in the heels of the Orange Book Level A1. That demanded a formal specification, formal proofs, and a failed penetration test by the NSA.

Do you contend that KVM has reached such a standard? Or do you argue that such a standard is too high? What standard should be expected? How do you verify such a standard has been achieved? How does that trace to operational security goals?

The operational security goal commerce needs is for the expected value of an attack to be unprofitable. How are you verifying your axiomatic arguments are moving that needle?

Thinking that everything is insecure and all that matters is “better” is not even binary thinking, it is unary thinking. There is no meaningful discussion to be had until you:

1. Establish a measure and level of security that matches operational goals.

2. Demonstrate proposed mechanisms empirically achieve such goals or have a track record of achieving the desired level of quality such that the reputation may provide some coarse substitute for evidence.

Until that point it is: “Dude, trust me. I have been wrong every time before, but I totally got it this time.”

Re: Unfashionably secure: why we use isolated VMs

#127

Earlier quoted context omitted.

I'd note I didn't say you copied it, just that I created it first (i.e. "compare paper to docker". also, as you note, its possible someone else did it too, but at least my conception got through academic peer-review / patent office, yeah, there's a patent, never been attempted to be enforced though to my knowledge). when I describe my work (I actually should have used quotes here), I generally give air quotes when sa…

I understood your point. I wanted to clarify, and in some ways connect with you. At the time, I didn't know what I was doing. Maybe my colleagues did some more, but I doubt that. I just wanted to stop waking up at night because our crappy container management code was broken again. The most brittle part was the lifecycle of containers (and their filesystem). I recall being very adamant about the layered filesystem, b…

they did it "simpler", i.e. academic work has to be "perfect" in a way a product does not. so (from my perspective), they punted the entire concept of making what I would refer to as a "layer aware linux distribution" and just created layers "on demand" (via RUN syntax of dockerfiles).

From an academic perspective, its "terrible", so much duplicate layers out in the world, from a practical perspective of delivering a product, it makes a lot of sense.

It's also simpler from the fact that I was trying to make it work for both what I call "persistent" containers (ala pets in the terminology) that could be upgraded in place and "ephemeral" containers (ala cattle) when in practice the work to enable upgrading in place (replacing layers on demand) to upgrade "persistent" containers I'm not sure is that useful (its technologically interesting, but that's different than useful).

My argument for this was that this actually improves runtime upgrading of systems. With dpkg/rpm, if you upgrade libc, your systems is actually temporarily in a state where it can't run any applications (in the delta of time when the old libc .so is deleted and the new one is created in its place, or completely overwrites it), any program that attempts to run in that (very) short period time, will fail (due to libc not really existing). By having a mechanism where layers could be swapped in essentially an atomic manner, no delete / overwrite of files occurs and therefore there is zero time when programs won't run.

In practice, the fact that a real world product came out with a very similar design/implementation makes me feel validated (i.e. a lot of phd work is one offs, never to see the light of day after the papers for it are published).

Re: Unfashionably secure: why we use isolated VMs

#128

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

Docker is fantastic and VMs are fantastic.

I honestly can’t imagine running all the services we have without containers. It would be wildly less efficient and harder to develop on.

VMs are wonderful when you need the security

Re: Unfashionably secure: why we use isolated VMs

#129
post #61

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

Isn't this discussion based on a false dichotomy? I, too, use VMs to isolate customers, and I use containers within those VMs, either with or without k8s. These tools solve different problems. Containers solve software management, whereas VMs provide a high degree of isolation. Container orchestration is where I see the great mistake in all of this. I consider everything running in a k8s cluster to be one "blast doma…

> Container orchestration is the thing I believe is "overused." It was designed to solve "hyper" scale problems, and it's being misused in far more modest use cases where VMs should prevail.

As a relatively early corporate adopter of k8s, this is absolutely correct. There are problems where k8s is actually easier than building the equivalent capability elsewhere, but a lot of uses it's put to seem to be driven more by a desire to have kubernetes on one's resume.

Re: Unfashionably secure: why we use isolated VMs

#130
post #105

As a permanent "out of style" curmudgeon in the last ~15 years, I like that people are discovering that maybe VMs are in fact the best approach for a lot of workloads and the LXC cottage industry and Docker industrial complex that developed around solving problems created by themselves or solved decades ago might need to take a hike. Modern "containers" were invented to make things more reproducible ( check ) and sim…

I've always hated the docker model of the image namespace. It's like those cloud-based routers you can buy. Docker actively prevents you from having a private repo. They don't want you to point away from their cloud. Redhat understood this and podman allows you to have a private docker infrastructure, disconnected from docker hub. For my personal stuff, I would like to use "FROM scratch" and build my personal contain…

Huh? In what way does docker prevent you from having a private repo? Its a couple clicks to get on any cloud
Post reply on HN