The evolution and future of cloud-native security

With the acquisition of my company, StackRox, by cloud-native technology vendor Red Hat, it seems like a good time to reflect on the state of 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 the new technologies and workflows of today’s cloud and will need to continue evolving them to meet the challenges of tomorrow’s.

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 with a focus 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 out with developers building and running containerized apps on their local machines, Docker containers rapidly found their way into many software environments.

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

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

“The Clair team built it in 2015 to detect vulnerabilities as soon as 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 for 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 Techonlogy (NIST).  A few platforms, like OpenShift and CoreOS, 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 then 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) each varied in their feature set, meaning that security tools would have to play to the lowest common denominator to support all of them.  Where the security functionality they provided wasn’t sufficient for users, a new ecosystem of container security vendors quickly emerged to fill in the gaps and augment the major platforms.  They provided — 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, the foundation for cloud-native security today. Enterprises rapidly increased their adoption of cloud-native technologies and 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 effectively manage security is to align with the system that is managing the applications that need to be protected.

As a result, we started extending security use cases into the Kubernetes infrastructure itself.  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 such as cryptojacking; 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 that 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, as well as requiring all component teams to have a member responsible for 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 small difference between those two 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 backwards compatibility. With Kubernetes-native security, there is also the opportunity to provide all the capabilities that someone needs across the full application lifecycle for many different 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 the same way they manage their infrastructure and workloads. This is what we mean when we refer 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 top of Kubernetes, they too benefit from a Kubernetes-native security approach.  We can also extend our approach 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 on it by participating in the Kubernetes and CNCF security SIGs and following projects like Clair, StackRox, OpenShift, and many others. As you continue on your journey with Kubernetes, you can expect security to continually evolve to meet the demands of your business.

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, which takes place May 4–May 7. For more information or to register for the event, go here.

The post The evolution and future of cloud-native security appeared first on SD Times.

from SD Times https://ift.tt/3aTbksX