Container Security, Explained

Container security, in this case, is not about physical shipping containers. In technology, the term container refers to the containerized software environment — one that contains all packages, libraries and dependencies required to run a software application component in isolation.

These environments can be seen as minimalist virtualized operating systems (OS): containers provide portable, reusable and automated systems to run a software application.

To meet the changing needs of software development teams, containers are orchestrated and adapted. Today, containers enable organizations to push new product features and release cycles to the market a lot faster, as promised by modern SDLC frameworks such as DevOps and Agile.

Securing these containers can feel daunting to a development team that is used to having security checks after the development cycle. But today, with security shifting further left in DevOps teams, let’s look at what container security really means.

Containers vs. traditional virtualization

Let’s review how container technologies are different from a traditional virtualization model where the OS layer and dependencies are shared between multiple software components.

The container technology shares the following key attributes:

Portable

Container technologies are portable across the SDLC pipeline. Once a container image is built for development, it is reusable for testing, QA and production stages without modifications — as long as the required configurations, dependencies and libraries are shared consistently.

The container is also portable among vendor platforms and service delivery models. For instance, the container can run on private, public, multicloud and virtualized data center environments as long as the underlying host OS supports the container.

Minimal

The application container is built with the bare minimum software packages required to run an application component. It only executes the OS functionality required to run the application process, while other OS features are operated by the host OS.

If a complex application requires a complex set of OS features, then multiple containers may be developed as part of a microservices architecture. 

A container is a method of packaging, deploying and running software. You could have one giant monolithic application as a container. You could also have an app built with microservices that does not use containers at all.

Declarative

The declarative programming nature of the container technology allows users to parse data that describes the operational process of the underlying hardware. This data may include information about OS, package and network configurations.

Immutable

The state of a container remains consistent, even when it is deployed and running. This means that changes to the container..

• Are not introduced at runtime.
• May require the users to create a new container from scratch to include the necessary changes.
• Use environment variables to change application configurations and behavior during runtime.

Immutability & data persistence

Naturally, these attributes have implications on how the applications interact with data. Specifically, data persistence — the lifetime and retrieval of data after the container is terminated. Since the container is designed to operate in isolation and an ephemeral state, it requires integration with external database or cluster storage systems to achieve data persistence.

With the portable and declarative nature of container technologies, various teams can adopt consistent configurations and set up of the runtime container environment.

Container immutability also addresses the common issue of “it works on my machine”. As the container packages all required dependencies and libraries, users are not required to adapt the runtime environment to make it work across different machines and host OS.

Challenges with securing your containers

Consequently, these characteristics also present a different set of challenges when it comes to cybersecurity, especially in comparison with virtual machines:

Multiple, discrete environment components

Monolithic environments require an exhaustive set of environment objects to run the app. These include resources that are not portable but dedicated to run multiple app components on the same infrastructure environment.

On the other hand, containers and microservices include several discrete components provisioned for every app component running within an isolated container.

For example, a Web service VM may only require a front-end web server VM and a back-end database infrastructure. Microservices on the other hand, may require multiple containers running on the front-end and backend for different application components and services.

High change frequency

Agility is a major selling point for container technologies, which means that developers can deploy a new application feature frequently. New container environments and frequent changes in microservices based SDLC processes require security tools and practices that can handle such dynamic operations. 

Cybersecurity responsibility is distributed

Developers carry more responsibility to execute an effective security strategy for the containers they build and distribute across upstream SDLC processes. For example, developers are expected to update a container image if one of the components is vulnerable and a security patch is available. This requires close collaboration between developers, infrastructure and operations teams and cybersecurity experts within the organization.

Cybersecurity must be portable

As the container is distributed across different infrastructure platforms, security becomes unpredictable and dynamic. Developers cannot make assumptions regarding these platforms, especially when using third-party cloud services.

Therefore, a holistic security strategy for containers must involve the tools, processes, network configurations and topologies, host operating systems and other dependencies that may change across the SDLC pipeline.

Ephemeral enough?

When compared to VMs that rely on static IP addresses, containers rely on the orchestration tools to allocate IP addresses dynamically. Therefore, the security policies and firewall rules may be reconfigured — often with human involvement — as the container is distributed.

Host OS

The host operating system not be optimized for security, especially for public cloud environments that are designed for a general-purpose functionality.

Although the container system itself contains only fewer application-specific components and users can plan for their risk mitigation and management, containers nevertheless share some general-purpose host OS components that may be vulnerable and unknown to developers.

Container runtime risk

Container Runtime Risk is also a rare possibility where a vulnerable software package within the container can allow malicious actors to install and spread malware across the network. If the container is compromised, and the security tools and processes are not adequately container-aware, the container traffic may not be inspected for security threats.

Orchestration & container image risk

Orchestration and Container Image Risk —in the form of inadequate identity and access controls —present additional challenges from a cybersecurity perspective.

This is especially the case for unmanaged inter-container network traffic: this traffic runs and is managed by an overlay virtual network. The orchestration tools that govern such a network may not share the security capabilities of existing network security tools.

Optimizing container security

In context of these challenges, you can optimize your container security by focusing on:

• Developer responsibilities and security awareness.
• Container orchestration and network threat intelligence.
• Risk mitigation for third-party cloud infrastructure platforms.

Containers themselves are not inherently more or less secure than non-containerized environments, but their complexity does create security challenges that teams must carefully manage. Many of these vulnerabilities are due to configuration errors. In fact, 67% of survey respondents had a serious misconfiguration in their container or Kubernetes environment. In the same survey, 90% of respondents had experienced a security incident in their container or Kubernetes environment in the last 12 months.

Containers in cloud-native environments should be as secure as any other type of computer infrastructure. Of course, a secure environment is always a work in progress.