Security Recommendations

10 Security Recommendations

Ensure that infrastructure and containerized applications remain secure by following security recommendations and guidelines.

Best Practices for Podman Components

Follow security guidelines at all levels within the infrastructure for an environment to best mitigate against exploitation. Follow the best practice guidelines for each component at play within the environment.

Note that while containerization provides resource separation between applications running on the same host, the separation isn't complete and it's possible to break out of a container or to exploit a container in such a way that it could affect other containers running on the same host. If you have different tenancies within your organization or if you have different customers that are using the same infrastructure, it's imperative that their containers run on different hosts or on different virtual machines to achieve more complete separation and to prevent the likelihood of a serious data breach.

Host

Regularly update the host kernel and operating system software

Security patches and bug fixes for the kernel and operating system software are released as issues are resolved. Keep the operating system current with the most recent software updates. Subscribe the system to the latest software channels or repositories; run regular DNF update operations; and consider using Ksplice to keep the system software up-to-date.
Use a minimal operating system and ensure that it's following security best practices

Where possible, use a minimal operating system installation and ensure that it follows the security best practices described in Oracle Linux 8: Enhancing System Security. Most importantly, reduce the number of services running on the same system. Ideally, move all other services to reside within containers controlled by Podman or move them to other systems entirely. This helps to contain damage in the event of container breakout.
Regularly scrutinize the operating system and kernel for safety

Be vigilant that the operating system is regularly scrutinized for safety and potential vulnerabilities.
Use mature system components that provides the best possible security feature set
We recommend keeping all system components, including the kernel, up-to-date so that all known security and functionality issues have been resolved. If you're using the Unbreakable Enterprise Kernel (UEK), consider using the latest available UEK generation for that Oracle Linux release, so that kernel-based features such as kernel namespaces, private networking, and control groups are mature, reliable, and heavily tested.
Use Linux security modules

Use the appropriate security modules on a host where possible. For example, run SELinux in enforcing mode to protect the host from the container images you're running. In addition, when using a volume mount, consider using the -z option if you need to share an SELinux security context between multiple containers or between the container and the host system. This is useful when running a container as a non-root user because the container is evaluated with the same SElinux context as the host. To restrict the volume to only the running container, use the -Z option. See Setting Up Container Mounts for more information.

Podman Images

Ensure that images come from verified and trusted sources

Verify that Podman images are received and deployed unchanged from a source with a trusted reputation and which has been authenticated. For example, see Configuring Podman for Signed Images.

When pulling images from remote sources, ensure that the connection is protected and that you're using HTTPS for the pull request. Don't use insecure image registries that aren't protected by TLS.

Where possible, Podman images should come from and be based on a curated, trusted collection of image suppliers.
Create reliably reproducible images

When using Containerfiles to build new images, review base images, and installed software for security. To help ensure that new images use base images and software that you have reviewed for security vulnerabilities:
- Specify a fixed version in the base image in an image Containerfiles.
- Specify fixed versions in package pulls in the build steps of an image Containerfile (note that dependencies of dependencies can still be a reliability problem).
- Ensure the that package pulls in the build steps are using trusted and verified sources.
Minimize packages installed on images

Don't install unnecessary packages into new image builds. Review Containerfiles to remove unnecessary installation steps so that images remain limited to their function.

Podman Containers

Run containers as a non-root user

Podman runs each container as the host user running the Podman container. The host user can be the root user or a non-root user. For most security, run containers with a non-root host user.
Consider running containers with limited memory and CPU usage

Consider limiting container memory and CPU usage using the -m and --memory-swap options for memory and swap memory; and the -c option for CPU.
Limit container restarts

To prevent potential denial-of-service resulting from a container that spins out of control, limit container restarts using the --restart=on-failure:N option when creating or running a container.
Monitor container resource usage

