Major Risks For Core Components Of Container Technologies And Their Countermeasures NIST SP 800 190

In order to use the container technologies safely, everyone needs to aware of the major security risks involved in that technology and countermeasures to address them. Here in this article, we are going to present the risk of the core components of the container technologies and their countermeasures with the reference to the NIST Special Publication 800-190. The following figure illustrates the core components and the risk involved in them:

core components and the risk involved in container technologies

Image Risks

  • Image vulnerabilities

As images are static archive files, which include entire components to run a given application, the components within the image sometimes missing critical security updates. Therefore, the common risk involved in the containerized settings is deployed containers possessing vulnerabilities; since the image version used to create the container includes vulnerabilities.


The organization needs to use management tools designed especially for container technologies because these tools use the pipeline-based build approach & immutable feature of containers as well as images to offer more reliable and actionable results.

  • Image Configuration Defects

The images also include configuring defects that can expose the system to attack, though it is fully up-to-date.


The organization must adopt tools & processes to evaluate as well as enforce compliance with best practices for secure configuration. In addition, the container should be executed in an immutable way to derive the security benefits.

  • Embedded Malware

Since images are a collection of files that are packaged together, there is a possibility to include malicious files intentionally or unintentionally within them. An example source of the embedded malware is the utilization of base layer & other images presented by 3rd parties of which the entire provenance isn’t aware.


Organizations must continuously oversee entire images to determine the embedded malware. The processes of overseeing should comprise the utilization of malware signature sets & behavioral detection heuristics.

  • Embedded Clear Text Secrets

Several applications need secrets to facilitate secure communication among the components. When an application is packaged into the image, it is possible to embed these secrets directly into the image file. Though, this approach leads a security risk since anyone who has access to the image can effortlessly describe it to aware these secrets.


Secrets must be stored external to the images and presented dynamically only at runtime as required. The organization can also integrate the container deployments with the available enterprise secret management systems, which are already in place for keeping secrets in the non-container environments.

  • Use Of Untrusted Images

The ease of use and portability of the containers enhances the temptation of the professionals to run images from the external sources, which mightn’t be trustworthy or validated. These actions result in the risks like introducing malware, including vulnerable components or leaking data.


The organization must maintain the set of trusted registries and images and guarantee that only the images from that set are permitted to execute in their container environment, thus addressing the risk of malicious or untrusted components being deployed.

Registry Risks

  • Insecure Connections To Registries

In case the connections to the registries are conducted over an insecure channel, then the image contents are vulnerable to the confidentiality risks, man-in-the-middle attacks, credentials thefts, etc.


Organizations must set their development tools, container runtime, and orchestrators to the only association to registries over the encrypted channels. This approach will ensure that entire data pushed to & pulled from the registry happens between trusted endpoints & is encrypted in the transit.

  • Stale Images In Registries

Since registries are the source location for entire images that organization deploys, there is a possibility to store images with vulnerabilities and out-of-date versions over the time. This risk can enhance the possibility of accidental deployment of the known-vulnerable version.


Two methods:

  1. The organization can clip registries of vulnerable, unsafe images, which should no longer be employed. This approach can be implemented based on the time triggers & label related with images.

  2. Operational practices must highlight accessing images by using immutable names, which mention discrete image versions to be used.

  • Insufficient Authentication And Authorization Restrictions

Since registries sometimes include images used to execute proprietary or sensitive applications and to contact sensitive data, the insufficient authentication and authorization restrictions can route to intellectual property loss & expose significant technical details.


All access to the registries, which include sensitive images should need authentication. Any write access to the registry should need authentication to guarantee that only the images from the trusted entities can be appended to it. Registries also offer a chance to employ context-aware authorization controls to the actions.

Orchestrator Risks

  • Unbounded Administrative Access

A single orchestrator may execute several different applications, each handled by the different teams & with different levels of sensitivity. In case the access offered to users & groups isn’t scoped to their certain requirements, a careless or malicious user could subvert or affect the other containers’ operations.


Orchestrators should employ the least privilege access model to ensure that users are only provided the capability to perform the certain actions on the certain containers, hosts, and images their roles need. In addition, the test team members should possess limited access to the containers utilized in production.

  • Unauthorized Access

Orchestrators often comprise their own directory service for authentication that may be discrete from the directories which are already in place within the organization. This can root to weaker account management practices & orphaned accounts since these systems are less strictly managed. Since most of these accounts are privileged in the orchestrator, any compromise on them can root to systemwide compromise.


Unauthorized access to the cluster-wide administrative accounts must be controlled tightly to ensure that it provides the capability to affect entire resources in the environment. Organizations should employ multifactor authentication methods and should implement single sign-on to available directory systems.

  • Poorly Separated Inter-Container Network Traffic

In several containerized environments, the traffic between the individual nodes is directed through a virtual overlay network. The worst case is the traffic risk from the various applications which sharing the same virtual networks. In case, the application with various levels of sensitivity are using the same virtual network, the sensitive internal applications may be exposed to greater risk due to network attacks.


Orchestrators should be designed to isolate network traffic into different virtual networks based on the sensitivity level. With the possibility of per-app segmentation, the organizations as well as use cases, simply describing networks based on sensitivity level offers sufficient risk mitigation within the manageable complexity degree.

  • Mixing Of Workload Sensitivity Levels

By default, orchestrators can place workloads of varying levels of sensitivity on the same host. If a critical vulnerability presents in the web server, then that can leave the container which processing sensitive financial data at a greater risk of security compromise.


