[Havoc]

Think it is rapidly moving towards being more of a data carrier/format rather than being dead per se.

Half the time you're jamming it into some cloud service anyway where you have no idea what GCP/fly/aws is using under the hood to actually run it.

Meaning this discussion is more relevant to the self-hosted context. In which case I'd say containerization isn't really security. So in my mind that residual risk of the daemon being root is inconsequential. (Or if not use a VM).

[pjmlp]

Indeed the proof being stuff like Kata Containers, which augment them with VMs anyway.

Personally, after dealing with Kubernetes yaml spaghetti, I rather deal with VM images, but unfortunately I don't get to dictate IT fashion.

[djbusby]

I'm still in the VM all the things camp. Like, containers are neat but VMs have the same cheapness for me - that is deploy some VM per app. Like Docker per app. Many times these days I'm one VM for just one Docker package. (Can you tell VM is my favorite isolation method)

[Havoc]

>I'm still in the VM all the things camp.

I do both with deciding factor being whether it has internet exposure.

>VMs have the same cheapness for me

It's all kinda relative (ballooning etc), but from what I've seen LXC allows for much higher density. Lowest LXC I've got running is ~20MB used. Lowest VM is at 380MB. Both headless debians so vaguely comparable (though MQTT vs Wireguard).

Not much of a difference if you've got a 128gb server on hand, yet its nearly 20x so depending on perspective its either a big difference or doesn't matter.

[jolux]

Fargate and Fly are actually both Firecracker VMs, not containers.

[djbusby]

Yea, super fast boot VMs are a game changer in the container vs VM game.

[LunaSea]

I don't think people mind using VMs rather than containers.

The preference comes from the tool chain which is simpler for containers (even if you use Vagrant) and performance ( true or not, lots of people still have the sluggish VMs in mind.

[tluyben2]

> lots of people still have the sluggish VMs in mind.

I did, until trying firecracker.

[magicalhippo]

I'm quite new to this side of things. Could you shed some light on how I could get docker-like simplicity but in VMs?

[ungamedplayer]

Just to be clear, privileged containers with CAP_SYS_ADMIN do have additional privileges outside of normal 'containerized' workloads, just having it in a container does not mean that the security side affects are inconsequential.

[krageon]

Kind of a weird take, to be honest. If containerization is not security, them not running as root should be an absolutely critical first step for managing risk.

[Havoc]

>If containerization is not security

Call it less secure than VMs if you prefer that wording.

>not running as root should be an absolutely critical first step for managing risk.

Kinda depends on what angle you come at it from risk management. You could take something less secure (containers) and try to tweak it to meet whatever level of residual risk you deem acceptable. Or you could just jump straight to VM and benefit from the inherent higher level of separation.

The fact that all the big players with their clever engineers have specifically opted for VM tech (e.g. AWS creating firecracker for lambda) tells me the later is probably the way to go.

That said I mostly do stick to containers when in a trusted environment.

[krageon]

The "if" was not meant to indicate I doubted you. I agree. It was to indicate a prior in the sense of "if this is true, this other thing should also be true).

VMs are also not a foolproof solution to operational security. It depends entirely on your risk appetite. If you're going to run containers, you should run them with as little permissions as you can. Hence, rootless.