Securing Kubernetes without Slowing Development

Hello from Styra! This is my first blog since joining Styra as CEO, and today, I’m proud and honored to present Styra at the first ever RSAC Launch Pad event at the RSA Conference in San Francisco. This “Shark Tank” style event means we have just 5 minutes to explain the problems we solve, and preparing for it got me thinking. With Kubernetes now the de-facto standard for container orchestration and management – what does that mean for cyber security?

 Spoiler alert: It means we need clear guardrails to define policy so that our new, fast, modern, ephemeral, portable, you-name-it-able, environments that are exponentially more flexible don’t end up adding exponentially more risk.

Speed… AND Security?

As I said, Kubernetes is now the standard for container orchestration and management. It’s growing at an incredible pace since developers can get it for free for testing and experimentation. It works so well in fact, it’s easier than ever to move from experimentation right into production. However, as we’ve seen with many great open source projects, once workloads make their way into production, security and compliance policy oversight must be implemented.

That’s where the problems start. In the new world of DevOps, where companies are moving to continuously optimize time to market, they recognize they can’t sacrifice security for efficiency. But, they also shouldn’t have to sacrifice efficiency for security either! Hence, security process and controls placed in the DevOps pipeline need to be set at the right points. They also must be beneficial to the overall process and the objectives of all the parties involved – Developers to Operations to Security folks, to the Business itself.

There are three reasons why this is happening (it’s not because there is a lack of understanding or desire to solve the problem).

1. Developers are not security people. Developers are gaining lots of exposure to secure code and best practices, but they cannot be held accountable for writing great code, AND adding great security within their applications, AND keeping the platforms secure.

2. IT Security Teams are currently learning DevOps and Kubernetes. Most traditional IT infrastructure and Operations teams are still coming up to speed on Kubernetes today. It’s new, its origins are open source, and there’s no commercial tooling to help them. Folks using Kubernetes in production today are developing custom policies and constraint logic by writing hundreds of lines of code. This Do-It-Yourself approach is fine for early adopters and companies that have lots of staff, but outside of the early adopters, the mainstream market needs tooling that’s purpose-built for the cloud-native space.

3. Cloud-native applications are truly different. The fact that cloud-native apps are dynamic, ephemeral and immutable means that the scope of securing them is exponentially more complex, and so is the attack surface. Legacy approaches to security don’t scale in this new environment. Think of it this way – How do you scan a workload in runtime, if that workload only exists for microseconds? How do you inspect traffic when new connections can be created in an instant? Where do perimeter defenses go in a multi-cloud or hybrid environment?

These are the problems that Styra is solving. Styra allows an enterprise to set up guardrails for Kubernetes. When a new object is sent to Kubernetes, if the Kubernetes object (e.g. Node) is within the guardrail constraints, Styra will let it go through. If it’s outside, Styra will reject or modify it, so that only the right objects go to the Kubernetes subsystem that’s responsible for production. Styra works the way that Kubernetes works – based on the Desired State principle, but applied to security.

In the traditional enterprise world, we had the concept of Gold Image. I find this is a good analogy for Desired State. It’s defines what’s right, and anything outside of that scope – the infinite permutations of “wrongness” are outside that definition. With the characteristics of cloud-native applications, if the Desired State meets the requirements of IT Risk and Compliance, then there is less risk when the Desired State is in production (called the Actual State).

Styra lets businesses define security guardrails for the Desired State, and then works directly within Kubernetes to enforce that Desired State, and ultimately reduce risk to the enterprise.

That’s the base of our 5 minute pitch to RSAC. Security guardrails for Kubernetes. It’s a rethink of policy for the cloud-native space, so you can move your security from tribal knowledge to policy-as-code.

I can’t wait to talk more about it here, and to share our customer stories with you.

Come by our booth to check out a demo, ask questions, or just say hello!