Fidelis Blog


Containerization and Container Orchestration Platform Protection: Cloud Workload Security Part 3

As we mentioned in a previous blog, the “Forrester Wave™: Cloud Workload Security, Q4 2019” report provided an excellent overview of the security challenges posed by cloud-based environments and the cloud workload security solutions best poised to address them based on 30 criteria. In this third blog post of our series, we explore the criterion “containerization and container orchestration platform protection.”

Public cloud computing caused a seismic shift in how application infrastructure was provisioned and managed. Soon after, another seismic shift opened up even more disruptive possibilities—workload containerization.

Today, containerized environments continue to evolve towards even greater levels of speed, flexibility, and dynamic operation. The challenge is they can be incredibly complex, especially in advanced use cases.

Solutions that provide container security must be able to address the broad set of tools typically in use, automation of change management, integration directly into continuous delivery pipelines, and scaling to handle hundreds of thousands to millions of container images and instances. The implementation of containerization and container orchestration platform protection is critical to cloud workload security.

About Containerization and Container Orchestration Platform Protection

In the key takeaways section of “The Forrester Wave™: Cloud Workload Security, Q4 2019”, Forrester says “Support For Containerization And OS-Level Protection Are Key Differentiators” and describes the capability as follows:

“With Kubernetes and Docker becoming de facto container environments mainly deployed on cloud platforms, S&R professionals need to be sure that: 1) they scan container images pre-runtime and runtime; 2) there are controls for any configuration drifts at the container level; and 3) they monitor network communications and system calls among containers as well as between containers and the underlying host operating system. Other differentiators include vendor-supplied and constantly updated best practices and compliance templates as well as agentless and agent-based container architectures.”

We’ll start with our perspective on what these capabilities entail, why they’re important, and what security and compliance control objectives they can deliver.

What Is Containerization and Container Orchestration Platform Protection?

Containerization and container orchestration platform protection is a set of capabilities that integrate directly into the broad set of components that make up a containerized environment and automatically discover, inventory, assess, monitor, and control these components.

The scope of containerization and container orchestration platform protection capabilities typically includes:

  • Security for container images at-rest (stored in registries) and in-motion (moving through CI/CD pipelines)
  • Security for container runtimes (e.g., Docker) running on hosts, pre-configured clusters, container-as-a-service (e.g., AWS Elastic Container Service or Elastic Kubernetes Service) or runtime-as-a-service (e.g., AWS Lambda)
  • Security for container instances launched into runtimes (e.g., Azure Container Instances)
  • Security for underlying container orchestration platforms such as Kubernetes or Mesos
  • Security for systems that support containerized environments, such as image registries, artifact servers, code repositories, and Jenkins hosts
  • Security for deployments across public, hybrid, and multi-cloud models

Secondary capabilities must include a range of protection capabilities not only for the containers themselves but also for the images and the runtimes, the ability to handle massive numbers of container images and instances, and the ability to implement “shift-left” strategies.

Capabilities to protect runtimes implemented as self-operated Docker hosts are particularly important to protect because:

  • All guest containers on a Docker host share that host’s operating system kernel and often other common components
  • The Docker host itself contains instrumentation with privileged access to the containers and other infrastructure (e.g., dockerd, kubectl), so if the Docker host itself is compromised, the entire environment is compromised.

For now, let’s consider why containerization and container orchestration platform protection is important and what security and compliance use cases it can address.

Why Containerization and Container Orchestration Platform Protection are Important

Containerization has revolutionized application infrastructure. Innovations in container platforms now deliver nearly unlimited portability, dynamic capacity management, and levels of operational automation never before possible. These environments continue to evolve towards even greater levels of speed, flexibility, and dynamic operation.

Effective container security requires tools with the same level of speed, flexibility, and dynamic operation. This means automation.

Below are some of the reasons why containerization and container orchestration platform protection are essential capabilities to have in the security and compliance arsenal.

Preventing a Security Incident from Becoming Viral

By now, we all know how quickly someone infected with a virus can expose a large number of other people in a short time.

Similarly, a vulnerable or otherwise dangerous container image can result in hundreds or thousands of exposed container instances in the normal course of the image being used.

