Why is systemd-nspawn not appropriate for production deployments?

Question

While reading about systemd-nspawn, it is mentioned that it should not be used in a production environment. The reason seems to be the lack of management and deployment infrastructure. Is practicality the only reason, or are there underlying security/functionality reasons too?

Answer 1

That was mentioned in a presentation by Lennart Poettering in 2013, but in 2015 he was quoted saying the following:

systemd also contains the systemd-nspawn container manager. It's a relatively minimal, yet powerful implementation of a container manager. Initially we wrote it for testing purposes, but nowadays we consider it ready for many production uses. In fact CoreOS' rkt container tool makes use of it as the lower level container backend.

Reference: Where systemd and Containers Meet: Q&A with Lennart Poettering

Answer 2

Your source describes a presentation by the systemd developer Lennart Poettering. Lennart is an employee of Red Hat. Both Red Hat Enterprise Linux, and the Fedora Linux community distribution, use SELinux.

The integration between systemd-nspawn and SELinux appears to be broken, e.g. see rhbz1416540. Also, if you try to access the network from a container started in a private network namespace on Fedora Linux, (the default when using [email protected]), it will be blocked by firewalld.

My conclusion was that systemd-nspawn is not supported for running containers as servers. It probably happens to run on non-Red Hat systems, but you won't have the benefit of any LSM-based protections. Unless you can work something out yourself.

Note that other well-known container managers include LSM-based protections. Particularly Docker, but LXC also includes some policy for AppArmor.

Being production-ready would imply people are auditing, documenting, or even marketing how to use systemd-nspawn securely. I think the systemd developers are being honest in admitting they aren't really doing this, at least at the moment.