Application Container Security: Risks and Countermeasures

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.

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.

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.

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.

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.

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.