1 of 16

Software - Apptainer

Linux Cluster Institute - Intermediate

Alan Chapman�Systems Analyst - Software Specialist�RTO Research Computing�Arizona State University

2 of 16

Agenda

What are containers

Security concerns

Docker vs Apptainer vs …

When to use a container

Methods of Building / Obtaining Containers

2

3 of 16

3

What are Containers?

Containers are lightweight, stand-alone packages that contain everything needed to run a piece of software, including the code, runtime, libraries, and environment variables. Unlike virtual machines, containers do not bundle an entire operating system—just the necessary components, making them more efficient, portable, and scalable.

The efficiency of containers comes from their lightweight nature, allowing for rapid deployment and scaling. Their portability ensures that software runs consistently across different computing environments, from a developer's laptop to an HPC cluster. Scalability is achieved by easily adding more container instances to handle increased load.

4 of 16

4

HPC Security Concerns

Using containers introduces several security concerns, primarily around isolation and privilege escalation. Containers share the host's kernel, so a vulnerability in the container can potentially affect the entire system. Key concerns include:

Isolation: Containers may not be fully isolated from each other or the host, making it possible for a compromised container to access other containers or the host system.
Privilege Escalation: If a container runs with root privileges, a vulnerability could allow an attacker to gain root access to the host.

5 of 16

5

Apptainer Security Management

User Namespace: Runs containers with user privileges, reducing privilege escalation risks.
No Root Access: Allows container operations without root, minimizing security vulnerabilities.
Immutability: Ensures containers are read-only, preserving integrity and preventing unauthorized changes.
HPC Integration: Seamlessly works with existing HPC security infrastructure.
Single-File Containers: Simplifies management and reduces tampering risks.
Host Integration: Uses the host's kernel, reducing kernel-level vulnerabilities.
Customizable Security: Allows for detailed security policy definitions.

User Namespace: Apptainer operates within the user's namespace, meaning containers run with the user's privileges rather than requiring root access. This reduces the risk of privilege escalation attacks, as the container cannot gain more privileges than the user running it.
No Root Access Required: Apptainer allows users to build and run containers without needing root privileges. This contrasts with other container platforms that might require root access, thus minimizing the attack surface and potential security risks associated with root-level permissions.
Immutability: By default, Apptainer containers are read-only. This immutability ensures that once a container is built, its contents cannot be altered, preventing unauthorized changes and maintaining the integrity of the application and its dependencies.
Compatibility with HPC Infrastructure: Apptainer integrates seamlessly with existing HPC resource managers and schedulers (e.g., SLURM, PBS), ensuring that containers can be managed and monitored using established HPC security policies and practices.
Single-File Containers: Apptainer uses single-file container images, which simplifies distribution and reduces the risk of tampering. These single-file containers can be signed and verified to ensure their authenticity and integrity.
Host Integration: Apptainer containers run with the same kernel as the host system, minimizing the risk of kernel-level vulnerabilities that could arise from using different or outdated kernels in a container.
Customizable Security: Apptainer provides fine-grained control over container permissions, allowing administrators to define security policies that restrict or allow specific actions within containers, further enhancing security.

6 of 16

6

Apptainer Security - Schedulers

Centralized Control
Access Management
Isolation and Resource Limits
Monitoring and Auditing
Scalability and Efficiency

1 Resource managers like SLURM and PBS provide centralized control over job scheduling and resource allocation, ensuring that containers are run within the established security policies and constraints of the HPC environment.

2 Integration with resource managers allows for better control over who can submit jobs and access resources, enforcing strict user authentication and authorization processes.

3 Resource managers can enforce isolation between jobs and set resource limits, preventing any single container from monopolizing system resources or interfering with other users' jobs.

4 Resource managers provide monitoring and logging capabilities, which help in tracking container usage and detecting any unusual or unauthorized activities. This facilitates better oversight and incident response.

5 Efficient job scheduling and resource allocation by resource managers ensure that containers are used optimally, reducing the risk of resource contention and improving overall system security and performance.

7 of 16

7

Comparison of some container engines

Feature	Docker	Apptainer (Singularity)	Charliecloud
Target Audience	General application development	HPC and scientific workloads	HPC users
User Privileges	Requires root privileges	No root privileges required	No root privileges required
Isolation	Strong OS-level isolation	Focus on user security	Simple isolation
Ease of Use	Very user-friendly	Moderate learning curve	Simple but may require setup
Portability	High portability	High portability	High portability
Repositories	Docker Hub	User-built containers	User-built containers
Integration	Broad ecosystem integration	HPC workload managers	HPC workload managers
Performance	Moderate overhead	Low overhead	Minimal overhead

