Live data from Hacker News

Unfashionably secure: why we use isolated VMs

blog.thinkst.com

161–170 of 256 posts

Re: Unfashionably secure: why we use isolated VMs

#161

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 great, way overused 100%. I believe a lot of it started as "cost savings" on resource usage. Then it became the trendy thing for "scalability". When home enthusiasts build multi container stacks for their project website, it gets a bit much.

> When home enthusiasts build multi container stacks for their project website, it gets a bit much.

I don't know - docker has been a godsend for running my own stuff. I can get a docker-compose file working on my laptop, then run it on my VPS with a pretty high certainty that it will work. Updating has also (to date) been incredibly smooth.

Re: Unfashionably secure: why we use isolated VMs

#162
post #135
post #123

Earlier quoted context omitted.

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...

So.. just use a domain. This seems like a nothing burger.

Not all dockerfiles (especially multi-stage builds) are easily sanitized for this.

think FROM python:latest or FROM ubuntu:20.04 AS build

They've put deliberate barriers in the way of using docker commands without accessing their cloud.

Re: Unfashionably secure: why we use isolated VMs

#163
post #88

Earlier quoted context omitted.

Somebody educate me about the problem Packer would solve for you in 2024?

Making machine images. AWS calls them AMIs. Whatever your platform, that's what it's there for. It's often combined with Ansible, and basically runs like this: 1. Start a base image of Debian / Ubuntu / whatever – this is often done with Terraform. 2. Packer types a boot command after power-on to configure whatever you'd like 3. Packer manages the installation; with Debian and its derivatives, this is done mostly thr…

I miss saltstack. I did that whole litany of steps with one tool plus preseed.

Re: Unfashionably secure: why we use isolated VMs

#164
post #58

Earlier quoted context omitted.

A sane DevOps workflow is with declarative systems like NixOS or Guix System, definitively not on a VM infra in practice regularly not up to date, full of useless deps, on a host definitively not up to date, with the entire infra typically not much managed nor manageable and with an immense attack surface... VMs are useful for those who live on the shoulder of someone else (i.e. *aaS) witch is ALL but insecure.

I'm not sure what you're referring to here? Our cloud machines are largely VMs. Deployments mean building a new image and telling GCP to deploy that as machines come and go due to scaling. The software is up to date, dependencies are managed via ansible. Maybe you think VMs means monoliths? That doesn't have to be the case.

That's precisely the case: instead of owning hw, witch per-machine it's a kind-of monolith (even counting blades and other modular solution), you deploy a full OS or half-full to run just a single service, on top of another "OS". Of course yes, this is the cloud model, and is also the ancient and deprecated mainframe model, with much more added complexity and no unique ownership with an enormously big attack surface.

Various return of experience prove that cloud model is not cheap nor reliable than owning iron, it's just fast since you live on the shoulders of someone else. A speed you will pay at an unknown point in time when something happen and you have zero control other that.

DevOps meaning the Devs taking over the Ops without having the needed competences, it's a modern recipe to a failing digital ecosystems and we witnessed that more and more with various "biblical outages" from "Roomba devices briked due to an AWS mishap, cars of a certain vendor with a slice or RCEs, payment systems outages, ... a resilient infra it's not a centrally managed decentralized infra, it's a vast and diverse ecosystem interoperating with open and standard tools and protocols. Classic mail or Usenet infra are resilient, GMail backed by Alphabet infra is not.

What if Azure tomorrow collapse? What's the impact? What's the attack surface of living on the shoulder of someone else, typically much bigger than you and often in other countries where getting even legal protections is costly and complex?

Declarative systems on iron means you can replicate your infra ALONE on the iron, VMs meaning you need much more resources and you do not even know the entire stack of your infra, you can't essentially replicate nothing. VMs/images are still made the classical '80s style semi-manual way with some automation written by a dev knowing just how to manage his/her own desktop a bit and others will use it careless "it's easy to destroy and re-start", as a result we have seen in production images with someone unknown SSH authorized keys because to be quick someone pick the first ready made image from Google Search and add just few things, we are near the level of crap of the dot-com bubble, with MUCH more complexity and weight.

