Container Security: An Overview of Risks and Security Best Practices

By Veritis :: Published on

Container Security: An Overview of Risks and Security Best Practices

‘Security’ is one most common risk in the modern IT despite the industry’s continuous evolution in the form of advanced technology solutions.

Every new technology implementation is falling prey to some or the other security risks, placing security at the top of organizational priorities.

Containerization’ is one such solution on demand for faster execution, portable and reusable applications, however facing security challenge on the opposite side.

Container Security is emerging as a serious challenge and building security around containers is questioning the existing security policies and compliance frameworks across many organizations.

Container applications are at high risk of security owing to their flexible nature, besides carrying along discrete components that interact over the network.

Because of these qualities, they offer a wide scope for security vulnerabilities such as bugs, misconfiguration, authentication and authorization issues across multiple layers of the software architecture.

Container Technology Architecture Tiers and Components

Fig: Container Technology Architecture

Understanding Container Security Risks

Container security risks are majorly categorized as:

  1. Compromise of a container image or container as a whole
  2. Misuse a container to attack other containers, the host Operating System (OS) or other hosts, among others
 Virtual Machine and Container Deployments

Fig: VM and Container Deployments

Besides, there are also risks associated with core components of the container ecosystem such as images, registries, orchestrators, containers and host OS’, as described by the National Institute of Standards and Technology (NIST):

Risk Type Description
Image Risks This includes image vulnerabilities, configuration defects, embedded malware, embedded clear text secrets and use of untrusted images
Registry Risks Insecure connections to registries, Stale images in registries, Insufficient authentication and authorization restrictions
Orchestrator Risks Unbounded administrative access, unauthorized access, poorly separated inter-container network traffic, mixing of workload sensitivity levels and orchestrator node trust
Container Risks Vulnerabilities within the runtime software, unbounded network access from containers, insecure container runtime configurations, App vulnerabilities and Rogue containers
Host OS Risk Large attack surface, shared kernel, Host OS component vulnerabilities, improper user access rights and host OS file system tampering

Now that we have seen the different types of container security risks, we shall look into the best practices that can handle the aforementioned risks.

Container Security Best Practices

Container Technology Architecture Tiers, Components, and Lifecycle Phases

Fig: Container Technology Architecture Tiers, Components, and Lifecycle Phases

Here are 6 container security best practices that NIST recommends:

1) Countermeasures to Container Images

Application images are among key vulnerable areas for security risks in a container environment. These images can be outdated ones, insecure versions of the software, applications carrying bugs, those containing hidden malware and those loosely configured. Moreover, these images often carry along authentication keys or certificates.

To address container image-related issues, NIST recommends usage of container technology-specific vulnerability management tools and processes.

“Organizations should use tools that take the pipeline-based build approach and immutable nature of containers and images into their design to provide more actionable and reliable results,” says NIST.

They should be able to easily integrate across the image lifecycle from building to runtime process.

With high visibility, they should be capable of reading vulnerabilities across all layers of the image, from base layer to application frameworks and custom software. This visibility should ideally include flexible reporting and monitoring in line with organizational goals.

At the policy level, there should be quality gates that check image vulnerability at every stage of the image lifecycle and allow only those meeting the set standards.

2) Countermeasures to Registries

NIST recommends organizations to configure their development tools, orchestrators and container runtimes only to registries over encrypted channels.

It recommends pulling images only from trusted sources.

When accessing from a poorly configured registry, the access should happen through encrypted and authenticated connections.

Also, the registry should undergo continuous monitoring to ensure all stale images that offer scope to vulnerabilities are cleared.

This can be done by automating, based on time triggers and labels related images, procedure of identifying registries with unsafe and vulnerable images that are no longer useful.

The other way is to use operational procedures to access images using immutable names that identify discrete versions of useful images.

3) Countermeasures to Orchestrators

The administrative interface that involves ‘single orchestrator managing multiple apps’ needs special attention in countering orchestrator-related security issues.

NIST recommends orchestrators to use a least privilege access model allowing users to only perform specific actions on specific hosts, containers and images that their work demands.

It recommends tight access control to cluster-wide administrative accounts through effective authentication methods such as multifactor authentication beyond just password authentication.

By sensitivity, different orchestrators should be configured to separate network traffic categorized into discrete virtual networks. Public-facing web applications should be isolated from high-sensitivity workloads. Workloads should be allowed to run in their assigned security levels.

Segmenting containers by purpose, sensitivity and threat posture provides additional defense-in-depth, says NIST. Overall, orchestrator platforms should be configured to features that make them facilitate a secure environment for all apps they run.

4) Countermeasures to Containers themselves

Besides the entities such as apps and images they hold, containers themselves are often considered vulnerable to security risks.

The most common security issue with containers occurs when container runtimes that manage containers themselves contain vulnerabilities. So, container runtimes require special attention and should be remediated in case of any issues. A vulnerable runtime can expose all containers it runs and also the host OS to potential security risks.

Moreover, administrators must pay special attention to all the configurable options associated with the runtimes. Misconfigured runtimes may enjoy unrestricted access to all devices that can cause potential threats to all containers running on the host.

Given the flexibility that containers enjoy through dynamic IPs over the network, there is a need to identify network anomalies in such an environment and apply relevant filtering tools to address any possible vulnerabilities.

5) Countermeasures to Host OS risks

Host OS is key to a successful container environment.

Given the fact it lies at the lowest level of the container architecture, it is the more critical target to security threats. A compromise of the host OS can lead to the compromise of all containers running on it.

“Whenever possible, organizations should use these minimalistic OSs to reduce their attack surfaces and mitigate the typical risks and hardening activities associated with general-purpose Oss,” recommends NIST.

Host OS’ meant for containers should only run them and exclude any other apps such as web servers, database, system services or anything beyond containers. Doing so helps them avoid the chances of possible attacks.

Moreover, host OS’ should undergo continuous scans for vulnerabilities and any required updates should be immediately applied. This is not just at the level of container runtime, it should also be done to the lower-level components such as kernel, which are key to secure container operations.

“Even though container-specific OSs have a much more minimal set of components than general-purpose OSs, they still do have vulnerabilities and still require remediation, says NIST.

Proper configuration is also important to the security of host OS. It should be run as an immutable infrastructure with no data and application-level dependencies. This makes host OS highly reliable and effective in functioning.

6) Automation is Vital

Given the aforementioned factors, it is clearly evident that container security needs a different approach. Doing all these actions every time, especially in a larger setup with hundreds of hosts and containers involved, will be a herculean task. So, NIST recommends automation of security processes to the possible extent.

Though orchestrators possess some abilities to automate certain tasks, it’s also the responsibility of container admins to master the art of automating some functions such as vulnerability checks and software updates.

Moreover, organizations need to clearly examine the internal processes and workflows for implementing effective automation and ensure better container security.

In Conclusion
The National Institute of Standards and Technology (NIST) offers a detailed container security guide, which gives more comprehensive information on achieving the goal of container security.


Related Stories: