Maintaining Open Source Singularity Since 2017
A Beginner’s Guide to Using Software Bill of Materials with Singularity Container Services
By Adam Hughes
Singularity Container Services (SCS) is a free offering from Sylabs that assists you with:
- Keystore: This function allows you to store keys for signing images, proving your ownership over any image you sign.
- Container Library: This is a full OCI compliant registry, enabling you to share your images with your partners and collaborators.
- Remote Builder: This function lets you build an image in a safe, isolated environment using SingularityCE or SingularityPRO. It also allows you to get a Software Bill of Materials (SBOM) that’s embedded in the resulting SIF file.
In this guide, we’ll demonstrate how you can use an SBOM and how it’s included in your SIF file. This tutorial assumes that you have already installed the latest version of SingularityCE or SingularityPRO.
Step 1: Set Up an SCS Account
Go to Sylabs Cloud and click on the “Sign Up” button. Choose one of the four approved login providers, and voila! Your account is ready.
Step 2: Create an Access Token
After logging in to SCS, navigate to your profile menu on the right side and select “Access Tokens”. This will direct you to the keystore where you can generate your access token. This token enables interaction between SingularityCE or SingularityPRO and Singularity Container Services.
Step 3: Name Your Token
Type any name you wish for your token, and then click on the “Create Access Token” button. This will generate a token, which is a string of random characters and numbers. Remember to save this token somewhere safe, as it won’t be visible again. It will be valid for 30 days and will then be removed.
Step 4: Login to Singularity
Use the following command to login to SingularityCE or SingularityPRO:
singularity remote loginYou’ll be prompted to paste the access token you generated earlier. After verification, the token will be stored in a file named
remote.yaml in your home directory.Generate an access token at https://cloud.sylabs.io/auth/tokens, and paste it here.
Token entered will be hidden for security.
Access Token:
INFO: Access Token Verified!
INFO: Token stored in /home/USERNAME/.singularity/remote.yamlStep 5: Define Your Container
We’ll use the example of containerizing RStudio. To do this, you need to create a definition file,
We’ll use the example of containerizing RStudio. To do this, you need to create a definition file,
RStudio.def, with the following content:Bootstrap: library
From: ubuntu:22.04
%environment
LANG=en_US.UTF-8
LC_ALL="en_US.UTF-8"
export LANG
export LC_ALL
%post
export DEBIAN_FRONTEND=noninteractive
export TZ=Etc/UTC
apt update -qq
apt install -y --no-install-recommends software-properties-common dirmngr wget locales
wget -qO- \
https://cloud.r-project.org/bin/linux/ubuntu/marutter_pubkey.asc | \
tee -a /etc/apt/trusted.gpg.d/cran_ubuntu_key.asc
add-apt-repository -y "deb https://cloud.r-project.org/bin/linux/ubuntu $(lsb_release -cs)-cran40/"
apt install -y --no-install-recommends r-base r-base-dev
wget -O /rstudio-2023.03.0-386-amd64.deb \
https://download1.rstudio.org/electron/jammy/amd64/rstudio-2023.03.0-386-amd64.deb
apt -y install /rstudio-2023.03.0-386-amd64.deb
wget -O /rstudio-server-2023.03.0-386-amd64.deb \
https://download2.rstudio.org/server/jammy/amd64/rstudio-server-2023.03.0-386-amd64.deb
apt install -y gdebi-core
gdebi -n /rstudio-server-2023.03.0-386-amd64.deb
# Log to stderr
echo "[*]\nlog-level=error\nlogger-type=stderr\n" > /etc/rstudio/logging.conf
# Setup the "general" CRAN repo
echo 'local({
r <- getOption("repos")
r["CRAN"] = "https://cran.us.r-project.org"
options(repos = r)
})' >> /etc/R/Rprofile.site
# Prepare system to use UTF-8
sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && locale-gen && update-locale
# Remove unneeded source packages
rm -f /rstudio*.deb
%runscript
/usr/bin/rstudio "$@"
%startscript
/usr/lib/rstudio-server/bin/rserver --server-user=$(whoami)"$@"
Step 6: Submit a Remote Build
With the definition file ready, you can submit a remote build as follows:
$ singularity build --remote RStudio.sif RStudio.defSingularityCE and SingularityPRO will submit the definition file. If you want to modify this example and include your own files, ensure they are listed in the
%files section of your definition file.
Building the image may take some time, so feel free to take a short break.
Once the image building process has finished, you can check if the SBOM was included:
$ singularity sif list RStudio.sifThe output is similar to this:
------------------------------------------------------------------------------
ID |GROUP |LINK |SIF POSITION (start-end) |TYPE
------------------------------------------------------------------------------
1 |1 |NONE |32176-33818 |Def.FILE
2 |1 |NONE |33818-36473 |JSON.Generic
3 |1 |NONE |36473-36565 |JSON.Generic
4 |1 |NONE |36864-633966592 |FS (Squashfs/*System/amd64)
5 |1 |NONE |633966592-635124892 |SBOM (cyclonedx-json)
Step 7: Scan for Vulnerabilities
You can scan the built image for vulnerabilities using grype:
You can scan the built image for vulnerabilities using grype:
grype RStudio.sif The output will list any vulnerabilities found and their severity level (full list and detail of vulnerable packages are trimmed out for readability.)
✔ Vulnerability DB [updated]
✔ Parsed image sha256:2fbc391f50c2eaf639d056e13c06c0c460c854c843e3af038c77bb7102fc3358
✔ Cataloged packages [428 packages]
✔ Scanned for vulnerabilities [249 vulnerabilities]
├── 0 critical, 7 high, 103 medium, 109 low, 30 negligible
└── 33 fixedUnderstanding Vulnerability Severity
- Critical: The highest level. Exploitation may compromise your software systems or infrastructure devices at the administration level.
- High: These vulnerabilities could result in data loss, downtime, or elevated access to a system, although they’re typically difficult to exploit.
- Medium: These vulnerabilities may require an attacker to persuade individuals (social engineering) or have local network access or limited user privileges.
- Low: These vulnerabilities have minimal impact on the organization and often require local or physical access to the system.
The inclusion of an SBOM within the Remote Builder capabilities of Singularity Container Services and Singularity Enterprise can help researchers and developers build more secure HPC workflows. Enjoy safer computing!
Join Our Mailing List
Recent Posts
Related Posts
Ensuring Singularity Enterprise Continuity: Crafting a Disaster Recovery Plan
In the dynamic world of IT operations, disaster recovery procedures stand as the secret weapon, quietly ensuring the resilience and continuity of businesses. Whether it's a natural disaster, a cyberattack, or a hardware failure, having a robust disaster recovery plan...
Remote Building with OCI Registries
This blog post will demonstrate how to use a definition file in a remote build that references an Open Container Initiative (OCI) image stored in Singularity Enterprise and Singularity Container Services.First, create an account in Singularity Container Service. To do...
SingularityCE and PRO 4.1: Embracing Compatibility with Dockerfiles
Introduction In the ever-evolving landscape of containerization, where innovation thrives and technological boundaries are pushed, adaptability is key. The ability to seamlessly integrate diverse technologies not only fosters a collaborative ecosystem but also...