Styra Declarative Authorization Service – Paul Foryt, Styra

This is Textron TV. Welcome back to techstrong TV. My name is Sharon Florentine.

I am the managing editor here at Tech strong group. I am thrilled to be here today with Paul for it. He is Cyrus director of product management.

I believe I'm gonna turn it over to him Paul. You want to give a quick introduction to yourself and to styra and then we will jump into some of your news. Great.

Thanks for having me like you mentioned. I'm Paul for IT director of product management and styra. And I focus on infrastructure use cases such as kubernetes terraform and cloud formation, which is what I want to talk about today.

And for those who may not be familiar with styra. We've been Helping users solve authorization problems for the cloud native world for about seven years now and it's what led styra to create open policy agent or Opa general purpose policy engine that uses a declarative policy language called Rego to specify policy as code. And since we've donated Opa to the cncf, it's become the de facto industry standard in authorization and is one of only a handful of cncf graduated projects, and we're really proud of that of that milestone.

So our product styra does declarative authorization service. It serves as a unified Enterprise control plane for Opa. So it helps users manage policy as code across a wide range of infrastructure authorization use cases, like kubernetes terraform and cloudformation.

Application API authorization use cases so things like Envoy istio Kong Kuma Etc. And as well as application and entitlements and today starred as is used in a wide range of company sizes and industries including Finance government energy Healthcare Telecom as well as a bunch of consumer Industries as well. But we see very large adoption, especially in those highly regulated Industries.

Awesome. That was a lot. So when we're talking about styra Das this is one of the broadest policy libraries and tool sets for cloud native infrastructure.

Is that correct? Yeah in January and February we've announced a number of new features for infrastructure policy guardrails. And so some of those things include expanding our kubernetes compliance packs and rules so we can touch on that a little bit later and then we've also expanded our terraform policy Library adding 500 new policy rules for AWS Azure Google and kubernetes terraform providers and then on top of that we also launched a new use case for cloudformation.

So it's currently in a beta state with our Enterprise customers, but we'll be making more announcements about when that will be generated generally available soon. So it seems like styrus found kind of a gap between developers and infrastructure platform teams that this is is going to fill so, how did you go about? Finding that Gap and how does this fill it?

Yeah, so we hear from our customers partners and and even Opa community members that authoring policy for infrastructure. Use cases is difficult. We've approached this in in two ways one is by improving the policy authoring functionality in styrate as itself.

So making it easier to author test manage and audit policies based on your infrastructure authorization decisions. So for kubernetes that's admission reviews because it's running as an admission control opa's running as an admission controller in the cluster for terraform. It's at plan time or at code time so closer to the developer and then the second thing we've done is increased the size of our built-in policy Law Library a lot of Companies have very standard requirements for for infrastructure authorization.

So things like S3 buckets must be encrypted as free buckets shouldn't be public that your database should have logging enabled all of these sorts of things that are basically standards around making sure you have a good Baseline security model and That's where we see customers start first with things like our compliance packs and our policy library rules and then for their specific use cases, that's when they need to expand and author custom policy that is specific to them and only them so we can't offer, you know, built-in rules that that work for every single possible use case, but make it as easy as possible to author policies for those use cases using Rego and opa. Okay makes sense. So then how does this address the security concerns associated with container usage?

Right. So for kubernetes, what we've done is we have a number of compliance packs that help customers get to a good Baseline state for for their policy guardrails. So things like A nist compliance pack or application containers security CIS benchmarks for kubernetes, then more deeper ones like a compliance packs for pcips.

And then recently we released a new compliance pack that is that aligns with the new pod security standards in kubernetes. So since the Pod security policy functionality has been a deprecated in kubernetes. We see users trying to move to using either an admission controller like oppa or for simpler use cases.

They can use the Pod security standards and potted mission that how security admission that's built into kubernetes. But many people they need more advanced control over the policies for their clusters. So that's where Opa comes in and then we build on top of that.

Let's start as by helping you manage your your oppa's deployed in your cluster and also, Simplifying the process of those opa's reporting back and pulling down data from a bundle registry which does hosts and then they also report back the state of the cluster. So that allows us to not only enforce policy and admission, but we can also give users a view of what's already in the cluster that is not compliant with their policies. How does this overall this is a pretty broad question.

We're going from super detailed back out a little bit to like the 60,000 foot view here. I think but how does this impact devops and platform engineering as a whole? It's a great question.

You know and in devops, there's the shift left mindset of having security closer to the the developer. So last year, we released our repository scan code scanning capabilities for kubernetes and terraform. And so all of these announcements that we've had in the past month or so around kubernetes and terraform all so apply to our code scanning capabilities.

So it's about adding more policy enforcement points into the devops cycle. So not just at runtime in the cluster, but you can have PR checks to make sure that the, you know, kubernetes templates that you want to deploy comply with your policy. So that way you don't Wait for your whole cicd pipeline to build due to the deploy.

And then you get the the policy violation. That's a very long process sometimes and depending on the size of your cluster and your pipeline could take 30 plus minutes. You don't want to developer waiting that long to find out that oh, they, you know, Miss the CPU requirements that the company wants for for pods containers and deployments.

So that's been key is is adding more policy enforcement points to meet developers where they are in in the devops cycle. Totally makes sense. Totally makes sense.

And it seems like it. Um, excuse me. It seems like that also addresses some of the process.

stumbling blocks that people encounter when they're trying to Deploy, kubernetes more widely across a distributed system. Right and and where we see. a customers Kind of have that aha moment with with styra Dazz is when you get to a larger scale, so you have more than one cluster or you have clusters with hundreds or thousands of nodes.

And then you have you want to manage your policy in a centralized way across all your clusters. You don't want to have to specify the same policies over and over and over for each cluster for each environment for each team. And that's where does has this concept of systems and stacks to allow you to have teams like a security team that might provide Baseline guardrails.

And then that those are enforced on all clusters and then individual application teams. They can have policy guardrails that are specific to their use cases, but it ensures that the company is always Meeting those Baseline security guard rails. Without having to worry that you know one team has gone off and chosen their their own policy set and they've forgotten some pretty key policies that the company requires.

Yeah. It's it keeps everybody in the same the same path without anybody really going rogue. Exactly.

Yep. All right. Um, great.

Well, I think that does it for me here. Thank you Paul so very much. Is there any last thoughts you want to share with us about the company or this news or?

com. com and for infrastructure authorization and infrastructure policy guardrails. You can find that under the use cases section in our website.

So that's where you'll find terraform and kubernetes since cloudformation is still in beta it you won't find it on the website just yet, but we'll have more on that soon. And then for anyone that's interested in learning more about Opa and Rego. There's the styria academy which you can also access from the styra website, which has a number of video courses to help you.

Learn how to write Rego and how oppa Works in various use cases. So that's that's available for free for for anyone. fantastic Well, thank you so much again for sharing your time and your information here with us always a pleasure to have styra on text wrong TV.

That's it for me. Thank you. Thanks for having me.

Anytime come back and see us again soon.