Container Security in the Cloud: Understanding Concepts and Requirements

Interest in containers and container platforms exploded in the second half of the 2010 decade. Amid this surging popularity, containers have become the third runtime for hosting applications besides Linux and Windows virtual machines (VMs).

In this guide, we explore the benefits of running containers in the cloud and take a closer look at how to make security work for containerized workloads

How to Run Containers in the Cloud

Compared to traditional applications, container images consist of not only the application but also incorporate all dependencies, including system libraries, drivers, and configurations. They ease deployments by making manual operating system configurations and error-prone device installations on VMs obsolete. Deployments become smooth, quick, and trouble-free.

All big cloud service providers (CSPs) offer multiple cloud services for running container workloads (Figure 1). The first variant is that customers deploy an open source or third-party container platform of their choice (e.g., RedHat OpenShift or Apache Mesos). They install the platform themselves on VMs in the cloud. So, in this scenario, cloud providers are not involved in setting up and running the container platform.

Figure 1 - How to run containerized applications in the public cloud

The second option is containers on a CSP-provided managed container platform service. Examples are Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), and Amazon Elastic Kubernetes Service. One click and a Kubernetes cluster spins up automatically.

Related:How to Choose Between Serverless, VMs, and Containers

Under this model, the container and platform configurations are the customer’s responsibility, which is the main differentiator to the third option, a focused container runtime platform in the cloud, such as Azure Function Apps or Azure Web Apps (Figure 2). The latter services enable engineers to provision – besides other options – containerized applications but hide the existence of the underlying container platform. So, the challenge for security architects is securing such a bouquet of platforms running containerized applications.

Figure 2 - Deploying containers as a function or web app in Azure

Container Security Requirements

To safeguard container workloads effectively, security architects need a comprehensive understanding of the technology layer and security-related tasks. These tasks are aimed at hardening all relevant components, managing vulnerabilities, and proactively identifying and responding to threats and attacks for the complete technology stack (Figure 3).

Hardening entails configuring all components securely, particularly implementing robust access control and network designs. Vulnerability management covers identifying security weaknesses and misconfigurations in self-developed and third-party components and patching them. Even when container images are vulnerability-free at deployment time, vulnerabilities might be identified later, as the Log4j case exemplifies. Finally, hackers can attack containerized applications and the underlying container platforms. Thus, organizations must detect anomalies and suspicious behavior in their organization’s container estate (threat detection).

Related:What Does It Take to Secure Containers?

Figure 3: Security-related challenges for containerized workloads

Hardening, vulnerability management, and threat detection are necessities for the complete technology stack (Figure 3, left): the underlying infrastructure layer (think VMs, network, storage, or cloud tenant setups), the container platform itself (e.g., OpenShift or Amazon Elastic Kubernetes Service EKS), and, finally, for each containerized application.

Responsibilities differ for the platform layer, depending on the cloud service. For containerized runtime environments such as Azure App Functions, customers must ensure that the image is vulnerability-free and the service configuration secure; everything else is with the CSP. In contrast, running an Amazon EKS cluster means the container platform configuration is also the customer’s responsibility, though the CSP patches the platform components.

Figure 4 visualizes all container-workload-related security challenges. Security architects must understand and define how they address the security tasks (hardening, vulnerability management, attack/threat detection) for each cloud service running container images (e.g., Azure Function App, Amazon EKS, Cloud Run) for every layer of the technology stack layer (application, platform, infrastructure) – if the customer and not the CSP is responsible for the particular layer.

Figure 4 - Analyzing an organization’s coverage of container-related technologies and risks

Making Security Work for Containerized Workloads

Cloud-native security tools like Microsoft Defender or Google’s Security Center are fantastic first solutions for securing containerized workloads in a public cloud. These tools detect vulnerabilities and threats in container workloads and the underlying platforms. While certainly not free, customers can activate them with just one or two (or very few) clicks and benefit immediately from an improved security posture.

When looking at Azure Function Apps, one of the Azure services that can run containerized workloads, the adequate Microsoft product is Defender for Cloud. It provides, first, Defender Recommendations. They unveil insecure parameter and configuration choices, such as “Function App should only be accessible over HTTPS” (Figure 5, 1). These recommendations are based (partially) on the CIS benchmark. The second Defender feature, Attack Paths analysis, looks at a broader context. It identifies attack paths utilizing multiple non-perfect configuration choices for breaking into a company’s cloud estate (2). Finally, Defender Security Alerts warn specialists about ongoing activities that might be an attack (3).

Figure 5 - Microsoft Defender for Cloud

What Microsoft Defender is for Azure are Amazon GuardDuty for AWS and the Google Security Command Center for GCP: good cloud-native out-of-the-box services for securing (not only) container-based workloads. Besides these cloud-native solutions, third-party security tools are also viable options. Larger organizations should compare their features and costs with those of the cloud-native service.

The real challenge with container security starts when CISOs demand full coverage for all cloud-based container workloads. Then, security architects need to analyze each relevant cloud service separately. In such an analysis, they should give three topics special attention:

In addition, third-party solutions for container security are also certainly valid options. However, comparing their features and costs with the cloud-native solutions is a must – at least for larger organizations.

Keeping Threats Contained

The horrifying reality for CISOs about container security is that container technology has already infiltrated most IT organizations. While CISOs and CIOs typically know their large Kubernetes clusters, they are less aware of the many additional, less-known cloud services executing containers. Since hackers aim to find unprotected services (rather than attacking the secured ones), organizations must analyze where they have container workloads and ensure all are secure.