Admin Guide Software Container

Comparison of Container Technologies

	Singularity	Charliecloud	Docker	runc	Podman
Default configuration	suid root	unprivileged	Daemon (running with root rights)	configuration needed	unprivileged
not clear if unprivileged is possible	yes, but limited functionality	only unprivileged	yes	yes, but with limitations	yes
Image files?	only with root	no	internal storage (various backends)	no	no
flat containers	yes	yes	no	yes	yes
User Namespaces	optional	yes	optional	yes	yes
Isolation	mount, PID, opt. networking	mount	freely configurable	freely configurable	freely configurable
Creation of Containers	yes	yes (various builders)	yes	no	yes
SL6-compatibility	yes	neo	yes	no	unclear
“Composing”	no	no	docker-compose	no	yes
Goals	Docker usage for HPC	user software stack for HPC, high-quiality Code	industry-standard, encapsulation of services	standardized container runtime OCI	drop-in replacement for Docker, frontend for OCI Runtimes and Builder

Singularity

General - About singularity

• singularity is an hpc-friendly alternative to docker (and other container systems) because it
  • does not run a root daemon
  • does not fully containerize the software running
• can be installed without root access (though not generally recommended due to limited functionality)
• (The devs claim) the source has been reviewed by several renowned insitutions (MIT, etc) in search of security problems, and never found anything.

Admin side

• Singularity needs to be installed on a drive that is mounted with SUID enabled. In the future there will be options available to use capability sets but for now this seems fairly limited.
  • It can be used without SUID, instead using namespaces, but this limits the container types to be used to sandbox containers (no images (.sif etc.) usable)
• Best install using the package manager (singularity can be found on rhe, centOS and ubuntu using a ppa) in order to update alongside the system packages.
• Singularity supports the option to limit usage to user groups (like docker) which can be handy for security.

User side

• Use trusted images preferably
• Build images before running them using the queuing systems.

Documentation

Can be found on this site.

A set of examples (for the user side) can be found here

Sregistry

Sregistry is a service that is easily deployable using docker, which acts as a hub for storing and sharing singularity images on the local (cluster) network. If you find yourself sharing lots of containers or sharing lots of build pipelines with your colleagues, it might be easier to deploy an sregistry server.

Docker

Administrator

• Container access for user only as non-root user if possible
• Update your system regularly
• Don’t trust Docker image providers to apply security updates to their images in a timely manner. Check manually for available system updates inside your Docker containers every 1-2 weeks
• Don’t allow unofficial base-images, i.e. only use images that stem from the software/distribution itself; the packages can be obtained from https://hub.docker.com/ and are labelled “official image”. Unfortunately, the admin has to implement any verification checks themselves - use the official Docker API to verify the images, see https://docs.docker.com/registry/spec/api/
• It’s now possible to use signed images: Content Trust in Docker https://docs.docker.com/engine/security/trust/content_trust/ and Automation with Content Trust https://docs.docker.com/engine/security/trust/trust_automation/
• Limit resource usage if possible - should either be set through the “run” parameter https://docs.docker.com/config/containers/resource_constraints/ or set in the compose files of the specific containers https://docs.docker.com/compose/compose-file/#resources. Setting it for all images through the daemon shouldn’t be the norm.

User

• Don’t use unofficial base-images/Don’t run untrusted container images
• use /latest instead of fixed versions
• use content trusted/signed images when possible