Virtualization Technology News and Information
VMblog's Expert Interviews: StackRox Talks Kubernetes, Containers and Compliance


One of the things hammered home at the recent KubeCon event in Seattle was Kubernetes is maturing and being adopted quickly across the industry.  But are people thinking about security and compliance yet?  To dig in deeper, I spoke with industry expert and StackRox chief technology officer, Ali Golshan.

StackRox is one of the companies leading the charge in security for containers and Kubernetes, and just yesterday, they introduced new compliance capabilities to the StackRox Kubernetes Security Platform, enabling organizations to verify and provide evidence for compliance with NIST SP 800-190, PCI DSS 3.2, and HIPAA standards.  The StackRox Kubernetes Security Platform enables companies to automatically and instantly check for compliance, identify gaps or non-compliance with controls, obtain clear and detailed remediation information, and provide evidence of compliance ahead of audits. 

VMblog:  Companies are constantly having to deal with various industry regulations.  As Kubernetes continues to mature and adoption scales across enterprises, are companies thinking about compliance yet?

Ali Golshan:  Companies adopted containers to increase agility and accelerate application development. The incredibly rapid adoption of Kubernetes shows how critical those containers have become - companies need Kubernetes to scale and manage those container deployments. Now we're seeing the next wave of maturation, with companies realizing they need to both have and demonstrate that they have the necessary controls in place to secure these container and Kubernetes environments. 

As companies move a greater portion of their Kubernetes deployments into production, they fall under increased pressure - both within the business and from outside entities - to adhere to a range of compliance specifications and general industry best practices. Companies that initially adopted containers just to run fast can no longer defer these compliance requirements.

VMblog:  What are the top compliance concerns for Kubernetes and container deployments?

Golshan:  Containers and Kubernetes have changed the infrastructure landscape, so the primary concerns for compliance in these environments center on how to effectively apply the controls and how to provide the evidence of these controls. Many aspects of the container and Kubernetes infrastructure support more inherent controls - being able to specify the capabilities of each image, for example, means a developer can program limitations in behavior directly into the configuration of the software code. 

The infrastructure, then, is able to offer inherent security advantages, but developers have not historically been focused on or deeply knowledgeable about security. So, tying together the security capabilities of the development stack with an understanding of appropriate controls can be challenging.

VMblog:  How do these concerns differ from those associated with compliance in traditional IT environments?

Golshan:  With traditional infrastructure, responsibility for compliance clearly sat with the security and compliance teams. Coders coded, networking people built the network, and security people overlaid the necessary controls to limit what could talk to what. In this new stack, security is part of the code itself, so the security team cannot simply layer in controls in separate infrastructure that they deploy and run - they've got to team with the developers to deploy controls and demonstrate compliance. 

VMblog:  What are the characteristics of Kubernetes and containers that make deployments particularly susceptible to compliance issues?  Are there unique pain points?

Golshan:  Containers and Kubernetes aren't more inherently susceptible to compliance issues - they just change how compliance happens. Think about the need for isolating different business functions - before containers, you could simply put a firewall between certain network segments and know that you could block any traffic not specifically allowed. In the container and Kubernetes world, we're working with a more atomic form of compute - now you need to see and control access between entities such as nodes and namespaces. There's no way to deploy the firewalls the security team is used to using in that environment. So developers and security teams need to work together to define the controls and embed them into the infrastructure itself. 

VMblog:  What specific regulations are top of mind and which industries/businesses are the most impacted?

Golshan:  The most common standards and specifications we see companies eager to comply with are the Center for Internet Security (CIS) benchmarks, the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-190, the Payment Card Industry (PCI) Data Security Standard (DSS), and the Health Insurance Portability and Accountability Act (HIPAA). These specifications impact financial services, retail, and healthcare companies to a large degree. 

Keep in mind, however, that these specifications apply to what's sometimes called "Capital C" Compliance - that is, compliance with a formal specification or standard. Far more companies are concerned with "small c" compliance - that is, adherence to a set of industry or company best practices to deter breaches and protect data. Any company providing its offering via SaaS - software as a service - finds itself needing to enumerate and demonstrate the security controls in place to protect customer data. Often, these companies must be able to prove appropriate security mechanisms are in place before they can win the business of larger customers.

VMblog:  Given the differences between the container/Kubernetes infrastructure and traditional infrastructure, who is taking ownership of compliance in container deployments?  Security?  DevOps?  Both?

Golshan:  Because leveraging the controls available in the infrastructure provides so many advantages, security and DevOps must work together to achieve and demonstrate compliance. Security must understand the controls the developers are applying in the declarative data of images, containers, and Kubernetes. And security must leverage this infrastructure to apply the controls mandated in different specifications. So while security used to be able to do compliance without the help of developers, that's no longer the case in the cloud-native development stack. 

VMblog:  What is unique about StackRox's specific approach to compliance for Kubernetes and containers and what are the benefits of the capabilities being announced?

Golshan:  StackRox has taken a broad approach to compliance, providing a framework and set of capabilities that span a number of specifications and standards. The framework leverages rich context from across the Kubernetes ecosystem to understand the environment, and it taps into the control capabilities inherent in the infrastructure to provide security features. For example, Kubernetes supports network segmentation. StackRox taps into those capabilities to isolate payment card services for the PCI specification, as one example, rather than providing segmentation directly in its own software. This approach ensures that customers have the controls directly in the infrastructure, ensuring portability and consistency across all teams. If the StackRox software itself performed the segmentation, then the DevOps teams would have one perspective on interconnectivity based on Kubernetes and the security team would have a different perspective, based on the controls embedded in the StackRox software. Avoiding this discrepancy is critical to enabling security and DevOps alignment.


Published Thursday, February 28, 2019 7:32 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<February 2019>