What Red Hat’s Purchase of StackRox Means for OpenShift
With its planned purchase of Kubernetes security provider StackRox, announced Thursday, Red Hat intends to use the company’s technology to bolster what Red Hat calls a multilayer security approach for OpenShift customers running Kubernetes and containerized applications. With an emphasis on integrating security with containers and Kubernetes, Red Hat can make use of how StackRox’s security plugins cover applications consistently, from the very beginning of the CI/CD process and once applications are deployed.
In this way, StackRox offers OpenShift extra runtime protection and network policy support while improving OpenShift’s “deeper data collection for better observability, which aligns really well with Red Hat’s strategic direction,” Kirsten Newcomer, the product manager overseeing security within OpenShift who is closely involved with the acquisition, told The New Stack.
StackRox’s network policy management features for automated generation is “something we’ve been exploring,” so that ultimately, StackRox will help to improve ease of use and the overall experience for security for Red Hat customers, Newcomer said.
For SecOps, StackRox will support OpenShift customers’ behavioral analysis requirements on the runtime side. “The deep observability that StackRox provides really does a much deeper data collection than we have done previously,” Newcomer said. “They also can help customers to automate the creation of network policies based on their application analysis — and that’s been a point of complexity, for any Kubernetes users.”
Organizations typically face additional complexity challenges for security when running applications on Kubernetes, which, needless to say, represents enormous complexity in itself. For security, organizations must determine network policies when, for example, adding micro-segmentation and then adding a service mesh layer, Newcomer said. “Customers are trying to figure out how those two sets of policies interact with each other, as well as what their application needs,” Newcomer said. “So, the analysis, which leads to automated suggestions for network policies, is definitely one of the value adds [that StackRox offers] along with behavioral analysis and observability.”
StackRox’s stack was also designed for Kubernetes, as opposed to existing security platforms that previously served monolithic applications and have only extended those capabilities to serve Kubernetes environments.
Many traditional security methodologies — while underlying security principles and practices remain relevant — don’t accommodate cloud native applications, for example, Newcomer said. “So, I think what’s particularly unique about StackRox is that they’ve really taken the declarative nature of Kubernetes and leveraged that for declarative security,” Newcomer said. “So, they’re really offering a very API-driven and Kubernetes-native approach.”
Shift Left/Shift Right
While StackRox certainly offers “shift-left” security — as a number of security firms purportedly do as well — while CI/CD support is but one part of what the platform offers, which covers build, deploy and run for “security capabilities across all three of those areas,” Newcomer said.
“When we think ‘shift left,’ StackRox has done the work and we have seen there are other players out in the market who do this who have originally shifted left and focused on vulnerability analysis — and that’s a piece of it, but it’s not enough,” Newcomer said. “You have to do the configuration analysis as well.”
When creating, deploying and managing containerized apps for Kubernetes, Docker files, pod configuration data and the deployment configuration must all be taken into consideration by the security platform as part of the basic foundation in order to achieve effective cloud native security. “You have to assess all of those for things with the principles of least privilege in mind: are there asks for too many privileges that would be inappropriate or are secrets being mishandled that are embedded in some of the container image itself?” Newcomer said. “So, StackRox goes beyond vulnerability analysis to configuration analysis.”
In this way, StackRox’s platform was designed to help organizations apply security to the entire spectrum of an application’s lifecycle to achieve these goals. “StackRox is part of a full solution where it’s not just in what is sometimes called the ‘DevSec’ part of ‘DevSecOps,’ Newcomer said. This is because StackRox can use the information gathered during the CI/CD pipeline analysis during the build analysis and leverage it with a Kubernetes admission controller to declare either ‘this is allowed or this is not allowed’ based on what has been discovered,” Newcomer said. “And so you can kind of use those cloud native tools, including admission controllers and such to declaratively state ‘this is the level of security I need in my cluster, and you either are allowed to deploy or aren’t allowed to deploy based on the analysis that was done.’”
StackRox consists of a proprietary platform with a sensor and collector that runs on Kubernetes — which Red Hat plans to eventually open source. Its recently introduced open source KubeLinter static analysis tool for Kubernetes that checks that YAML files and Helm charts meet pre-set best practices and policies in order to detect anomalies in Kubernetes deployments.
True to Its Roots
Since StackRox’s creation over six years ago, the company has built its platform around managing security for Kubernetes in such a way that it integrated into the fold of the microservices running in containers.
“In microservices environments, security needs to operate the same way as the application components it seeks to protect. Whether components scale instantly by several orders of magnitude, move across clouds (public or private), or rely on a fully automated lifecycle, security needs to be applied continuously and consistently,” Wei Lien Dang, co-founder and chief strategy officer (CSO) for StackRox wrote in a blog post in 2017. “This requires security to be built into the ‘connective tissue’ that glues applications together — it has to be part of the microservices fabric itself.”
Since then, writing in a blog post his week, Kamal Shah, president and CEO of StackRox, described how StackRox was founded “with an initial focus on runtime security for containers.”
“Over time, based on customer feedback and industry trends around DevSecOps and shift-left security, we expanded the product footprint to cover use cases across the build and deploy phases of the container lifecycle.
“By joining Red Hat, we will be able to accelerate product innovation and achieve far greater scale, on a global level, than we would be able to achieve as an independent startup,” Shah wrote. “Red Hat sees the tremendous Kubernetes security benefits our customers have enjoyed, understands how security remains a top priority, and knows that together we can further increase the value we provide to our customers.”
Newcomer could not elaborate on how StackRox will become integrated into Red Hat’s OpenShift platform, while the terms of the deal and how much Red Hat has agreed to pay for the company were undisclosed. However, StackRox, which already supported OpenShift prior to the announcement, will continue to support Amazon Web Services’ (AWS) Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) and other Kubernetes platforms, Red Hat said.
Amazon Web Services and Red Hat are sponsors of The New Stack.
Feature image via Pixabay.