Application Container Security: Risks and Countermeasures

Application Container Security: Risks and Countermeasures

Blog Article Published: 05/05/2021

Written by Suria Venkataraman

Virtualizations enable isolated, virtualized views of the operating systems (OS) to each application. Today’s OS virtualization technologies are primarily focused on providing a portable, reusable, and automatable way to package and run applications as containers-based deployments, and they provide key automation enablement in cloud scaling.

This article was created with the intention of enabling iterative security improvement for cloud containers. I list broad risk groups associated with container technologies, as recommended in the NIST container security framework (800-190), and then list potential countermeasures to address those risks when planning for, implementing, and maintaining containers. The risks are split into the following groups, under which multiple risk elements and countermeasures are listed:

Figure 1: Application Container Risk Groups

Risk Group: Image Risks

Risk Elements:

Image vulnerabilities

Image configuration defects

Embedded malware

Embedded clear text secrets

Use of untrusted images


Default OS shells, which are packaged with OS builds, are prone as compromised entry points. Consider using images like Distroless, which can be without shell, to make your security posture slightly better.

Age of images should be in check and the age threshold should trigger a new certified image build.

Teams should not add custom OS libraries from market, rather they should use standard, certified OS (Linux) images. Such controls should apply for foundational programming platforms like JDKs/JREs.

Organization processes should support visibility into all layers of image, at all times.

Image configurations should be well tested and applied by only well-informed system administrators to avoid misconfigurations.

Use quality gates to ensure build and deployment of DevOps lifecycle.

Nearly all major cloud vendors provide their own registries, so teams should carefully validate these products to make sure the above countermeasures can be applied to them.

Risk Group: Registry Risks

Risk Elements:

Insecure connections to registries

Stale images in registries

Insufficient authentication and authorization restrictions


Use an industry standard registry (like AWS ECR) controlled by appropriate privileges for few users to avoid accidental deployment of a known-vulnerable version.

Secure network controls specifically to avoid man-in-the-middle attacks towards registries, whose compromise will have large-scale compromise on downstream containers and hosts.

Make sure stale images would be controlled by internal SysOps teams.

SysOps/DevOps should configure CI/CD processes to allow only signed images and to push to a registry only after they have passed a vulnerability scan and compliance assessment.

Existing automated scans should be integrated into registry transactions and scheduled scanning processes.

Risk Group: Orchestrator Risks

Risk Elements:

Unbounded administrative access

Unauthorized access

Poorly separated inter-container network traffic

Mixing of workload sensitivity levels

Orchestrator node trust


SysOps should provide RBAC (Role-Based-Access-Control) for development, test, and production deployment teams. Orchestrator designs tend to assume all users interacting are administrators, which may not be the case in production-grade large enterprise systems.

Where applicable, organizations should apply Multi-Factor Authentication (MFA).

Hosting VPCs/Subnet should ensure appropriate network access separation is enforced. For example, external facing container apps need not have access to internal facing container apps. This will avoid poorly separated inter-container network traffic.

In most containerized environments, overlay networks may be used for node-level traffic, which is sometimes designed to be opaque for existing network security and management tools. Depending on network design, these overlay designs may cause a network “blindness” scenario, where suspicious traffic between an app’s serve node and database server node may go undetected.

Group the containers according to application/data sensitivity level. For example, a heavy-traffic public-facing “read-only” web server need not be on the same host as a highly secured financial database server.

Orchestrator is the most foundational node; weaker configurations can expose all other container technology components to greater risk.

Risk Group: Container Risks

Risk Elements:

Vulnerabilities within the runtime software

Unbounded network access from containers

Insecure container runtime configurations

App vulnerabilities

Rogue containers


Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) in the runtimes deployed, to upgrade any instances at risk, and to ensure that container orchestrators only allow deployments to properly maintained runtimes.

Containers deployed across multiple hosts typically communicate over a virtual, encrypted network and traditional network devices are often blind to this traffic. Also, containers are typically assigned dynamic IP addresses automatically when deployed by orchestrators.

Both the OS stack and the application technology stack should be monitored for vulnerabilities.

App-aware tools should provide the following capabilities:

    1. Automated determination of proper container networking surfaces, including both inbound ports and process-port bindings.
    2. Detection of traffic flows both between containers and other network entities, over both ‘on the wire’ traffic and encapsulated traffic.
    3. Detection of network anomalies, such as unexpected traffic flows within the organization’s network, port scanning, or outbound access to potentially dangerous destinations.

Mandatory access control (MAC) technologies like SELinux and AppArmor provide enhanced control and isolation for containers running Linux OSs.

Common container runtimes like Docker include default seccomp profiles that drop system calls that are unsafe and typically unnecessary for container operation.

Container vulnerability prevention tools/profiles should prevent and detect anomalies at runtime, including:

    1. Invalid or unexpected process execution
    2. Invalid or unexpected system calls
    3. Changes to protected configuration files and binaries
    4. Writes to unexpected locations and file types
    5. Creation of unexpected network listeners
    6. Traffic sent to unexpected network destinations
    7. Malware storage or execution

To identify and prevent rogue containers being instantiated, all container creation should be associated with individual user identities and logged to provide a clear audit trail of activity.

Risk Group: Host OS Component Risks

Risk Elements:

Large attack surface

Shared kernel

Improper user access rights

Host file system tampering


Organizations should reduce risk by not having a dedicated OS shell, which is the primary OS attack surface. It should be built with a minimalistic OS component approach to reduce the attack surface.

Organizations should not mix containerized and non-containerized workloads. Containerized workloads have specific, elevated countermeasures to support secure fleet management. For example, if a host has a containerized web server, it should not run a separate web server directly on the same host.

Orchestrator’s OS logins/actions (for job distributions to hosts) should still be audited, to detect anomalies or abnormal escalation of privileges.

In no case should containers be able to mount sensitive directories on a host’s file system, especially those containing configuration settings for the operating system. Organizations should use tools that monitor and prevent such OS level activities directly by non-OS component stacks.

Risk Group: Hardware Risks


Trusted platform module (TPM) can check the integrity of the machine during the boot process, enabling the hardware’s protection and detection mechanism at pre-boot, and in the secure (measured) boot process. Also note that not all cloud providers enable verification of hardware trust by users of cloud services. Organizations can amend hardware trust requirements as part of their service agreements with cloud providers.

As with any new technology injection, there can be phased governance on control measures to make it less daunting. Following this list of container phases may help in implementing such control measures:

  1. Initiation Phase
  2. Planning and Design Phase
  3. Implementation Phase
  4. Operations and Maintenance Phase
  5. Disposition Phase

To conclude, the above countermeasures shift-left application ecosystem security towards DevOps/DevSecOps/SysOps teams instead of reactive post-deployment solution approaches. The immutability and declarative nature of containers enable organizations to be more automated, push application-centric security that requires minimal manual involvement, thus reducing overall risk.

About the Author:

Suria Venkataraman is an Enterprise Architect in the National Student Clearinghouse (Herndon, VA) and passionate about cloud security challenges and solutions. He is an active member of Cloud Security Alliance volunteer groups. The National Student Clearinghouse is the nation's trusted source for degree verification and enrollment verification and student educational outcomes research.

Share this content on your favorite social network today!

Related Articles: