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?
Unfashionably secure: why we use isolated VMs
121–130 of 256 posts
Re: Unfashionably secure: why we use isolated VMs
#122As 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…
Re: Unfashionably secure: why we use isolated VMs
#123Earlier 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.
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
#124Earlier 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.
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
#125Earlier 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 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
#126Re: Unfashionably secure: why we use isolated VMs
#127Earlier 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…
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
#128As 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 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
#129As 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…
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
#130As 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…