Running containers are instantiated from static images, much like virtual machines from a virtual-machine image or AWS EC2 instances from AMIs (Amazon Machine Images). But containers can be instantiated even faster, leaving little to no opportunity for security intervention if an image contains dangerous code or has been subverted.

This speed means that a single bad image can expose entire application environments to attack almost instantly. This risk is compounded when other “child” container images are built on top of a bad container image.

Given that every single configuration change to a container creates another image, this results in a massive number of images (container image sprawl) that could expose the broader container environment. A large number of potentially bad containers being accessible for instantiation combined with the speed of their instantiation can lead to an explosion in attackable application surface area.

Preventing a viral security incident is just one of the many reasons why containerization and container orchestration platform protection is important.

Shifting Security To The Left By Making Security Tests Part Of The Build

Tremendous gains have been made in enabling continuous software delivery by applying the DevOps practice of shifting left.

In a software testing context shifting left means moving application testing and security earlier in the development process, which is important here because shifting security to the left is key to delivering quality software at speed—as it drives teams to start testing earlier in the pipeline and ultimately build security into software rather than bolting it on at the end.

To learn more about the concept of shifting left and its value—such as reducing the cost of fixing vulnerabilities by almost 10 times—read What is “Shift Left”? Shift Left Testing Explained – BMC Blogs.

Containerization, DevOps, and continuous delivery go hand in hand.

The key goals of DevOps are to speed up production and improve product quality. These make containerization a critical component of DevOps and continuous delivery, as it helps to increase the stability and reliability of applications and makes application management easier.

Containerization also directly supports continuous delivery pipeline infrastructure by easily integrating into existing processes. To learn more, read “Continuous infrastructure: The other CI.”

Continuous delivery of infrastructure depends on automated testing to ensure that the application and infrastructure it runs on behaves as expected: Within each stage, teams use quality gates to assess the quality level of an application. These are often referred to as “gates” since the tests have to run clean before the build can progress towards production—a failure is known as “breaking the build” and requires the owner of the changes (usually a DevOps engineer) to go back and fix what they broke.

This testing, or quality gates, is the reason why continuous delivery works well. You can focus on specific tests that will give you the fastest feedback—and with the right tooling, security can be made part of the build, ensuring that vulnerabilities never make it to production.

Achieving a shift-left posture by making security testing part of the build is a major reason why containerization and container orchestration platform protection capabilities are important.

Rapid DevOps Feedback

With traditional security approaches, such as vulnerability scanners, getting feedback to DevOps teams and other system owners takes a long time (days, weeks, even months).

Containerized environments often leverage continuous delivery and the related automated testing described process discussed above.

Making security part of the build through container orchestration platform protection capabilities creates a real-time feedback loop for system owners that’s part of their day-to-day workflow. Which means that security flaws introduced by system owners will be presented to them in real time, and they will have to fix them before moving to the next stage. This will also result in better education and far fewer security flaws making it to production.

Reducing Exposures, Vulnerability Windows, and Security Assurance Costs

Security problems are harder to fix once they’re in production. The further they get down the development pipeline, the more complicated and costly they are to fix. These difficulties result in more people and more time.

Waiting until an issue gets further into the production workflow also makes it take longer to be fixed, which means there’s a longer vulnerability window—that is, the exposure is in production for some period of time while it’s being fixed. Additionally, once the software is in testing phase, reproducing any defects on a developer’s local environment poses yet another time-consuming task.

Implementing processes for detecting early and often can be extremely valuable because it cuts down on the potential exponential costs of re-work and vulnerability remediation. With the right automation, continuous delivery methods enable reduction of exposures released into production, reduces vulnerability windows, and cuts the overall cost of security assurance for containerized environments.

This is a reason why containerization and container orchestration platform protection capabilities are essential to the effectiveness of these environments.

Prevent Attacks On Runtime, Orchestration, and Registry Layers

The end-to-end protection of containers in production is also critical to avoiding the steep operational and reputational costs of potential data breaches.

While there’s myopic focus on the containers themselves, they’re just part of the equation.

Comprehensive runtime container security also requires securing orchestration systems, which may have vulnerabilities creating even more attack surfaces for malicious actors. Attackers who are able to penetrate runtimes or orchestration layers own the environments they host and/or manage.

