Container Security: Examining Potential Threats to the Container Environment

Containers have become one of the most essential technologies in DevOps and are often used by companies for development, testing, packaging and deployment of applications. Containers can increase the speed and efficiency of the development process while maintaining consistency across the board, they can also expose organizations to potential risks without sufficient security controls. However, the increasingly widespread adoption of container technologies also means an ever increasing need to secure them from the wide range of potential threats at each stage of the development pipeline.

The infographic shown here illustrates these threats and risks in zones that correspond to different stages of the pipeline. Many of them are specific to certain zones, for example, images containing vulnerabilities can primarily be found at the image development stage of the process while specific vulnerabilities affect only certain components. There are also certain commonalities across most zones — such as mismanaged credentials and security settings — that can potentially be harmful during the whole process.

Data
ZONE 1
Image Development

Careless image creation A common mistake when it comes to image creation is failing to take into account the security aspects of it. Often, users will install an application while keeping the default configuration without implementing any security safeguards or controls.

Exposed data in Docker files Carelessly leaving data such as passwords and the private portions of SSH encryption keys in Docker image files can result in security compromise. Failing to change the default password of an account can also lead to an attacker gaining control of it.

Unreliable third-party resources The use of third-party resources — for example, creating an image using a GitHub repository — is often an unavoidable aspect of container development. However, this opens up the container to potential attacks, for example, if a repository owner plants malware within the repository.

Embedded malware A container image could contain malware embedded on the image after creation or hardcoded routines to download malware after image deployment.

Non-updated images that contain vulnerable applications Images that are not updated regularly may contain vulnerabilities or bugs that can be exploited for malicious attacks.

ZONE 2
Source Code Hub

Hijacked repository and poisoned resources Attackers can potentially gain access to a repository, often via misconfigured security controls and vulnerability exploitation, to alter its content or even delete it entirely.

Docker file Build server
ZONE 3
Dependencies Repo

Dependencies repository compromise Older, outdated software poses significant risks to repositories as they can have vulnerabilities that can be exploited by attackers to gain access via backdoor attacks. In addition, this zone can be prone to repository hijacking and poisoning of requested resources.

ZONE 4
Registry/Image Hub

Hijacked image registry Similar to zone 2, attackers can hijack the registry and image hubs via mismanaged configurations and exploitation of existing vulnerabilities and a requested image could be poisoned.

Docker image Test deployments
ZONE 5

Hijacked repository and poisoned resources Attackers can potentially gain access to a repository, often via misconfigured security controls and vulnerability exploitation, to alter its content or even delete it entirely.


ZONE 6

Kubernetes/Docker API abuse Vulnerabilities related to API abuse put the host system at risk. CVE-2017-1002101 allows containers that use subPath volume mounts to access files or directories outside of the volume, including the host’s file system, while CVE-2017-1002102 allows containers using secret, configMap, or projected or downwardAPI volume to trigger deletion of arbitrary files and directories on the nodes where they are running.

Kubernetes-specific vulnerability Exploitation of vulnerabilities specific to Kubernetes, such as CVE-2018-1002105, proxy request handling in kube-apiserver, can leave vulnerable TCP connections open to abuse.

Unrestricted administrative access Giving all users administrative access could possibly lead to compromise due to a larger number of possible attack entry points.

Unauthorized access Attackers could gain access to user accounts, especially those with administrative access.

ZONE 7

Environment passive recognition due to open ports A misconfigured application could have an exposed port that exposes its banners and other sensitive information upon port scanning.

Exploited applications Deployed applications can be exploited through a variety of methods, for example, SQL injection, cross-site scripting, remote file inclusion, and brute-force attacks.

Exposed ports Exposed ports in applications can potentially lead to API abuse.



Best practices to defend against container threats

The use of containers can increase the speed and efficiency of the development process while maintaining consistency across the board, but they can also expose organizations to potential risks. That’s why, for any organization that uses container technology, security should always be a top priority. By adopting a risk-based security approach that covers as much of the development process as possible, companies can help ensure that their exposure to threats is reduced.

By implementing the following recommendations and adopting a security by design stance, companies can mitigate risks to their containers and related resources and lessen any potential impact they face from these threats:

  • Docker can make use of a Linux feature called user namespace which, when enabled, allows for container isolation by limiting container access to system resources. Setting applications to run as regular users can stop privilege escalation attacks from accessing the critical parts of the container.
  • Mandatory access control (MAC) tools such as SELinux (Security-Enhanced Linux) and AppArmor can help prevent attacks that compromise application and system services by limiting access to files and network resources.
  • Minimizing the use of third-party software and using verifiable ones ensure malicious software is not inadvertently introduced to the container environment.
  • Mounting the host's root file system in read-only mode will restrict write access for applications, limiting the chances of an attacker being able to introduce malicious elements to the container.
  • Scanning images in the repository can help determine whether they contain any vulnerabilities or are not configured properly.
  • Deploying an application firewall enhances the security of the container and helps catch threats before they can enter the environment.
  • Prevent vulnerability exploitation by using tools such as Clair, which provides static analysis for containers.
  • The UNIX socket is a two-way communication mechanism that allows the host to communicate with the containers. Disabling this socket can thwart attacks that exploit it — for example, an attacker abusing the API from inside a container.
  • Using different databases for each application allows for more efficient management and greater visibility into every individual application.
  • Using the integrated firewall for the Docker virtual network, especially for TCP API control, can filter external attacks.
  • Regularly updating the host operating system and the kernel to the latest security updates can prevent exploitation of vulnerabilities that exist in older software versions.

Trend Micro Solutions

Trend Micro helps DevOps teams to build securely, ship fast, and run anywhere. The Trend MicroTM Hybrid Cloud Security solution provides powerful, streamlined, and automated security within the organization's development pipeline for runtime physical, virtual, and cloud workloads via XGenTM threat defense technology. It also adds protection for containers via the Deep SecurityTM platform and Deep Security Smart Check, providing vulnerability assessment and malware detection through fully automated pre-runtime scanning of Docker container images at the registry. This shifts security earlier in the development life cycle for comprehensive protection even prior to deployment.

HIDE

Like it? Add this infographic to your site:
1. Click on the box below.   2. Press Ctrl+A to select all.   3. Press Ctrl+C to copy.   4. Paste the code into your page (Ctrl+V).

Image will appear the same size as you see above.

Опубликовано в Security Technology, Infographics, DevOps, Containers