The evolution and future of cloud-native security

by Joseph K. Clark

With the acquisition of my company, StackRox, by cloud-native technology vendor Red Hat, it seems like a good time to reflect on cloud-native security. Security in the cloud has been my life for the past five years, and it’s changed very quickly as new cloud-native platforms have taken over the industry. We’ve had to create new tools and approaches to meet today’s cloud’s latest technologies and workflows and will need to continue evolving them to meet the challenges of tomorrow.

Before we get into the future of cloud-native security, though, let’s look at where we started in the distant past of … seven years ago.

Our industry started focusing on basic security hygiene for containers, which formed the basis for “container security.” While container-related technologies had existed for over a decade, Docker provided the toolset that popularized the Linux container as a standard distribution format for applications, making it widely accessible and adopted. While it started with developers building and running containerized apps on their local machines, Docker containers rapidly found their way into many software environments.

cloud-native security

RELATED CONTENT: 4 reasons the future of cloud-native software is open source

Container image scanning became commonplace, with many options available, including open-source scanners like Clair and OpenSCAP, paid offerings like Black Duck, and ones proprietary to cloud providers. Suddenly, with thousands of applications distributed via Docker Hub, people realized this new, emerging stack area created new security problems. One of the most straightforward to address was preventing vulnerable software from being introduced into production environments.

“The Clair team built it in 2015 to detect vulnerabilities when images were pushed to a registry. By making your container contents more visible, we helped mitigate the distribution of vulnerable applications across servers and workstations. This may sound historical, but many popular public container images are still vulnerable,” remarked Louis Delossantos of the Clair project.

Image scanning was “good enough” for most users since they were still running containers in a limited context, such as non-sensitive web apps, or strictly in development and testing. But then organizations started running containers in production, and everyone had to think about baseline security best practices for the underlying container infrastructure, which led to the Center For Internet Security (CIS) Benchmark for Docker and other tools and guidelines such as those published by the National Institute of Standards and Technology (NIST). Like OpenShift and CoreOS, a few platforms extended this approach with security modules to further lock down the operating system on the underlying nodes.

Generally speaking, this combination of image scanning and secure infrastructure configuration became the new “good enough” for production deployments, partly because there was no standard for container orchestration yet. The major competing orchestration systems  (including Kubernetes, Fleet, Docker Swarm, Marathon, and others) varied in their feature set, meaning that security tools would have to play to the lowest common denominator to support all of them. Their security functionality wasn’t sufficient for us; a new ecosystem of container security vendors quickly emerged to fill in the gaps and augment the powerful platforms. They offered — and continue to provide — solutions for security use cases such as runtime security, compliance, and network segmentation.

Progressing to Kubernetes Security

As Kubernetes became the dominant orchestration platform, container security evolved into Kubernetes security, today’s foundation for cloud-native security. Enterprises rapidly increased their adoption of cloud-native technologies. They matured their usage patterns of containerized applications: running in production, deploying sensitive workloads, scaling to hundreds of nodes, and implementing multi-tenant and multi-cluster scenarios. As a result, it eventually became clear that the only way to manage security effectively is to align with the system controlling the applications that need to be protected.

As a result, we started extending security use cases into the Kubernetes infrastructure. Vulnerability management meant supplementing image scanning with scanning for and fixing vulnerabilities within the Kubernetes control plane and node components. Configuration management evolved to encompass securing Kubernetes configurations rather than just container configurations. CIS released a Kubernetes security benchmark. Security vendors developed threat detection methodologies focused on finding exploits to Kubernetes components like the Dashboard and malicious activity like crypto jacking; Microsoft researchers published a Kubernetes Threat Matrix based on the well-known MITRE ATT&CK framework.  

This shift to Kubernetes security was also reflected in community efforts focused on identifying security issues within and protecting Kubernetes itself. The Cloud Native Computing Foundation performed a security audit of the main Kubernetes components. The Kubernetes community launched SIG-Security, requiring all component teams to have a member responsible for the security and switching the default settings for controls such as Role-Based Access Control (RBAC) in Kubernetes from optional to mandatory.

The Future: Kubernetes-Native Security

The next phase of cloud-native security is already underway, and we are progressing from “Kubernetes security” to “Kubernetes-native security,” as we describe in our whitepaper. The slight difference between those phrases belies a widespread evolution in integration, tooling, and approaches. Kubernetes-native security ensures that security is tightly coupled with the underlying Kubernetes platform (such as OpenShift) and extends security controls by taking advantage of the extensibility of Kubernetes. Features like Custom Resource Definitions (CRDs), created to enable application automation, also allow us to achieve security automation.

A key element of Kubernetes-native security is making the stack “secure by default.” We know that users frequently stick to default configurations, which historically have been left insecure for operational convenience or backward compatibility. With Kubernetes-native security, there is also the opportunity to provide all the capabilities that someone needs across the entire application lifecycle for many common scenarios, whether dev/test or production, single or multi-cluster and public web apps, or ones that process and store sensitive data.  

Aside from integration with native Kubernetes extension points, cloud-native security will also succeed through close integration with DevOps practices and teams, allowing them to manage their security declaratively like they manage their infrastructure and workloads. This is what we mean when referring to the phrase “shift left”: embed and automate security in the workflows that people already use instead of making it an exception. DevOps teams are the new security users we must enable, and our security tooling must be built with them in mind.

“By shifting security left with DevSecOps and leveraging Kubernetes to define security controls as code with a trusted, automated application and deployment pipeline, organizations can achieve highly scalable security and compliance while spending less time remediating and more time innovating,” explained Chris Van Tuin, West Region Chief Solutions Architect, Red Hat.

Newer technologies like serverless platforms and service meshes, like early orchestration, are still more fragmented and, as a result, don’t yet have comprehensive security practices. However, since most of these are built on Kubernetes, they benefit from a Kubernetes-native security approach. We can also extend our policy to cover the new security use cases that arise when they are used.

Cloud-native security continues to evolve and improve rapidly. Since so much of it is open source, you can keep current by participating in the Kubernetes and CNCF security SIGs and following projects like Clair, StackRox, OpenShift, and many others. As you continue your journey with Kubernetes, you can expect security to evolve to meet the demands of your business continually.

To learn more about the transformative nature of cloud-native applications and open-source software, check out KubeCon / CloudNativeCon Europe 2021, a virtual event hosted by the Cloud Native Computing Foundation on May 4–May 7. For more information or to register for the event, go here.

Related Posts