Companies are moving to cloud native development because it speeds up product delivery cycles and innovation. This is an exciting time, as developers can create complex applications, deploy them more quickly at scale, and deliver more value to customers.
But what does this mean for security? Security is challenged by cloud native development because current security methods introduce waste and slow developers down. No one has time to insert security processes or file a ticket for the security team to set something up. All too often, developers spin up new environments and deploy applications while security has no visibility or control.
The good news is that with the use of Kubernetes, we have a new opportunity to operationalize security, empowering developers to deploy security on their own terms. In this blog post, I’ll discuss the current state of cloud native security, and describe how we can use Kubernetes to operationalize security. You can also download the whitepaper Operationalizing Security With Kubernetes that goes into more detail.
Why Security Is Left Behind
Cloud native development enables engineers to more quickly produce and iterate new versions of products, helping companies get ahead of competitors and increase profits. Ease and speed of development are both often higher priority than deploying security measures because the results of secure development may not be as clear or tangible as increased productivity and profits.
We need to empower developers to deploy secure services while the security team stays out of their way
Security vendors have not helped their customers by adapting their approaches to this new world. Security vendors are accustomed to selling into the security organization because in the past, companies had centralized control of acquiring, deploying, and maintaining IT assets and infrastructure. This was possible with homogeneous computing environments with slow rates of change.
This doesn’t exist in the cloud native world; developers can rapidly spin up new containers across different environments. And they don’t want to spend extra time using the traditional security solutions. Provisioning access, running a vulnerability scan, checking configurations – all take time. Filing a ticket to get help from another team – security or operations – interrupts their work.
This is why enterprise security vendors can’t meet the needs of cloud native development. They are looking for a single buyer with authority to push their software across the enterprise. It fails because the central authority and buyer is gone. It has been replaced by the developer, and the developer just wants to code and ship software.
The Current State of Security
When we talk to security leaders at companies, we typically see them falling into one of three tiers for how they are addressing security for cloud native development. In the top tier, there are a handful of elite companies known for reaching new levels of productivity and scale. They have security and operations teams with skilled staff who can cobble a mix of open source and in-house developed tools to ensure availability and security.
But few organizations have access to security and operations teams, or Kubernetes experts. So there is a second tier of companies that may have a roadmap for security projects to secure cloud native workloads, but they may not have the expertise, time, or money to do them. Finally, the third tier of organizations knows it needs to do something to enable cloud native Kubernetes environments, but may not even know where to start.
Organizations shouldn’t have to spend time and resources building custom solutions. It would be better if companies had access to best of breed solutions so they could immediately secure their environments.
Operationalizing Security with Kubernetes
Kubernetes has played an important role in the move to cloud native application development. Designed on the same principles that allow Google to run billions of containers a week without increasing ops teams, Kubernetes automates deployment, scaling, and management of cloud native applications.
Now we have the opportunity to operationalize security by using Kubernetes to provision SaaS security services across clusters, empowering developers to deploy secure code while the security team stays out of their way. Security gets the information they need for visibility, reporting, and compliance, and developers keep shipping software, unimpeded.
More importantly, this gives all companies access to security for their Kubernetes environments.
So what are the components of Operationalized Security? Here are the five requirements:
- Self-serve, developer-deployed services. Developers themselves deploy and consume operationalized security.
- SaaS platform with pay-as-you-go model. This is a change from enterprise security sales, owned by security teams, with software or processes pushed onto the developers to use.
- Fast, easy installation across clusters. Operationalized security is deployed in seconds, and runs seamlessly across clusters.
- Centralized place for identity and security services. Instead of going to multiple vendors or using multiple open source solutions, a standardized menu of services is available.
- Works within existing developer workflows and tools. The developer cannot be interrupted by forcing them out of their normal toolset.
We believe these are the five essential components that companies should consider when evaluating security solutions for Kubernetes. If they do not meet these requirements, we believe they are likely to be rejected by cloud native developers.
You can learn more by downloading our Whitepaper: Operationalizing Security With Kubernetes.