Runc: Is runC alone suitable for a production environment?

[Andreyooo]

I'm a beginner in the container world and was wondering if runC alone is suitable for a production environment.

We need a lightweight implementation for containers and dockers daemon interface has to much overhead, so the idea was to export the docker image and run it with runC.

Is there something to watch out for? We intend to only run one container, so container management features are negligible.

[CrunchylnMilk]

Short Answer: Not alone - try Podman. No daemon to bloat your system, command compatible with docker, and can pull and run docker images - no extraction necessary.

Long Answer:
In the strictest sense yes; as the de facto implementation of the OCI spec, runc is the final software (other than linux primitives) invoked by many container software chains (including docker).

That said, though it can be, runc is not really meant to be invoked directly by the user - it's meant to be part of a containerization toolchain. An awful lot of setup, configuration, and preparation is required for Runc, and your security absolutely depends on getting this configuration right. It is _technically possible_ to do this security and network setup by hand, but discouraged in the strongest possible terms.

Personally, I would suggest you see if Podman is available on your distro. It is almost completely command compatible with docker (except for swarm and remote administration features), which means you can literally look at the docker documentation for how to do almost anything, change the word 'docker' to 'podman', and it will work fine. Like Docker, Podman uses runc under the hood, but uses the more traditional *nix fork/exec model. This means Podman has no daemon constantly running to consume resources, and does not have the glaring security hole of the docker socket. I have no commercial stake in Podman, but personally (and happily) use it instead of docker in production. It can also pull and run docker images out of the box.

Please note that the usual caveats apply - containerization (with ANY container runtime) is not automatic security. Running a production application in a properly configured (strongest possible emphasis on properly configured) container can absolutely help harden against certain kinds of threat, but there's a LOT that goes into infrastructure security.

On a final note, you mentioned being a newcomer to the container world (welcome :-)). It's a lot of fun, definitely the future, and has a ton of promise. That said, container development and management is a fundamentally different set of skills than a lot of newcomers (even experienced IT pros) are used to, and while definitely not _hard_, learning to develop a secure container (and infrastructure) takes some time. I'm not trying to tell you what to do, but you might not want to jump right into production. If you have the option, you might want take the time to experiment in a safe development environment before pitting your server against the unwashed hacker hordes.

[cyphar]

Yeah, if you're familiar with how containers operate you can use runc directly as part of a larger custom container management system (and runc itself is production-ready -- it's used by effectively every deployment of Docker, Kubernetes, et al). But I wouldn't recommend using it directly unless you have very specific requirements that preclude the use of easier-to-use tools like podman/docker/lxd/etc.

The main thing to be worried about using it directly is the fact that configuration is something that's entirely up to you. Tools like umoci do generate pretty-good default configurations but if you use a management tool like Docker/Podman/LXD, those tools also manage security profiles (seccomp, apparmor, selinux) which you would have to do manually without them. There are also other administrative things which container managers do for you (secure setup of image storage for instance) that you may need to end up managing yourself.

Also you should be aware of how terminal handling works with runc, because that is probably going to trip you up at some point if you're using runc directly.

[kolyshkin]

I guess this is now answered, so it can be closed.

I have added a note to README about using runc directly, based on the comments above (https://github.com/opencontainers/runc/pull/2714).

[Andreyooo]

I see, that helps a lot. Thank you for your clarification @CrunchylnMilk & @cyphar .