Applications have historically been deployed and created in a manner reminiscent of classic shopping malls. First, a developer builds the mall, then creates the various stores inside. The stores conform to the dimensions of the mall and operate within its floor plan.

In older approaches to application development, a developer would have a targeted system or set of systems for which they intend to create an application. This targeted system would be the mall. Then, when building the application, they would tailor it to fit within the confines of the targeted system, like the store in the mall.

Historically, however, problems have arisen with this approach. What if I want to deploy a store within a mall but the store doesn’t fit within the confines of the mall floorplans? The same principle applies to applications. What happens if I want to deploy an application to a system it wasn’t designed to target? Usually, it won’t work.

The retail industry came up with a creative solution to the misfit brick-and-mortar store problem — e-commerce. With websites, items could be sold that didn’t fit in physical storefronts. Similarly, the technology sector has a solution for the application misfit problem — containerization.

What is containerization?

Containerization provides a method for developers to distribute applications as a portable package.

With containerization, developers and engineers can distribute an application as a package that contains the required operating system components for the application. This allows engineers and developers to create applications without the concern about whether an application will successfully deploy to a custom operating system or platform. Because containers usually only include the required components and files of their contained application, they can have a significantly reduced attack surface compared to other solutions such as virtual machines.

Virtual machines were originally created as a solution to allow a single computer or server to execute software in isolation while preserving the integrity of the supporting host. This was an evolution upon deploying software applications to dedicated hosts and hardware intended to provide better portability and security. Virtual machines achieve this goal but also include software and tools that are not used by a deployed application but are used by attackers. Extra functionality and utilities within the environment that executes an application provide attackers with functionality they can leverage to further attack organizations.

While containers are intended to not include extraneous tools and functionality like virtual machines do, containers are not without risk or security concern. Containers do not provide perfect isolation from the host that they execute upon like virtual machines are intended to do. There is shared software and functionality between containers and their executing hosts that increases the risk to the host, such as sharing the same kernel, which normally is not a concern with virtual machines. Sometimes this shared functionality can be used to escape a container and allow an attacker to access other containers and sensitive information within the containers’ host.

Within the container, like virtual machines, secrets and sensitive information is used by applications and can pose a risk to other systems if discovered by attackers. Applications that rely on database credentials, for example, might have those credentials stored in files included within the container image. If the container image were published, it would pose a serious risk to the database and the data it holds. Even though containers do not contain full operating systems, the portions of an operating system they do contain can still become outdated and vulnerable to attacks. The libraries that applications use in their software supply chains can also be vulnerable, especially if they are outdated.

Container vulnerabilities abound

The inside of a container isn’t the only location that can contain vulnerabilities. The ways a specific container interacts with its environment can create vulnerabilities too. Applications that are architected to run within cloud environments as containers may have additional functionality implemented for integration with those environments. The integration can elevate the risk of an attack.

The cloud provider, container, and platform the container operates within represent the context of a container. The context a container executes within can include things such as service accounts that the application within the container can leverage to access the cloud environment. Service accounts can have permissions and privileges assigned to them that may be too broad in nature and could allow an attacker to perform operations on the cloud provider’s platform. These operations might include accessing databases with sensitive data, such as credit card numbers or creating crypto-currency miners that run high costs on accounts.

How to secure your containerized environments

To prevent those kinds of issues, many tools have been created to allow engineers to analyze the security of the contexts within which the containerized applications execute. The tools that have been created, such as Snyk and KubeAudit most notably, scan configurations and permissions to identify permissions that may be too broad or configurations that could allow for container escapes or application vulnerabilities. These tools are fantastic for identifying very basic issues within their targeted domains.

Unfortunately, most of the time these tools are built from preconceived ideas about how applications are built and integrated into their cloud contexts. Often these preconceived notions, however, do not match reality and therefore tell engineers of security “issues” that are not relevant to the containers and applications within the environment. Containerized applications many times have a need to interact and integrate with their platform in a way dictated by business requirements that various automated tools can’t account for. These false positives can waste a lot of time. Because the platforms and utilities that run containers are designed for integration, the resulting system of container, context, and cloud provider needs to be reviewed and attacked using an attacker’s mindset to determine the real quantifiable security of the integrated system. This process can only be done by a human, and it is how real-world attackers break in.

A good practical approach to minimizing risk in containerized environments leverages all the available resources. Thankfully, many of the available tools and resources are free and easy to use. Many cloud providers provide container image scanning services, which are integrated into their platforms. Using these services can add significant value. Leveraging configuration scanners for both cloud accounts and container platform environments can provide a fantastic starting point for determining the initial risk of these environments and help teams remediate any low-hanging fruit.

Utilizing Kubernetes and container-aware endpoint detection and response systems can provide intelligence about a compromise before an attacker can affect your systems. After taking those steps, penetration testing can be used to cut through the various false positives and negatives of tooling and monitoring systems, validate a security posture, and give actionable intelligence about your environment with context-specific recommendations.

X-Force Red, IBM Security’s team of hackers, can provide container testing services to organizations worldwide. Their goal is to uncover and help remediate flaws inside and around containers in the cloud. The testing includes the containers themselves, and their supporting infrastructure, such as orchestrators. For more information, download the X-Force Red Container Testing Services infosheet here.

If you’d like to schedule a consult with IBM Security X-Force, fill out the scheduler form here.