In this blog post
We live in a world of innovation and are beneficiaries of new advancements. New advancements in software technology also comes with potential security vulnerabilities.
‘Containers’ are no exception. Let us first understand what a container is and then the vulnerabilities associated with it and how to mitigate them.
What is a Container?
You might have seen containers in the shipyard. It is used to isolate different cargos which is transported via ships. In the same way, software technologies use a containerization approach.
Containers are different from Virtual Machines (VM) where VMs need a guest operating system which runs on a host operating system (OS). Containers uses OS virtualization, in which required processes, CPU, Memory, and disk are virtualized so that containers can run without a separate operating system.
In containers, software and its dependencies are packaged so that it can run anywhere whether on-premises desktop or in the cloud.
Source: https://cloud.google.com/containers
As stated by Google, “From Gmail to YouTube to Search, everything at Google runs in containers”.
Container Vulnerabilities and Countermeasures
Containers Image Vulnerabilities
While creating a container, an image may be patched without any known vulnerabilities. But a vulnerability might have been discovered later, while the container image is no longer patched. For traditional systems, it can be patched when there is a fix for the vulnerability without making any changes but for containers, updates should be upstreamed in the images, and then redeployed. So, containers have vulnerabilities because of the older image version which is deployed.
Also, if the container image is misconfigured or unwanted services are running, it will lead to vulnerabilities.
Countermeasures
If you use traditional vulnerability assessment tools to assess containers, it will lead to false positives. You need to consider a tool that has been designed to assess containers so that you can get actionable and reliable results.
To avoid container image misconfiguration, you need to validate the image configuration before deploying.
Embedded Malware and Clear Text Secrets
Container images are collections of files packaged together. Hence, there are chances of malicious files getting added unintentionally or intentionally. That malicious software will have the same effect as of the traditional systems.
If secrets are embedded in clear text, it may lead to security risks if someone unauthorized gets access.
Countermeasures
Continuous monitoring of all images for embedded malware with signature and behavioral detection can mitigate embedded malware risks.
Secrets should never be stored inside of containers image and when required, it should be provided dynamically at runtime.
Use of Untrusted Images
Containers have the advantages of ease of use and portability. This capability may lead teams to run container images from a third party without validating it and thus can introducing data leakage, malware, or components with known vulnerabilities.
Countermeasures
Your team should maintain and use only trusted images, to avoid the risk of untrusted or malicious components being deployed.
Registry Risks
Registry is nothing but a repository for storing container images.
1. Insecure connections to registries
Images can have sensitive information. If connections to registries are performed over insecure channels, it can lead to man-in-the-middle attacks that could intercept network traffic to steal programmer or admin credentials to provide outdated or fraudulent images.
You should configure development tools and containers while running, to connect only over the encrypted medium to overcome the unsecured connection issue.
As we have already seen that registries store container images with sensitive information. Insufficient authentication and authorization will result in exposure of technical details of an app and loss of intellectual property. It also can lead to compromise of containers.
Access to registries should authenticated and only trusted entities should be able to add images and all write access should be periodically audited and read access should be logged. Proper authorization controls should be enabled to avoid the authentication and authorization related risks.
Orchestrator Risks
- Unbounded administrative access
There are many orchestrators designed with an assumption that all the users are administrators but, a single orchestrator may run different apps with different access levels. If you treat all users as administrators, it will affect the operation of containers managed by the orchestrator.
Orchestrators should be given the required access with proper role-based authorization to avoid the risk of unbounded administrative access.
- Poorly separated inter-container network traffic
In containers, traffic between the host is routed through virtual overlay networks. This is managed by the orchestrator. This traffic will not be visible to existing network security and management tools since network filters only see the encrypted packets traveling between the hosts and will lead to security blindness. It will be ineffective in monitoring the traffic.
To overcome this risk, orchestrators need to configure separate network traffic as per the sensitivity levels in the virtual networks.
- Orchestrator node trust
You need to give special attention while maintaining the trust between the hosts, especially the orchestrator node. Weakness in orchestrator configuration will lead to increased risk. For example, communication can be unencrypted and unauthenticated between the orchestrator, DevOps personnel, and administrators.
To mitigate this, orchestration should be configured securely for nodes and apps. If any node is compromised, it should be isolated and removed without disturbing other nodes.
Container Risks
- App vulnerabilities
It is always good to have a defense. Even after going through the recommendations, we have seen above; containers may still be compromised if the apps are vulnerable.
As we have already seen that traditional security tools may not be effective when you use it for containers. So, you need a container aware tool which will detect behavior and anomalies in the app at run time to find and mitigate it.
- Rogue containers
It is possible to have rogue containers. Developers may have launched them to test their code and left it there. It may lead to exploits as those containers might not have been thoroughly checked for security loopholes.
You can overcome this by a separate environment for development, test, production, and with a role-based access control.
Host OS Risks
- Large attack surface
Every operating system has its attack surface and the larger the attack surface, the easier it will be for the attacker to find it and exploit the vulnerability and compromise the host operating system and the container which run on it.
You can follow the NIST SP 800-123 guide to server security if you cannot use container specific operating system to minimize the attack surface.
- Shared kernel
If you only run containers on a host OS you will have a smaller attack surface than the normal host machine where you will need libraries and packages when you run a web server or a database and other software.
You should not mix containers and non-containers workload on the same host machine.
If you wish to further explore this topic, I suggest you read NIST.SP.800-190.
References
- https://cloud.google.com/containers
- https://azure.microsoft.com/en-in/overview/what-is-a-container/#overview
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf
Author
