[fulafel]

> These things force the application to run in restricted environments where capabilities are reduced, system calls are filtered, apparmor profiles and selinux labels are applied, among other things

This characterisation is too charitable, without qualifications. It depends a lot on the container runtime and configuration. Out of the box with Docker you don't get AppArmor or SELinux, and apps run as root where they normally wouldn't (because uid remapping, aka user namespaces is disabled by default, and people rarely bother to set up non-root users in containers).

As a bonus, applying security updates is left as an exercise to you, meaning it often doesn't happen.

Also, complexity is the enemy of secutity. Containers are yet another added layer that you have to juggle in your head when trying to make sense of the whole system you're building and operating. If used wisely and with good understanding, monitoring and processes, they can be a net positive despite this, but not necessarily so.

[cpuguy83]

Out of the box apparmor is enabled by default when the system has apparmor available.

I don't recall why we don't turn on selinux when it is available.

[Spivak]

I mean this is basically saying that locks aren't security devices because you have to put them in your door and use them. I guess there's a point there but we are talking about professional devs and ops people. If they can't bother to pass --enable-selinux they aren't gonna use Firecracker either.

And docker at least has an update delivery story (same as microVMs as well) compared to traditional ops where there are patching cycles and anything that can't be yum/apt updated is basically ignored and updated on quarter/year time. Build a base image in your CI pipeline, update it every night, have your app build against it, smoketest deploys, and largely forget that patching exists.

[jiggawatts]

“If they can't bother[ed] to…”

They can’t. Not one developer I have worked with in the last 10 years has lifted a finger in the name of security.

This is why managing containers is a full time job by itself, a specialised discipline.

If you can’t afford an FTE to manage containers you can’t afford containers.

[Spivak]

So is managing VMs and devs don't do that either. Every dev I've ever known (and most ops people tbh) have just unthinkingly turned off SELinux the moment it gets in their way. If you're painting an arbitrary distinction between "containers are fully owned by devs who by assumption don't care about security" and "vm's are fully owned by ops who care about security" then you're doing it wrong. It's like ... the whole point of devops mannn.