 Hi, this is your something party and we are here at open source summit in Vancouver. And today we have with us Gabriel Eleanor. You are director of developer relations at permit.io. Gabriel, it's great to have you on the show. Yeah, good to be here. Good to be at the conference. We cover permit on regular basis or, you know, audience. They don't know what permit, but what I want to talk to you about, especially here at Diamond, finally AWS, the, you know, open source, you know, cedar. So first of all, just for a lot of folks who don't know what is cedar and what is its importance when it comes to, you know, identity access management. So cedar is a policy language and mostly the first one that designed for application level authorization. So policies code is not new, right? We see the exponential growth of open policy agent with the Rigo language for a couple of years now. But most of the languages used to be for that mission level, which services can go to where and what, what is the authorization level in deployments and machine. And for the last two years, we see a trend coming up together with permit.io to do policies code also in application. Cedar language that's released by AWS show that even the tech giants believe in that idea. And this is what AWS come and say, we want application developer to declare policy instead of just write imperative policy in their software. And what does it, you know, mean for the larger community and also ecosystem that AWS has kind of released a project. AWS also has a cloud product to support cedar called AVP, Amazon Verified Permissions. But as you can see, they decided to release the cedar as an open source, which gives the whole community a chance to create better software Access control is one of the most critical aspects of software, right? We can see in the top 10 of OWASP from the day of the beginning, there is one thing that is always in the top three, broken access control. It was broken authentication and then became broken access control because authentication is already in a good place today. But authorization is still a challenge. And the way that AWS come and say, hey, we don't want to keep it for us, we want to get the community develop much safer and secured application by using our standards, by using our contracts, show how they believe that this is the future of application level authorization. How is it integrated? And what does it mean for permit IO customers? The way that AWS released cedar is a language and a library to get policy decision. This library is actually written on Rust. The product side, right? So policy is not only getting decision, it's also sync data. To get policy decisions, you need data from a lot of resources, your identity management, your billing system, CRM system, external resources, could be anything. And the way that AWS released it, right, show that they are saying, we want to give you the backbone, right? We want to give you the backbone to do what you need with us. And for permit IO is actually a great chance because what permit does in the open source area is the step above the obstruction level of policy engines, right? So there was a lot of policy engines out there. We mentioned open policy agent and now also the cedar engine. But you need a tool that helps you orchestrate everything, that helps you keep in sync the three parts, the data that you get decision based on, the policy that you declare in Git repository, and the enforcement point, the application that needs to get decisions based on. OPAL, open policy administration layer by permit IO, is actually the only tool around, which is an open source tool, that get you deploy policies in scale. And when AWS released cedar, they contact us like month before they release it and say, hey, we see that you are not trying to reinvent the wheel by developing policy languages or develop policy engines. We see that you are winning and excelling in having much better orchestration and administration around policies code. And we want your insight about what we are doing. And then when they decide to release it open source, we said, why not we will just join forces and have a better open source for administration too. So we add and support in cedar language and cedar agent, which is another open source tool that we just released in OPAL, in open policy administration layer. And for the day one, you can get a whole solution for policy as code in application level authorization. What does it mean for other tools? Are you going to prioritize this one? Or it doesn't really matter. You are totally agnostic. OPAL itself by definition. And I'm speaking now not on permit, but the open source of permit, OPAL. OPAL is actually agnostic to the policy engine and to the data that it's get. It's actually a pluggable system. You can plug policy engines and you can plug the many data sources that you want. In our plan, and also people can find it in our GitHub open issues, we are planning to add support in more policy engines. The thing about policy engines and policy languages, they are different with their purpose. So for example, if we look at open policy agent, it started as admission level language, but then shifted left into application level. This is why we based our cloud product now on open policy agent, because this is the wider support. But now we can see also Cedar, which came from the application perspective and the language and the engine is more fit for application. We can see, for example, Google Zanzibar implementations like OpenFGA that is more intent to be on a rebuck relationship based access control. We see a lot of engines out there. We are trying to priority the order of the engine that we will implement in Opal, but if someone from the community fill the need in orchestrate or administrate more policy engine, we invite them to contribute to our open source or the community open source and make Opal excel in more policy engines. When we look at the whole cloud native landscape, one more tool, one more open source tool, it's already a cloud market. The fact is that this complexity is not going to go away. There's just no way it's going to get more and more. What we have to do is to help customers deal with it, to kind of lower the benefit of entry so they can leverage it. So also talk a bit about what does this mean for complexity and once again how to make it easier for users. That's a great question. That's a great question. The thing with cloud native community is the community is the most, let's say, grow community around software. And the reason for that is because every day something new came. As you said, and as a DevTool developers, as there are people who bring tools into that space, we need to think of people as our friend. We try to make them software more simpler. And the way we are thinking of permit, we said shift left is not left, is not end in DevOps developer. We should shift left more. We should make all the deployment, all the CI CD transparent so application will have left to focus only with their application functionality. We can see now that you can create complex application with chat GPT support. So what we are understanding is the more and more shift left, the more developer that will excel in a specific domain, in a specific language and it is not any more technology domain. I don't want developer to be excel in authorization or to be excel in security. I want developer to be excel in what they need to deliver now, what the business value they need to deliver. And the way we see authorization now shifted left, so developer not need to worry anymore about the complexity and they just simplify all the need with low code tools, a tool that can just deploy with one row of deployment script and then use it with no complexity and more bugs in the application as a good way to go. And this is why we believe that the cloud native now that you can see we've been in Kubecon like two weeks ago and we see more and more developer that are not DevOps developer that coming there. You see for example platform engineering. Many people in platform engineering now are not DevOps developer. They are developer authentication system, they develop authorization system and again the reason for that is we are shifting left the simplification of creating complex implications. One more thing I want to ask you before we wrap this up is also when we talk about complexity, complexity also translates into cost and companies are once again becoming more and more cost effective. So how is permit also making that this is not another cost center that once again not just a complexity but helping companies also tame their cost? Again, great question. The thing about cost is fun because if you look today we are deliver much more software than before, right? We all for decades in the area, in the landscape of software development and we see that the amount of the functionality and application that we are developed has exponential growth and in the other end we have more and more developers that work on stuff and also the cloud cost is actually grow and grow and as a DevTools developer I don't want application developer to pay more. I want them to deliver more functionality, right? So if I'm developing an application for developers in my developing DevTools my first set of mind is that I don't want them to give me money. I want them to deliver more functionality and this is actually the key to get back to the previous question is simplicity. The more I'm simplifying the way to deliver better software the more I create way to deliver more functions. More functions equal low cost. Gabriel, thank you so much for taking time out today and of course talk about Cedar Project. Permits you know involvement in the product early on and how you are making it easier and also not easy help with complexity and also cost. So thanks for those insights and as usual I would love to chat with you again soon. Thank you. Thank you. See you soon.