Your entire container ecosystem is only as secure as its least secure container, and the security of that container is at least in part dependent on the registry from which you pulled the original container image.

Compromise of image registries would mean that the very source images used to build containerized applications is compromised. Imagine what they could do by sending out pre-compromised software.

These components are critical to protect in addition to the running containers themselves. Well-rounded containerization and container orchestration platform protection capabilities are essential for ensuring that applications are protected from attacks and exploits throughout as much of the build-ship-run lifecycle as possible.

Use Cases for Containerization and Container Orchestration Platform Protection

The simple ability to implement containerization and container orchestration platform protection is a far cry from automating a specific operational task at scale, across an environment.

In our experience working with hundreds of companies on cloud security, the most critical question to ask may be “What can I do with it?”

The following capabilities can address many use cases, too many to list here. The most common use cases in which control objectives are achieved with containerization and container orchestration platform protection include:

  • Continuous Asset Awareness – Automated, continuous discovery and inventory of IaaS services and resources. You can’t do any of the things below if you don’t know the assets exist.
  • Point-in-Time Security Assessment – Assessment of public cloud account security, including the IaaS account itself and the security of the services and assets inside the account
  • Continuous Security Monitoring – Ongoing IaaS environment monitoring to detect and evaluate how changes and events impact your security and compliance posture
  • Compliance Auditing & Monitoring – Point-in-time evaluation of compliance posture against a range of standards (a.k.a. pre-auditing), or continuous compliance monitoring to surface issues as they arise instead of “cleaning up” right before an audit.
  • Detect Indicators of Threat & Compromise – Attackers will use cloud technology to their advantage, leaving cloud “versions” of rootkits and other malicious artifacts as part of their attacks. With the right containerization and container orchestration platform protection automation, indicators of these situations are quickly detected to accelerate prevention, isolation, containment, investigation, and clean-up.
  • Automated Issue Remediation – Leveraging cloud provider APIs to implement automatic remediation for exposures and compliance flaws is extremely valuable but often overlooked. Capturing metadata from provider APIs enables system owners to automate the process of zeroing in on and remediating problems, creating fully automated remediation capabilities.

Fundamental information security control objectives are still requirements in cloud environments. What’s new is how these objectives can be achieved consistently, at scale, across distributed environments.

Well-implemented containerization and container orchestration platform protection for IaaS and PaaS environments is capable of solving these new challenges through efficient, effective, and consistent automation.

Capabilities Needed to Manage Information Security Risk in Orchestrated Container Environments

Forrester discusses and evaluates the capabilities needed to manage information security risk in orchestrated container environments.

In our experience, the capabilities should address the following.

Security for:

  • Container images at-rest (stored in registries), and in-motion (moving through CI/CD pipelines)
  • Container runtimes (e.g., Docker) running on hosts, pre-configured clusters (e.g., AWS Elastic Container Service or Elastic Kubernetes Service), or turnkey container- or runtime-as-a-service (e.g., Azure Container Instances or AWS Fargate)
  • Container instances launched into runtimes
  • Container orchestration platforms such as Kubernetes or Mesos
  • Systems supporting containerized environments, such as image registry and artifact servers, code repositories, and Jenkins hosts.

Why We Believe CloudPassage Halo Achieved 5 of 5 in the Containerization and Container Orchestration Platform Protection Criterion

Our flagship solution is the CloudPassage Halo cloud security platform. Halo was purpose-built in 2010 to automate security and compliance for servers across public and hybrid cloud environments. Since that time, CloudPassage has invested heavily in the platform’s evolution to address new cloud technologies and their security needs. Halo now addresses security for server-based, containerized, and public cloud infrastructure environments including public, hybrid, and multi-cloud deployments.

Halo’s containerization and container orchestration platform protection capabilities are included in Halo Container Secure, one of the three primary services of the Halo platform. The capabilities of Halo Container Secure are our implementation of security and compliance automation for containerized environments. Halo received the highest possible score (5 out of 5) in this criterion.

Here’s how we built Halo to achieve a level of capability worthy, in our opinion, of this independent recognition.

Key Requirements That Halo Is Designed To Address

