[cpuguy83]

It is important to understand that as implemented by runtimes such as docker, containerd, cri-o, and podman, containers are absolutely a security device.

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.

These are the same sort of things that chrome, for instance, does to make it harder to do bad things from the browser. They are hardening techniques. Images are automatically checksummed on download, and for certain things even signatures are checked (more of this soon).

Just because they do not protect you from a kernel exploit (also actually not true, seccomp filters have prevented a number of kernel exploits from inside the container) does not mean they are not added security.

The important thing to know what your attack surface is and what is acceptable risk for the workloads you are running. And yes, it is important to understand that containers do not isolate you completely from kernel exploits.

It is also important to understand the control plane (runtime up to the orchestrator) is much more likely to introduce security issues than the container itself.

[raesene9]

Obviously containers do add a of security relative to uncontained processes but there are security challenges(as I'm sure you're aware)

There are multiple independent projects involved in securing a standard orchestrated docker style container (some of the set of Linux kernel/Linux distro/runc/containerd/docker/k8s) and no obvious owner of overall security configuration and problems.

we've seen examples of this, e.g. k8s disabling Docker's seccomp filter, or more recently the difficulty in how to handle clone(3) and seccomp filters.

For me it's that comparison with dedicated security sandboxes, is that in other projects there's a single team handling the whole security picture , which is likely to make things easier to manage.

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

[andrewstuart2]

It's also important to remember that security is not merely confidentiality. Kubernetes and docker both assist in availability and integrity through redundancy and (at least for most of its history) the ability to run code by content-addressed cryptographic hashes. And validate other signatures etc.

There are a ton of security mechanisms that are enabled by the ecosystem itself, even if it does introduce new complexities and does have certain weaknesses against full hardware virtualization. It also has significant and meaningful security strengths (namely in availability via lower resource usage) against exclusively using hardware virtualization.

[AtNightWeCode]

Agree, if you then like some of the huge companies spin up containers per user/customer it works more or less as sandboxes giving huge security benefits.