1 Resource managers like SLURM and PBS provide centralized control over job scheduling and resource allocation, ensuring that containers are run within the established security policies and constraints of the HPC environment.

2 Integration with resource managers allows for better control over who can submit jobs and access resources, enforcing strict user authentication and authorization processes.

3 Resource managers can enforce isolation between jobs and set resource limits, preventing any single container from monopolizing system resources or interfering with other users' jobs.

4 Resource managers provide monitoring and logging capabilities, which help in tracking container usage and detecting any unusual or unauthorized activities. This facilitates better oversight and incident response.

5 Efficient job scheduling and resource allocation by resource managers ensure that containers are used optimally, reducing the risk of resource contention and improving overall system security and performance.

8 of 16

8

Methods of building containers - Downloading

Downloading a container image from a container repository

$ apptainer pull docker://godlovedc/lolcow

INFO: Converting OCI blobs to SIF format

INFO: Starting build…

Getting image source signatures

Copying blob 3b61febd4aef done |

Copying blob 7fac07fb303e done |

Copying blob 9fb6c798fa41 done |

Copying blob 8e860504ff1e done |

Copying blob d010c8cf75d7 done |

Copying blob 9d99b9777eb0 done |

Copying config 38dc06177c done |

Writing manifest to image destination

INFO: Creating SIF file...

$ ls *.sif

lol_cowsay.sif

$

9 of 16

9

Methods of building containers - Building

$ vim rocky

bootstrap: yum

include: dnf

mirrorurl: http://dl.rockylinux.org/pub/rocky/{{ version }}/BaseOS/x86_64/os/

%environment

LC_ALL=C

%arguments

version=”8”

%post

dnf -y update

dnf install -y epel-release

dnf install -y wget git vim

$ apptainer build —build-args version=”8” rocky8.sif rocky

10 of 16

10

Methods of building containers - Building

$ vim rocky-docker

Bootstrap: docker

From: rockylinux:{{ version }}

%environment

LC_ALL=C

%arguments

version=”9.3”

%post

dnf -y update

dnf install -y epel-release

$ apptainer build --build-arg version="8.6" rocky8.6.sif rocky-docker

11 of 16

11

# First Stage

installed

Bootstrap: docker

From: golang:1.12.3-alpine3.9

Stage: one

%post

# prep environment

export PATH="/go/bin:/usr/local/go/bin:$PATH"

export HOME="/root"

cd /root

# insert source code, could also be copied from host with %files

cat << EOF > hello.go

package main

import "fmt"

func main() {

fmt.Printf("Hello World!\n")

}

EOF

# build go application

go build -o hello hello.go

# Second Stage

installed

Bootstrap: oras

From: ghcr.io/apptainer/alpine:3.15.0

Stage: two

%files from one

/root/hello /bin/hello

%runscript

hello

Multistage build

$ vim multistage

$ apptainer build gohello.sif multistage

12 of 16

12

$ vim spack.yaml

spack:

specs:

- gcc@12.3.0

- zlib-ng%gcc@12.3.0

- 7zip

- tcl

- lua

container:

format: singularity

images:

os: rockylinux:8

spack: 0.22.0

strip: true

os_packages:

final:

- libgfortran

- wget

labels:

apps: "gcc"

Multistage build with Spack

Build a spack environment and add the packages you want to build
Use spack containerize to build the definition file

13 of 16

13

Resources

Apptainer - https://apptainer.org/
User Documentation - https://apptainer.org/docs/user/latest/
Admin Documentation - https://apptainer.org/docs/admin/latest/
Blog - https://ciq.com/blog/ - filter by Apptainer / Singularity
NIH Wrapper examples - https://github.com/NIH-HPC/singularity-def-files
Spack Containers - https://spack.readthedocs.io/en/latest/containers.html
New Approach to MPI in Apptainer - https://ciq.com/blog/a-new-approach-to-mpi-in-apptainer/
OpenFOAM Containerized - https://ciq.com/blog/integrating-site-specific-mpi-with-an-openfoam-official-apptainer-image-on-slurm-managed-hpc-environments/

14 of 16

14

My Linkedin

Feedback

https://github.com/acchapm1/lci-feedback

https://www.linkedin.com/in/alanchapmanaz /

15 of 16

15

Questions / Discussion

1 of 16

2 of 16

3 of 16

4 of 16

5 of 16

6 of 16

7 of 16

8 of 16

9 of 16

10 of 16

11 of 16

12 of 16

13 of 16

14 of 16

15 of 16

16 of 16