In a blog post, Ian Lumb, leader of business development at Sylabs, walks through the highlights of the Singularity 3.4.0 release. “It’s a HUGE release for us, as this is the first time a container platform has been able to offer a comprehensive scheme for confidentiality via encryption,” he told HPCwire. Here’s an excerpt from the blog with a link to read more.

---

TL;DR: The generally available release of Singularity 3.4.0 allows you to build and run encrypted containers. Encryption is applied at rest, in transit, and during execution. The software is immediately available here. 

The generally available release of Singularity 3.4.0 places emphasis on a single feature: the ability to build and run encrypted containers. We appreciate that some might object to our propensity towards hyperbole, given that seemingly sweeping statement. And that’s precisely what makes this release, frankly, a remarkable one; to quote from the release notes:

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. Furthermore, Adam surmises that:

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.

As one of the development leads closest to the implementation of support for encryption, Satish Chebrolu opines that the single-file format, and not having to worry about securing multiple layers, is what makes the approach taken in Singularity highly differentiating.

As you might expect, implementing a comprehensive capability to support encryption over a container’s entire lifecycle is a team sport. Satish initiated the effort and contributed on an ongoing basis. On the development front, his efforts were aided by fellow software engineer Marcelo Magallon, and in-flight testing was contributed by Adam, Dave Godlove, David Trudgian, and Geoffroy Vallee. Finally, Ian Kaneshiro made various contributions to correspondingly enhance the Singularity CLI; based upon even a cursory scan of the release notes, it will become readily evident that encryption supports PEM-encoded RSA keys and passphrases.