Podman provides facilities to monitor container resource usage, such as memory consumption, CPU time, I/O and network usage. Review container resource usage for performance, error detection, and anomalous behavior. Consider using tools to monitor real-time resource usage for anomalous activity such as use of resources, suspicious traffic, and unexpected user activity.
Limit container file access
When creating and running containers, limit container file access using the --read-only flag or the -v <host dir>:<container dir>:ro option. Explicitly create volumes for container applications to write in and monitor changes to files in these volumes. Ensure that volumes that are dedicated for container write access are reviewed for sprawl and are cleaned up regularly. The following example shows how to use the :ro option to mount a host directory such that the host folder or file is read-only for the container:
```
podman run -v /host_directory_to_be_mounted:/target_container_directory:ro oraclelinux:8
```
In the previous example, host_directory_to_be_mounted is the host directory and files to be mounted as a volume and target_container_directory is the directory on the container where the host directory is to be mounted.

Don't mount sensitive host system directories at container runtime:
- /
- /boot
- /dev
- /etc
- /lib
- /proc
- /sys
- /usr
Regularly review containers for safety

Consider using tools that help automate container safety checks and to monitor for changes within containers.

Systematically remove images and containers that aren't needed from the host system to avoid image and container sprawl and to help prevent the accidental usage of an old, unused image, or container that has potentially avoided security scrutiny. Consider using the Podman auto-update feature to automate the process of checking for new image versions and redeploying impacted containers automatically.
Understand kernel capabilities in containers

Oracle Linux divides the root user into distinct units, called capabilities. By default, the following kernel capabilities are granted to a container:
- CHOWN
- DAC_OVERRIDE
- FSETID
- FOWNER
- NET_RAW
- SETGID
- SETUID
- SETFCAP
- SETPCAP
- NET_BIND_SERVICE
- SYS_CHROOT
- KILL
By default, the following notable kernel capabilities are removed from a container:
- SYS_TIME
- MKNOD
- NET_ADMIN
- SYS_MODULE
- SYS_NICE
- SYS_ADMIN
- AUDIT_WRITE
Don't use the --privileged option when starting containers because it disables the security features that isolate the container from the host such as dropped Capabilities, limited devices, read-only mount points, and volumes and so on.
Understand options to Limit kernel file handle and process resources in containers

When creating and running containers, limit kernel resources by using the --ulimit option or set container defaults using the --default-ulimit when starting the Podman service.
Understand options to limit networking access from containers

If you do run a network for a container, when publishing ports to the host, specify the IP address of the interface that you want the port to bind to so that the attack surface is reduced to the network interface where the container is listening. Podman publishes to all interfaces (0.0.0.0) by default if an IP address isn't specified when using the -p or --publish option.

Don't run SSH inside containers.

Don't map privileged ports (< 1024) inside containers.

Don't use the --net=host mode option for containers when they're started or run. This option gives the container full access to local system services and is insecure.
Understand options to limit system calls in containers
By default, Podman containers limit the system calls available to containers using the system calls specified in the /usr/share/containers/seccomp.json file. This list is compatible with most containers and you don't need to add more system calls.
Don't share host namespaces with containers

Don't share host namespaces such as the PID or IPC namespaces when starting or running containers.
Don't expose host devices into containers

Don't expose host devices into containers when you start or run them.

Containerized Applications

Minimize kernel calls in containerized applications

Because the kernel is shared between containers, kernel calls increase risk to other containers running on the host system. Avoid kernel calls within containerized applications wherever possible.
Run Container applications as a non-root user

Ensure that containerized applications run as a non-root user. Because the UIDs are shared across the host, the root user in a container is the root user on the host.
Remove or minimize the use of setuid and setgid in containerized applications

Most applications don’t need any setuid or setgid binaries. If you can, disable, or remove such binaries. By doing so, you remove the chance of them being used for privilege escalation attacks. If you discover binaries that have setuid or setgid permission flags, remove them altogether, or try to remove the permission flags to remove the risks that are associated with these permissions on a binary.
Design containerized applications to be impermanent

As much as is possible, design applications to be stateless, rollable, instantly migrateable microservices container apps if possible. If using applications outside of your own design, take this approach into consideration when selecting software that you intend to run within containers. This quality can be helpful in maintaining service during and in the time following a breach or accident in the system.