Enhancing application container security and compliance with Podman

As organizations adopt container-based ecosystems, the approach to continuous IT security and compliance must shift from traditional system security assessments to new methodologies that account for how cloud-based technologies operate. Containers enable agnosticism amongst cloud computing operating environments by packaging applications, or workloads, within a virtualized environment. The application, or workload, is then operating independently of its hosted environment all while inheriting the security benefits of that hosted environment. Container technologies implement the concept of immutability, as in a stateless entity or image that is deployed but not changed.

Containers have disrupted the culture of software development and how IT security assessments are conducted within organizations. Traditional development and operations practices may not directly apply to containerized environments, necessitating a shift for the organization to adapt to a DevOps model that best fits how the organization functions. For the security teams, simply installing endpoint agents or remotely connecting through the Secure Shell Protocol (SSH) protocol is not feasible with newer technologies. Challenges occur when attempting to integrate agent-based solutions. Solutions that utilize Application Programming Interfaces (API) to access resources and management of information systems are preferred over long-standing shared system service account methods.

However, some workloads may not benefit from Kubernetes, the de facto standard platform to orchestrate containerized functions into more complex enterprise applications. In some cases, a General Purpose Operating System (GPOS), or Single Purpose Operating System (SPOS) environment may work better. An example of a GPOS is Red Hat Enterprise Linux (RHEL), whereas an example of SPOS is Red Hat Enterprise Linux CoreOS (RHCOS). Kubernetes can introduce risk when there is no need for distributed architecture with High Availability (HA) or a workforce shortage of specialists. As with all things technology-related, avoid architecting unnecessary complexity.

Without introducing new risks, an effective way to prepare the organization for the realities of container-based environments are to:

• Provide education and training for people involved in the software development lifecycle (SDLC) across development, operations, security, and other roles to enhance their understanding of cloud-based technologies through experience with the changing paradigms of cloud-based technologies

• Implement tailored control baselines specific to the individual information systems, the data types it may contain, and acceptable risk, and;

• Analyze the solutions that protect the containers, their applications, and the critical technologies hosting the containerized applications.

Podman: A compliant solution

Podman, a pod manager tool included with RHEL subscriptions, is an Open Containers Initiative (OCI) compliant solution designed to find, build, run, share, and deploy applications. Podman provides a portable, reusable and automated way to package and run applications. It can operate without the need for Kubernetes, reducing potentially unnecessary architectural complexities, which can be attractive to security and compliance teams that are hesitant to adopt a container-based orchestrator.

The National Institute of Standards and Technology’s Special Publication 800-190 (NIST SP 800-190) Application Container Security Guide provides guidance to, "only group containers with the same purpose, sensitivity, and threat posture on a single host OS kernel". This is a reference to meeting the requirements set forth by the Federal Information Processing Standards Publication (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems. Podman helps to group containers with the same purpose by managing an image registry, the images, kernel, storage, networking and one or several running containers, all within the pod itself. This allows for greater operational ease of managing and separating applications of varying categorization levels in the target operating environments, further managing risk.

Podman is also a means of enhancing application security in a non-privileged, or rootless, configuration of its resources. This is a default configuration in RHEL 8, though it requires a minimal level of effort for RHEL 7. A greater level of application security is possible because Podman does not run a daemon or system service requiring administrative (or sudo) rights to build and run those resources. This improves the protection of not only the applications but also the host environment in the event that a container image contains a weakness from vulnerable software packages.

Correlating indicative controls

Here, we sample some selected typical controls (drawn from NIST SP 800-190) in the context of maintaining necessary operational capabilities. (Obviously, each environment is unique and users must evaluate use of any technology in light of their own risks and threats.)

Network Isolation

• 3.3.3 Poorly separated inter-container network traffic

• 3.3.4 Mixing of workload sensitivity levels

• 3.4.2 Unbounded network access from containers

Podman has the ability to manage Container Network Interfaces (CNI), allowing pods to remain in an isolated environment/virtual network on the host. Entirely isolated virtual networks are created on the host for containers to use. In addition, Podman uses the Netavark and Aardvark-based network stack, providing further control over the network, such as attaching multiple networks to container performance improvements and IPv6 support. A summary of Podman with CNI can be found here.

Operating without daemons

• 4.5.4 Improper user access rights

• 5.2 Exploit of the Container Runtime

Typically, Container Runtime Interfaces have a daemon that runs with escalated privileges on the host. Podman does not require a daemon, meaning it can be utilized by any user without additional privileges.

In addition to the running container, local configurations such as the graphroot, runroot, registry configuration and volumes are isolated. This respects the boundaries of peruser data from the convenience of the home directory.

For reference, the graphroot is the directory to store all writable content created by container storage programs. The runroot is the directory to store all temporary writable content created by container storage programs.

User namespaces

• 3.1.5 Use of untrusted images

• 3.3.1 Unbounded administrative access

• 4.5.5 Host file system tampering

With Podman’s daemonless nature, each user on the host acts as a namespace, enabling further isolation of components including networks, volumes and secrets.

Secrets

• 3.1.4 Embedded clear text secrets

Podman allows for the creation and management of secrets that live on the host, providing further isolation of sensitive information between the container and host.

Secrets are stored locally on the host, rather than within the container. They are then mounted within the container for access. This prevents sensitive information from being stored on a registry embedded with the image, or worse, in clear text on your desk.

Configurable registry policies

• 3.2.1 Insecure connections to registries

• 3.2.2 Stale images in registries

• 3.2.3 Insufficient authentication and authorization restrictions

Signed, mirrored, trusted and untrusted registries can be configured on the host for all. This allows for a controlled policy for pulling images.

Exploring this capability, CRI-O, the runtime for Red Hat OpenShift as well as the Kubernetes project, also uses the configuration file at /etc/containers/registries.conf. Administrators can set credential helpers that store and reference authentication information for registries, as well as configure mirrors’ default registries and TLS enforcement. This can be configured on a per-user basis (versus a global default) for all users utilizing Podman.

Implementing the way forward

We have explored some of the basic security controls principles that Podman provides. In a future article, we will be diving deeper into how Podman better protects the application, the host it operates on and further correlation with typical controls (using NIST SP 800-190 as the example).