Re: Unfashionably secure: why we use isolated VMs

#165
post #104
post #58

Earlier quoted context omitted.

A sane DevOps workflow is with declarative systems like NixOS or Guix System, definitively not on a VM infra in practice regularly not up to date, full of useless deps, on a host definitively not up to date, with the entire infra typically not much managed nor manageable and with an immense attack surface... VMs are useful for those who live on the shoulder of someone else (i.e. *aaS) witch is ALL but insecure.

VMs are useful when you don't own or rent dedicated hardware. Which is a lot of cases, especially when your load varies seriously over the day or week. And even if you do manage dedicated servers, it's often wise to use VMs on them to better isolate parts of the system, aka limit the blast radius.

Witch is a good recipe to pay much more thinking to be smart and pay less, being tied to some third parties decisions for anything running, having a giant attack surface and so on...

There are countless lessons about how owning hw is cheaper than not, there are countless examples of "cloud nightmares", countless examples of why a system need to be simple and securely design from start not "isolated", but people refuse to learn, specially since they are just employees for living on the shoulder of someone else means less work to do and managers typically do not know even the basic of IT to understand.

Re: Unfashionably secure: why we use isolated VMs

#166
post #88

Earlier quoted context omitted.

Somebody educate me about the problem Packer would solve for you in 2024?

What's a better way to make VM images?

There's lots of tools in this space. I work on https://github.com/systemd/mkosi for example.

Re: Unfashionably secure: why we use isolated VMs

#167
post #150

Earlier quoted context omitted.

> This is wrong in pretty much every way I can imagine. Nope! It’s not wrong in any way at all! You’re thinking of how it’s built. I’m thinking of what it does (for me). I tell it a package (image) to fetch, optionally at a version. It has a very large set of well maintained up-to-date packages (images). It’s built-in, I don’t even have to configure that part, though I can have it use other sources for packages if I…

> You’re thinking of how it’s built. I’m thinking of what it does (for me). I've read your reply and I hear you (now). But as far as I'm concerned package management is a little more than that. Not everything that installs or uninstalls software is a package manager-- for instance I would say that winget and Chocolatey are hardly package managers, despite their pretensions (scoop is closer). I think of package manage…

Oh no, you’re fine, thanks for responding in kind, I get where you’re coming from now too. Maybe it’s clearer to label my use of it as a software manager or something like that. It does end up being my main interface for nearly everything that matters on my home server.

Like, I’m damn near running Docker/Linux, in the pattern of gnu/Linux or (as started as a bit of a joke, but is less so with each year) systemd/Linux, as far as the key parts that I interact with and care about and that complete the OS for me.

As a result, some docker alternatives aren’t alternatives for me—I want the consistent, fairly complete UI for the things I use it for, and the huge library of images, largely official. I can’t just use raw lxc or light VMs instead, as that gets me almost nothing of what I’m currently benefiting from.

I haven’t run into a need to have dependent services (I take the SQLite option for anything that has it—makes backups trivial) but probably would whip up a little docker-compose for if I ever need that. In work contexts I usually just go straight for docker-compose, but with seven or eight independent services on my home server I’ve found I prefer tiny shell scripts for each one.

[edit] oh, and I get what you mean about it not really doing things like solving software dependencies—it’s clearly not suitable as, like, a system package manager, but fills the role well enough for me when it comes to the high-level “packages” I’m intending to use directly.

Re: Unfashionably secure: why we use isolated VMs

#170

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…

As the person who created docker (well, before docker - see https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and compare to docker), I argued that it wasn't just good for containers, but could be used to improve VM management as well (i.e. a single VM per running image - see https://www.usenix.org/legacy/events/lisa11/tech/full_papers... ) I then went onto built a system with kubernetes that enabled on…

> any security advantage they have is simply due lack of bugs, not simply a better design.

feels like maybe there is some corelation

Post reply on HN