As enterprise software containers become ever more critical to running applications easily across clouds, securing them has become a mounting problem.

And as more workloads move onto these containers, using the container cluster management software Kubernetes, they require better tools, more specialized knowledge of their potential exploits, and more automated techniques that are still being invented to handle their complexities and subtleties.

Containers have been around for more than a decade, and businesses have embraced them readily because they offer flexibility and are easy to create and discard for specific tasks. They combine the best features of cloud-based virtual machines with lightweight and reusable code that is quick to develop and deploy.

A recent survey by SpectroCloud found that 83% of those interviewed had between two and more than 10 container collections that were spread across managed services such as Amazon Web Services’ Elastic Kubernetes Service or hosted on a variety of tools such as Red Hat OpenShift or other platforms. And 14% of those surveyed have more than 100 clusters, which just means that there is room for growth for the remaining 86%.

“In the last year we’ve really seen the enterprise actually start to shift their workloads over to cloud native architectures, because they have better applications observability,” Martin Mao, chief executive of container security vendor Chronosphere, told theCUBE, SiliconANGLE Media’s video studio, said this week during the KubeCon + CloudNativeCon conference.

A new Kubernetes Security report Wednesday from Wiz Inc. analyzed more than 200,000 cloud accounts and found that attackers are becoming proficient at pivoting back and forth between container clusters and cloud accounts. They found that attacks are so attuned to container creation that it takes less than three hours — and in some cases mere minutes — for a typical malicious exploit to find them.

Few clusters segregate their network traffic, and other security controls are lacking. “However, as Kubernetes adoption continues to soar, so do the security risks,” the authors wrote in their report. They mention privilege escalation and lateral network movement within a Kubernetes cluster as two prominent security risks. These have been well-known in the networking world for decades and have numerous tools to detect, defend against and deploy for appropriate protection. This is an indication that container security still is in its infancy.

The many dimensions with maintaining container security

But with this popularity comes a dark side, meaning that securing containers and their clusters is a lot harder problem than setting up the protection for other resources that have more permanence, such as a web or database server. The reason has to do with the multiple dimensions of protection containers require:

• Many applications make use of dozens or hundreds of containers and a mixture of open- and closed-source projects. This puts pressure on developers to understand how best to orchestrate containers and ensure that the appropriate security controls are built-in, and how they should deploy runtime application protection to scan their code constantly. Orchestration and runtime protection have both been available for generalized cloud applications for years, but they need additional features to secure container usage.
• Securing the build and development environment and code pipelines will stretch already delicate software supply chains. Given the building block nature of containers, this means developers need to enforce image source integrity controls and being able to track the supply chains with tools such as those which are used to track software bill of materials. Although that doesn’t sound too difficult, Emily Fox, software engineering lead of emerging technologies for security at Red Hat, told theCUBE this week that “a lot of organizations don’t necessarily understand how they should be using these bills of materials. And software supply chain security is actually driving a lot of the zero-trust conversations that are now coming to the forefront, because it’s not necessarily about just signing and verification, it’s actually understanding what went into the build and whether or not you can make decisions about that information.”
• Another problem is that it’s high time for development and security teams to work together to meet both of their needs. “Developers now have a lot on their plates, and they are thinking first and foremost about building apps and not all the operational and security concerns,” Joe Fernandes, vice president and general manager of hybrid platforms at Red Hat, told theCUBE. That was echoed by Melinda Marks and Paul Nashawaty of Enterprise Strategy Group, who wrote in a June 2023 blog post on SearchSecurity: “Security pros need to understand the development process to make sure security can be modernized to support efforts for greater productivity and scale.”

There is some hope, however: Last year Kirsten Newcomer, director of cloud and DevSecOps at Red Hat, told SiliconANGLE that “the Kubernetes paradigm requires involvement of both teams. Actually, in some ways, it forces involvement of developers in things like network policy for the [software-defined network] layer.”

Fixing container security won’t be simple

If all this seems overwhelming, a good starting point is Sysdig Inc., which has long been a leader in container security. It has a series of excellent tutorials — using its software as examples, of course — that walk developers through some of the common security use cases, such as auditing runtime code for odd behaviors, performing forensic analysis and examining vulnerabilities. The company also offers its open-source tool Falco and commercial tools Monitor and Secure, the latter for image scanning and vulnerability monitoring.

Next, enterprise security managers should carefully examine what security services are available from the major cloud platform providers. One issue is that these tools are more general-purpose and weren’t originally designed for containers. But all of the providers have been busily adding container features to services, such as Microsoft Defender for Cloud, Google Kubernetes Engine, Google Cloud Security Command Center and Amazon Inspector, Fargate and GuardDuty.

Speaking of Amazon, it recently posted a very detailed explainer on how to use its various container security service offerings. It’s certainly needed, because its various tools have vastly different security models and use cases, making them even more difficult to implement without spending a lot of time reviewing the documentation.

Then there are various container specialty products, such as Akeyless, which does dynamic credential secrets management. This provides just-in-time access for containers to facilitate machine-to-machine communications. Given the ephemeral nature of containers, this approach will become increasingly important to secure and manage their credentials.

Another tool to watch is the open-source projects devoted to OpenTelemetry. It had 15 sessions devoted to its use at this week’s KubeCon conference, showing its importance.

Two of the biggest areas of innovation have to do with observability and orchestration, and the opportunities to automate both to handle the large number of containers as they enter and leave a computing environment. For the former, Cilium has become the de facto building block for cloud-native network infrastructure. It’s central to efforts to bring software supply chain security visibility and enforcement closer to the Linux kernel that lies at the heart of most containers.

Tetragon, a Cilium project for runtime network observability, recently came out with its v1.0 release, showing how this particular security segment is maturing.

In the orchestration area, the Cast AI Group Inc. last year came out with its tool to automate Kubernetes cost reduction and provisioning. There are other tools that do some of this available from the major cloud providers too.

Some of the longtime cloud security providers have branched out into container security, such as Alertlogic, which added container security to its managed detection and response product line.

One place to watch is the continued pace of mergers and acquisitions in this market segment. For example, Red Hat bought StackRox and rebranded it Advanced Cluster Security for Kubernetes, Cisco Systems Inc. bought Portshift and rebranded it as Panoptica’s Attack Path Engine, VMware Inc. bought Octarine and folded its features into its Carbon Black, and Rapid7 Inc. acquired Alcide.IO Ltd. In addition, F5 Networks Inc. acquired Threatstack, Weaveworks Inc. acquired Magalix Corp and Tenable acquired Flawcheck and folded into its container image scanner that leverages its Nessus security expertise.

Most of those companies still offer the original open-source versions in addition to integration into their proprietary security lines. That means corporate developers can try before they buy anything.

One bright spot in this landscape is those providers that are beginning to integrate their separate tool sets and collaborate to cover more of the container waterfront. One example: this week’s announced partnership where cloud runtime threat detections identified by SentinelOne Inc. are correlated with vulnerabilities found by Snyk Ltd. in container images. That makes sense, because every enterprise needs both general cloud security as well as container-specific protection.

Finally, Wiz’s latest report recommends what it calls playing zone defense. “Instead of reactively pairing security controls for every potential attack vector, security managers should proactively cover the most vulnerable points and use wider security options as a backup shield.” Still, dunking the ball from beyond the foul line might be easier than keeping those containers secure.

Image: ValdasMiskinis/Pixabay