Alpaquita Linux: Keeping containers secure

One of the most important security measures on Linux hosts is to conduct proper audit of sensitive activities on the system. The instrument that can help with tracking such activities is the audit support in Linux kernel and corresponding userspace tools/packages. The audit allows system administrators to monitor security sensitive events and report them in a log, such as audit.log. This log file can be created on a local or remote system for better security protection.

Due to Podman implementation to use fork/exec to run containers, the audit feature works more correctly and stores necessary data in the log files. In Docker, the auditd auid is unset in the log, which means a system administrator can see that a process associated with a container has accessed security sensitive information, but the identity is not recorded in the log. In Podman, auid is properly recorded in the audit log file.

For instance, a cat coreutils executable was used to access sensitive information and Podman provides all necessary information about an identity while in Docker auid is in an unset state.

It is recommended to use only Podman to set up container host environments and to use audit for tracking access to sensitive information.

Setting up an audit in Alpaquita requires installing the audit package and starting the audit service as follows.

To properly set up resource management, the system must be configured to use Control Group v2 (cgroup v2). Consider performing the following actions to use cgroup v2.

We recommend using AppArmor in the container host setup based on Alpaquita Linux. Proper AppArmor configuration helps prevent malicious container escapes and protects host sensitive resources.

Use the -m option to limit memory and the -c option to limit CPU.

When creating and launching containers, limit file access using the -v <host dir>:<container dir>:ro option or --readonly flag. It is safer to explicitly create volumes for applications running inside a container. Monitoring file changes in these volumes can help prevent security breaches. Volumes that are dedicated for container write access must be cleaned up regularly. Here is an example of how to use the :ro option and mount a host directory in a way that the host directory/file is read only for a container:

host_directory is the host directory/files to be mounted as a volume and become available in container_directory in the container. We strongly discourage you from mounting the following sensitive host system directories at container runtime. /, /boot, /dev, /etc, /lib, /usr, /sys, /proc, and so on.

Malicious or accidental denial-of-service might happen to a container that produces many errors, so limiting container restarts is a good practice and can be done using the --restart=on-failure:N option when creating or launching a container.

It is an excellent practice to limit network access from a container unless it is needed for running certain applications. When publishing ports to the host, specify the IP address of the interface that a port will be bound to so that the attack surface is reduced to the network interface where the container should be listening to. Podman publishes to all interfaces (0.0.0.0) by default if an IP address is not specified when using the --publish option.

Review the following recommendations:

The following kernel capabilities are usually granted to a container by default. Review the capabilities and disable unnecessary ones.

The --privileged option disables the security measures used for isolating a container from the host, so it should not be used unless absolutely required. This option removes barriers from isolated capabilities, limited devices, read-only mount points and volumes, and so forth.

Podman includes the necessary features to monitor container resource usage, such as memory consumption, CPU time, I/O, and network usage. Monitoring container resource usage for performance, error detection, and abnormal behavior like suspicious traffic or unexpected user activity, helps to detect security flaws as well.

Images and containers that are not needed should be removed from the host system to avoid image and container garbage and to protect from the accidental execution of an old, unused image, or container that might have possible security flaws. Podman has the auto-update option to automate the process of updating for new image/container versions according to their auto-update policy.

By default, Podman containers limit the system calls available to containers based on the calls defined in the /usr/share/containers/seccomp.json file. This list is valid for general purpose containers and is compatible with most containers, so there is no need to add more system calls.

However, you can narrow down system calls needed for a particular container to run. Create the seccomp generated profile using the following command:

You can reuse it later with the --security-opt seccomp=<file_path> option.

Podman has a useful feature to create shortcuts for podman run with all necessary metadata, so the actual container execution can be done as follows:

Before actual execution, we recommend checking such shortcuts by executing the runlabel --display option to avoid any malicious podman run command. The option does not execute the label command, but only displays what will be executed.

Podman has a remote API implementation called varlink that works over a socket. The socket configuration is similar to a Unix socket, restricting it to local use only. Security consideration is to run this socket as a non-root user especially if a container has no requirement to run as a privileged user. A socket can be created by running the following Podman command:

By creating a socket with Podman command, you ensure that proper permissions are set on the socket.