 Hi, this is Joho Sapin Bhartyan, behalf of the Linux Foundation. CNC have recently announced the graduation of Open Policy Agent or OPA. To tell more about what is OPA and what does this graduation mean, today we have with us, once again, Torin Sandal, VP of Open Source at Styra, the creators of OPA. Torin, it's great to see you again. Yes, thanks for having me on. I want to first understand from you quickly, what is the importance of Open Policy Agent? What is the criticality of this project for the entire cloud native landscape? Sure, yeah. So we started the project at Styra over five years ago now. And we created the project at Styra because we knew that these modern cloud or cloud native environments were going to require a rethink when it comes to things like policy and authorization. And so Open Policy Agent or OPA, as we like to call it, is essentially a building block that helps people towards that direction of kind of rethinking and empowering themselves when it comes to policy and authorization in modern environments. So it provides a very fundamental building block, which is a way of expressing policy and having it enforced kind of consistently across the stack in their environments, whether you're talking about Kubernetes environments or microservice environments or CI CD pipelines or even applications themselves. OPA basically provides a single, unified way of expressing and enforcing policy. Can you also talk a bit about how different it is to deal with policies in the cloud native world versus the traditional data center space? What we've basically seen over the last 10 years or so is a move to much more dynamic and ephemeral and heterogeneous environments. So in the last 10 years or so, we've seen an explosion in terms of the number of different technologies that any given organization will be leveraging. Every single developer is now empowered to choose a different programming language, a different database, a different execution environment, a different protocol for talking to their dependencies and so on. And so there's just been this tremendous kind of Cambrian explosion of choice when it comes to the technology stack that you're going to use to build your applications. And that applies in basically every part of the stack, whether you're talking about CI CD or microservices or even orchestration systems, databases and on and on it goes. So there's just all these different ways of running software today, of building software. And the challenge is that in the past, each one of those pieces of software would have its own kind of project or product specific way of expressing policy of saying who can do what. And so having 50 or 100 different ways of managing policy and authorization in a large organization, it creates a tremendous challenge. It's fragmentation that makes it very difficult to not only understand what policies you actually have in place to understand your security posture, but also to manage your security posture. Because now if you want to put down end-to-end policies that control who can do what across the stack, you have to go into each and every one of those systems and kind of configure them separately and understand how to configure them separately. And that's a very difficult task for developers, for administrators, for InfoSec and so on. At the same time, we've also seen a shift towards basically distributed systems. Distributed systems have become the norm. And so you can no longer rely on singular, centralized services that run on a specific server and a specific data center in order to control and in order to manage your applications. You need something more that kind of embraces sort of the dynamic distributed nature of modern applications. And so OPA was really designed for these more kind of ephemeral dynamic workloads and environments where you might have applications that are being deployed and updated every hour or serverless applications where they're being updated every few minutes, right? And so there is this need also for something that's supported this kind of ephemerality out of the box. And that's what OPA is really designed to do. It enables a distributed model for policy enforcement. And when we do talk about distributed, how much does hybrid or multi-cloud make it even more complicated? Because you're running your stack on maybe... And today, everybody wants to leverage different clouds, not only there are so many different reasons. So how does that help them maintain it across clouds? Well, I mean, yeah, I mean, that's part of... Open Policy Agent provides a way of unifying policy across a bunch of different environments, right? So whether you're running workloads inside of your own data centers or you're running them inside of Amazon accounts or GCP accounts or Azure accounts, OPA provides you with a single way of expressing policy across all of the workloads in those different environments, right? So this portability story is a very important one. And it's actually one of the important reasons why we ended up donating OPA to the CNCF, because we wanted OPA to have kind of a vendor-neutral home that could serve as sort of a rallying point around policy and authorization. And so by having OPA be part of a body like the Linux Foundation, like the CNCF, it really helps with this portability story of giving people confidence that they're gonna have a piece of technology that they can take and they can apply in all kinds of different environments and different cloud providers with different vendors and so on. It has been graduated, you know, at the CNCF. I have a couple of questions here. Number one is that if you do look at projects like OPA, they're already in production. Companies are already using it. So what does this graduation really mean in real world, not only to the project, but also to the users because a lot of users are already running it in production? What is the value of graduation? Yeah, I mean, so the CNCF, they outline a set of criteria that define what stage a project is at, right? And so the CNCF has different stages, graduation being the final one, being the kind of highest one. And so it's really just, it's really a reflection of the maturity of the project. Like you said, you know, there are already a number of, like a large number of companies that are running OPA at scale in production. That's what's required in order to get to graduation, right? So in order to get the project graduated, we had to go through a process of documenting how it's used, who's contributing to it, that it meets certain technical bars and so on, right? And so the graduation status is really a reflection of the maturity and the readiness of open policy agent for a wide scale to kind of deployment and operational use, right? So from the project's perspective, it's really that kind of reflection of maturity. I think more broadly for the industry, for the cloud native space, it's a reflection of the need for, you know, a solid foundation or a way of doing authorization and policy enforcement within kind of cloud native environments, right? The fact that all these different companies are running OPA for a variety of different use cases, right? It's used within Kubernetes, it's used within CIC systems, it's used with cloud provisioning, it's used in microservice environments for API authorization. It's even being used in the application now. I think that, you know, graduation is really, you know, it's just a further reflection of the fact that this is a need, I think that's necessary, right? It's a must have for modern environments. You have graduated. What is next for OPA? Of course, you have your own roadmap, which is open source, anybody can go and look at it. But from your perspective, what are the things that you are either planning, working on, or some challenges that you still have to resolve, or in general, just summarize what things look like for OPA. The project is kind of stable and widely used. So, you know, one of the things that we're always looking at improving is just kind of the onboarding experience, the getting started experience for new users, right? We want to make it as easy as possible for people to come on board and start leveraging the project for some use case they have in their organization. And we've seen lots of people be tremendously successful doing that in the past, but we want to make it even easier. So we're always kind of focused on that, that initial onboarding experience. Obviously with lots of users running OPA at scale, we run into interesting performance and kind of scale challenges and we're kind of committed to supporting those users and making sure that they continue to be successful as they continue to operationalize OPA and really rely on it more and more in the critical path of their systems. In addition to that, one of the things we did last year was we ran a survey and we asked people, what are you using OPA or what are you most interested in using OPA for? And one of the responses that was most interesting was that a large number is like something like 50% of respondents out of like the 150 organizations that completed the survey said that they were already or they wanted to use OPA around application authorization. So offloading the actual like application authorization decisions to an engine like OPA is tremendously valuable and it's something that a lot of folks are interested in. And so that's where we're spending a lot of our time and energy in terms of feature enhancements and optimizations and other work. So that's something to look out for in the next year is to seeing OPA leveraged higher and higher up in the stack. As you were talking about earlier about graduation that it's already in production, can you give us some example of some of the most exciting use cases of OPA? Sure, yeah. So the two kind of like broad categories of use cases that we see people adopting it for today are authorization, like configuration authorization, right? So use cases like Kubernetes admission control, right? If you go to a KubeCon event, you'll see tons of people talking about how they use OPA to implement different admission control policies using OPA, right? So these are basically allowing platform engineers, Kubernetes operators, administrators to put down guardrails or safeguards in their cluster to prevent really bad things from happening, right? To prevent container images from outside the corporate image or registry from running inside the cluster to prevent developers from like accidentally exposing applications on the public internet or allowing applications to talk out to the public internet, right? You know, a lot of organizations are concerned about data being exfiltrated, right? And Kubernetes is great. It's very powerful. It kind of hands over these tools to developers to empower them and to allow them to kind of self serve. But at the same time, that opens up a lot of ways that people can hurt themselves because now they're in complete control of the compute network and storage resources that make up those applications. You need some way to put kind of safeguards in place. And so we see a lot of people leveraging OPA for that kind of authorization use case of putting safeguards and guardrails over configuration whether it be Kubernetes configuration or Terraform configuration or cloud formation configuration, whatever it may be. So that's one broad category. Another broad category is around microservice API authorization kind of controlling which services can talk to which and which users, which humans can talk to which services, right? So if you're in a large organization, you know, you might be running hundreds or thousands of distinct microservices and you might have all kinds of different ways that people can interact with them, right? You can have services talking to other services. You can have employees talking to those services. You can have contractors. And you need some sane way of unifying policy enforcement across all of that because they're all implemented in different languages. They speak different protocols. There's different ways of identifying obviously humans versus machines. And you want a single way really of capturing that and enforcing it. And so OPA provides that. And so we see that being heavily used today. No, let's talk about the community side of the equation. Of course, the project originated from Chaira, a company, then it became part of CNCF. But if you look at this whole growth, can you talk about what role does community play, open source community play in not only improving the project but also kind of advancing its user base? We knew at the very beginning that in order for this to be successful, we'd have to rely heavily on the community to help guide us especially, right? And so we quickly got something working five years ago and we got it out there and we got people to look at it and try it and talk about their use cases and kind of inform the project direction. And so by engaging with the community that really helped shape the language and shape the use cases where we applied it. And so over time, we're super thankful for everybody in the community. We have a Slack organization. It's got like almost 4,000 people on it. And we're super thankful for all the folks that ask questions and file issues and ask for help and so on because it really helps us kind of like step back and reflect and think about how we can improve things and make things better and more reliable. So the community has been tremendously valuable when it comes to guiding and shaping what the project is today. And over time, we've also seen contributions from the community ramp up considerably. The project, while we started at Styra, it's now actively kind of maintained and contributed to by not only Styra but also Google, Microsoft, VMware and a host of other like individual contributors essentially, that have very specialized area of expertise, especially when it comes to things like integrations. We knew that in order for the project to be successful, the core of it is very kind of general purpose and domain agnostic, but it needs integrations in order for it to do anything useful. And there's a tremendous amount of knowledge and expertise that different people bring when it comes to those integrations. And so that's been absolutely key and that's come from the community. We couldn't have done that on our own as a small group of people. We needed like the community to help us build out these integrations and get them production ready and document them and talk about them to the world, right? You need people to go out there and talk about how they're using the technology in order for other people to see that and come along and help grow it. Awesome. I think now we have everything, anything else that you think that, hey, this is really important, not only from OPAS perspective but also from the cloud native communities perspective or you think we have covered everything in terms of this, I mean, graduation. No, this has been great. I just wanna thank the community again. It's really exciting to see how the project has kind of evolved and mature over the last several years. So a huge thank you to the community, to the CNCF, to anybody that's ever contributed to the project. It's been a great experience and we're really looking forward to where it's heading in the future. Torian, thanks for joining me today for this discussion. I look forward to talk to you again. Thank you. Absolutely. Thank you.