In 2010, only the earliest adopters of public cloud technologies realized just how different containerized environments are. Then and now, CloudPassage has had the privilege of working with some of the largest and most sophisticated public cloud enterprises in the world.

  • Unified Capabilities – IaaS and PaaS services don’t exist in isolation. Modern application architectures now combine IaaS and PaaS services with server-based and containerization technology (some of which is delivered by the provider themselves). Looking at components in isolation limits context and slows analysis of the overall application environment. This makes the unification of data and management across various types of cloud infrastructure a critical requirement.
  • Portability – The majority of successful digital enterprises use multiple IaaS and PaaS providers for availability, cost management, and prevention of vendor lock-in. Even within a single cloud provider, not all regions operate identically; federal and some international service regions are good examples. This makes portability of capabilities within and across cloud providers critical. API compatibility, data normalization, and common policy management are just a few of the portability issues that are important to a successful deployment.
  • Scalability – The scale of cloud infrastructure typically changes both on a short-term basis (cloudbursting or autoscaling events) and in the long term (organic application growth, new applications, data center migration). Containerization and container orchestration platform protection capabilities must be able to quickly and automatically adapt to changes in infrastructure scale, in terms of both functional capacity and licensing.
  • Automation – Changes are programmatically automated in cloud and DevOps environments. If security and compliance functions are not equally automated, they will be quickly outpaced by the infrastructure’s rate of change. Automation is needed to ensure that security instrumentation is “part of the build” and not something to be added later. Automation also ensures consistency and eliminates errors, both critical needs in highly dynamic and diverse cloud environments.
  • Operational Integration – As previously discussed, aligning security and DevOps is a critical success factor that delivers mutual benefit and a stronger overall security posture. This requires that security functionality and intelligence are automatically delivered to system owner workflow tools (e.g., Jira, Slack, Jenkins). These needs are complex, especially in larger environments, making comprehensive REST APIs, data routing, and other operational integrations critical.

CloudPassage was guided by top cloud enterprises to build the Halo platform with these and similar cloud-specific requirements in mind. Below is how Halo implements containerization and container orchestration platform protection, including details on how the platform successfully addresses these vital needs.

How Halo Implements Containerization and Container Orchestration Platform Protection

From its inception, the innovations built into the Halo cloud security platform were designed to address the critical needs discussed above. These innovations are recognized by ten patents granted to CloudPassage between 2013 and 2019 that cover various aspects of the Halo technology.

Below are just a few of the design decisions and features that enable Halo’s unification, portability, scalability, automation, and operational integration for containerization and container orchestration protection:

  • Docker host and Kubernetes nodes protecting using low-friction, low-impact microagent (2MB in memory)—same agent for server, Docker host, and Kubernetes node security—all the agent features like automatic upgrade, no listening port to attack, patented agent and communication security, outbound-only “heartbeat” communication protocol, etc.
  • Customizable “out-of-the-box” policy templates for Docker hosts and Kubernetes nodes that supporting common security and compliance standards such as PCI DSS, CIS Benchmarks, HIPAA, and SOC 2 / SysTrust criteria for Docker 
  • Deep inspection and collection of container host metadata including raw Docker-inspect output, image source, identification of unknown or “rogue” containers, etc…
  • Fast, scalable, fully automated security analytics capabilities that include tracking of initial issue appearance, automated detection of remediation, and issue regressions
  • Detailed remediation advice for issues identified, presentation of raw assessment data for automation and inspection purposes, and instructions to manually verify findings if needed
  • Bidirectional REST APIs and direct integration with queueing services like AWS SQS to enable operational automation and direct integration with other security and DevOps tools
  • Operational features and integration tools to automate deployment, configuration, issue routing, email alerting, and bidirectional interaction with operational tools such as Jira and Slack
  • RBAC and data access features to ensure system owners only interact with authorized systems

The list of capabilities above only addresses Halo Container Secure, the Halo platform service that implements API-level connectivity and control.

An exhaustive explanation of every innovation is outside the scope of this article. However, Halo’s innovations cover a much broader range of cloud-related issues, including assumed-hostile running environments, multitenancy, asset cloning, ephemeral workloads, agent security, and more.

Learn More About CloudPassage Halo

To learn more:

Come back and read our upcoming blogs on:

  1. Scalability of protected cloud instances and protected containers
  2. Centralized Agent framework plans

Related Posts