Orchestrators must be configured to separate deployments to certain sets of hosts by levels of sensitivity. It should define rules to defend high-sensitivity workloads from being run in the same environment as those executing lower-sensitivity workloads. A best practice is to bundle containers together based on relative sensitivity & to guarantee that a provided host kernel only executes containers of the single sensitivity level.

  • Orchestrator Node Trust

Weak orchestrator design can present the orchestrator and all components of the other container technology into increased risk.


The platforms of the orchestration must be designed to present features, which make a secure environment for entire applications they run. The orchestrators should guarantee that the nodes are introduced to the cluster in a secure manner and offer an accurate inventory of the nodes & their connectivity states.

Container Risks

  • Vulnerabilities Within The Runtime Software

This risk is certainly dangerous in case they allow the scenarios like container escape in which malicious software can breech resources in the other containers & the host Operating System itself.


The container runtime should be carefully tracked for vulnerabilities & when issuers are determined, they should be remedied as soon as possible. The organization must use tools to search for any instances at the risk and to guarantee that orchestrators permit deployments to appropriately maintain runtimes.

  • Unbounded Network Access From Containers

In several container runtimes, individual containers are capable to access the host OS. In case the container is acting maliciously, it would permit this network traffic to expose other resources to risk.


The organization must control the outlet network traffic created by containers. At least, these controls must be in use at network borders, guaranteeing containers aren’t capable to send traffic over the networks of varying sensitivity levels. The organization should employ compilation of available network level devices & several app-aware network filtering.

  • Insecure Container Runtime Configurations

Container runtime exposes several configurable choices to administrators. configuring them improperly can reduce the level of system security.


The organization must automate compliance with the runtime configuration standards of the container. It can use processes or tools, which continuously evaluate the configuration setting over the environment and enforce them. Secure computing 7 profiles are mechanisms, which can be applied to constrain the system-level competencies containers are assigned at runtime.

  • App Vulnerabilities

Containers may be compromised because of the flaws present in the application they run. This isn’t an issue with the containers themselves; however, instead, is the manifestation of software errors within the container environment.


Enterprises should implement extra tools, which are container aware & designed to function at the scale & change rate with containers. The tools must be capable to automatically profile a containerized application using behavioral learning as well as to construct security profiles for them to reduce human communication. These profiles should also be capable to prevent & detect irregularities at runtime.

  • Rogue Containers

Rogue Containers are unsanctioned or unplanned containers in the environment. In a development environment, this can be a common occurrence, since application developers may establish containers as the ways of testing their code. In case, these containers aren't placed via the vulnerability scanning rigors and proper configuration, they may be susceptible to exploits.


Organizations must institute different landscape for development, production, test and other processes, each with certain controls to offer role-based access control and management activities. Further, enterprises are encouraged to employ security tools to enforce baseline needs for managing vulnerability.

Host OS Risks

  • Large Attack Surface

Every host includes the attack surface. The larger the attack surface is, the higher the chances that an attacker can determine and gain access to the vulnerability to compromise the host OS as well as the containers running on it.


The organization should employ the minimalistic Operating Systems to reduce the attack surfaces as well as mitigate the risks & hardening activities related to general-purpose Operating Systems. The host OS shouldn’t run unwanted system services, which enhance its attack & patching surface areas.

  • Shared Kernel

The using of shared kernel invariable leads to the larger inter-object attack surface, even for the container specific OSs.


Together with grouping, the container workloads based on the sensitivity level, organization ensure that the containerized workloads aren’t mixed with non-containerized workloads over the same host instance. This approach makes it safer and simpler to apply defense, which is optimized for container protection.

  • Host OS Component Vulnerabilities

All host OSs, including container-specific ones, presents foundational system component. These components can include vulnerabilities & since they available, low in the architecture of container technology, they can influence entire containers as well as applications, which run on the hosts.


The organization must implement management tools and practices to evaluate the component versioning provided for the base OS functionality and management. Host OSs should be functioning in an immutable way with no state or data stored persistently and uniquely.

  • Improper User Access Rights

Container-certain OSs are not optimized to support the multiuser scenarios; because interactive user login must be rare. Enterprises are exposed to danger when the user logs on to the hosts directly to handle containers, instead of going via an orchestration layer.


Organization need to ensure that entire authentication to the Operating System is audited, login irregularities are monitored & any escalation to conduct privileged functions are logged.

  • Host OS File System Tampering

Insecure container configurations can put host volumes to experience file tampering risks. These changes could influence the security and stability of the host & other containers executing on it.


Guarantee that containers are executed with the negligible set of permissions required for the file system. Organizations should make sure that rarely containers should base local file systems on the host. They should use tools, which can oversee what directories are being placed by containers & protects the container's deployment which violates these policies.

Hardware Countermeasures

The rising complexity of the systems & the deeply embedded nature of the threats requires that security should be extended to entire components of the container technology, beginning with the firmware and hardware. This procedure would create a distributed trusted computing system and offer the most secure and trusted way to build, orchestrate, run and handle containers.

The trusted computing model must begin with measures boot that offers a verified system platform & constructs a trust chain directed with hardware and enlarged to the OS kernels, bootloaders, and the OS components to facilitate cryptographic evaluation of system images, boot mechanisms, container images and container runtimes.

Hope, the above-mentioned risks as well as their corresponding countermeasures provided you an idea on how to implement the container technologies in a secure way.

H2S information security training

    All Comments (0)

    No one has commented yet.

Leave a comment