Signing the Container

The Singularity 3.0 family introduced the ability to create (and manage) PGP keys to sign and verify containers. This provides a trusted method for Singularity users to share containers and ensures a bit-for-bit reproduction of the original container as the author intended.

For security purposes, it is important that private keys remain private. Singularity Container Services only stores your public key information. In this example, pull the TensorFlow container previously created, sign it, then store the signed container in the SCS Library.

Generating and managing PGP keys

To sign your containers you first need to generate one or more keys with Singularity CLI, which can then be pushed to the SCS Keystore.

Create a new keypair by entering the email address associated with our Singularity Container Services account.

We’ll then enter our account details, add a comment and passphrase (which will not be displayed) and have the Singularity client push it to the keystore.

With that key created, let’s use the command line and web interface to display the keys.

Listing keys

In the output above the index of my key is 0 and the letters stand for the following:

U: User

C: Creation date and time

F: Fingerprint

L: Key length

*for more information on signing, please see the Singularity Signing and Verify documentation

From the SCS Dashboard, we’ll select “My Keys”. Listed below is the key we had created via the SIngularity client and pushed to the SCS Keystore. We can see the Key name and description, creation date, algorithm and bits used in the creation, followed by the fingerprint. From here we also have examples of a container signing and image verification commands.

With verification of the access token, the next step is to check the status of the services.

Pull then Sign the container

*When pulling the container with a tag, you may notice the semicolon is converted to underscore in the resulting file name.

The first time you sign a container, Singularity will generate a PGP signing keypair and optionally upload the public key to Singularity Container Services Keystore, where it will be available for container verification requests. 

Enter the passphrase key you created during the “singularity key newpair” command and you will see the container has been signed. For advanced signing capabilities, such as signing objects withing the SIF, please see Singularity SIF ID’s and Groups documentation.

You can see the details of the signed container by using the singularity sif list command:

Singularity SIF Verification

Use the SIF verification functionality to ensure the local container has not been modified:

If another user ran this verification against an image in SCS Library, Singularity would retrieve the public key from the Keystore automatically, rather than using [LOCAL]

Push to the Library

Okay – let’s go ahead and push our newly signed Tensorflow container up to the Library, with the Singularity push command, adding a new tag name:

Now that the container is pushed up to the SCS Library, we’ll take a quick look at the repository. We can see both signed and unsigned versions are available. And it is through the web interface that we can add tags or delete tags. If you want to change a tag, add a new one and remove the old. 

*See the Singularity Documentation: Pushing a Container for more information on tags

By default, Singularity Container Services repositories are private, unless made public. In our case, we can make this project public. To show this, we will open another WSL2 (Debian) with Singularity installed using the default settings. By issuing a “pull” command we can see the container is not accessible. If we go back into the web interface and make this a public project, we can then see the container is now available for public “pulls”.

*If you tried pulling a container from the Library that is not public, you’d receive the following error message

Summary

We have taken what we’ve done in the past and continued on by signing our TensorFlow container, verifying that container was unchanged, and pushing that container to the Singularity Container Services Library.

In the next installment, we will view and search for containers through the Singularity Container Services interface as well as perform some advanced Singularity functions such as encryption and inspection of SIF content.

Thank you for joining us!