Sylabs just released the Singularity 3.4.0. The major new feature of this release is the ability to build and run encrypted containers. These containers are encrypted at rest, in transit, and even while running. There is no intermediate decrypted rootfs left around upon termination. Data is decrypted totally in kernel space.
In other words, Singularity containers remain encrypted throughout their entire lifecycle — when they are created, when they are at rest or transferred around, and yes, even when they are in use. Owing to their use of kernel space for data decryption, there is no need to clean up a decrypted rootfs upon termination.
The Single-File Advantage
In some ways, Singularity exploits an unfair advantage: use of a single file to encapsulate the entire container runtime. Sylabs software architect Adam Hughes frames it this way:
From a technical point of view, it’s certainly more complicated in the Open Container Initiative (OCI) case. Individual layers may or may not be encrypted, and/or they might be encrypted with different keys, etc.
The inherent complexity of encryption in the OCI case is well reflected by progress in standards and implementations — the most promising of which today only address but an isolated layer at rest.
In striking contrast, the single-file approach that is employed in the Singularity Image Format (SIF) has the benefit of not needing to decrypt multiple layers, and put them somewhere before running:
Container startup cost should be lower owing to the single-file approach. Because there’s no need to decrypt the rootfs to a filesystem before running, it is reasonable to argue that this single-file approach is also more appealing from a security point of view. In our estimation encryption over an image’s entire lifecycle, that does not impair its mobility in any way, far outweighs any economies associated with layer-based decompositions — e.g., in cases where a static base image may be layered together with a relatively small amount of sensitive content.
