Open Sourcing AWS Cedar – Or Weis, Permit.io

This is Techstrong tv. io. And we're talking about an AW Ws decision to open source C, which is a policy as code tool and, or is pretty excited about that or welcome the show.

Uh, thank you Michael. It's a pleasure to be here. All right, Why does this matter, from your perspective, what is it that people should be paying attention to?

Here we have other policy as code tools, not necessarily a new idea. So what's changed? Well, I think, uh, there's a lot of things changing.

Primarily the entire space is changing up till now. This was something that people would have been building completely on their own, and most people still are building this on their own. And, uh, even with the existence of, uh, previous policies, code solutions, people have still built application level access control on their own.

But now AWS is coming in saying specifically this concept of application level access control. It deserves more attention, it deserves more tool, and it deserves more languages. Policy is code languages oriented towards this task.

And so, first of all, AWS being the behemoth that they are coming in with that statement. I think by itself, that's a significant motion in the space, kind of foretelling what's coming up next. And secondly, what's exciting here is the language itself.

So unlike previous languages, uh, they have kind of mostly adhered to being very generic. Uh, a w s have invested a lot in making this language more strict, more structured, more focused on security as a first citizen aspect in the application. Uh, primarily denying things on default and also making it more readable and more easily to analyze.

So it'll become more approachable for not just developers, but all the stakeholders working in the ecosystem. Think product managers, think security and compliance, think analysts. Everyone's involved in being in building access control, and this makes it more approachable to them as well.

That has been one of the criticisms of policy as code, is that the languages that people are presenting with, they're a little on the arcane side. And so the number of people who use them, not surprisingly, is not as high as we might hope. So is that gonna get better now or are we gonna see more policy as code adoption because the language is just that much better?

So I think, yeah, two factors of what I said actually translate into more adoption. So first of all, this becoming available. Is part of the cloud becoming available?

Is part of it aws that is very likely to speed up adoption and even just that message existing out there, I think it will speed up the market education. And secondly, yes, because, uh, this is more readable, uh, developers know that they can bring this onto the table, but still have this available and relevant for the other stakeholders. And I can say this is also expediting what other companies are building.

So for example, with us with Permit, we have a policy editor, a no-code, low-code interface that generates policy for you, writes, basically writes code for you. So up till now, we mostly supported, uh, Rigo the language that is, uh, used for open policy agent opa. Uh, but we've, uh, we were so excited about the motion here with Cedar that we've added support for Cedar as well.

So with permit, it's also easy to write policies code. And with the generated result being in Cedar, it's also easier to read. And I think that pser move together really makes this, uh, highly available for all organizations and all the stakeholders in those organizations.

Do you think other cloud service providers, therefore will adopt cer? I mean, because there's usually a fair amount of not invented here syndrome, or will everybody have their own flavor of a cer? So I think they'll adopt their own policy languages.

Um, Google already has some things that they're using internally within Google. Uh, there's a white paper called Zanzibar that they've released, but they haven't released any source code or any technical details besides the white paper. So Google already has some tools, but they're, uh, have, so far they've avoided sharing them as part of their own cloud offering.

And they also have, uh, their own, um, uh, code execution languages like, uh, G C L, and we're likely to see some form of those tools arrive at that cloud. They might choose to adopt c they might choose to adopt an novel language in addition. Um, but I think it's important to remember that in this developer space, it's all about being polyglot and using the right tool for the right task.

So I wouldn't hold my breath expecting to have one language to rule them all, but I think having a arsenal of languages that we can harness together and mostly have standards and aggregation tools that connect between them, just like, for example, the policy editor that we provide, I think those would, uh, uh, be the glue in between. Uh, but everyone, and I think all the clouds will be gradually deploying these kind of, uh, uh, policies code languages. We've seen a lot of AI advancements lately and a lot of folks talking about writing code using these generative AI tools.

Will this be applied to policy as code? It already is, and I'm, and I'm confident it will expedite it as well. Um, I can tell you that for some of the, um, as we were working on, um, creating parody between what we've created with Rigo and oppa and what we've created with Cedar, I've used the, and we've used our on the team, we have things like chat, G P T and Google Bard to translate some of the code examples from one language to another.

I'm sorry to say that it wasn't a perfect translation, so you can't trust that blindly not yet. Uh, but it can definitely be another way to bridge between these different components. And actually talking about ai, I want to bring in another point here.

AI coming in and being embedded in all of these applications actually creates additional need for policy as code. Cause unlike before, it wasn't just, uh, connecting a human user to your application and deciding what they're allowed to do. Now you need to connect their, their own personal AI agent part of another application as they connect to your application and the AI agent that you've embedded in your application.

I just, I recently got back from Uhcan, uh, Amsterdam, and there almost without exception, every company was tuning, uh, the new Lang large language model or otherwise AI agent that they were embedding into their app. So that's something that's gonna be commonplace and it's gonna make the policies that we need to have for how our applications and the components within them interconnect. It's gonna make them extremely complex.

So without good policy tools, it's gonna be very painful for all of us. So it's, uh, it's really at the nick of time that this category is emerging and maturing. Hmm.

Do you think that security people and compliance people are aware of policy as code tools? And will they make some mandates requiring developers to kind of use them? Or are they a little oblivious to the whole space right now?

I wouldn't say oblivious, but definitely legging behind developers as usually they as us. They do usually, sorry, as they do, usually they're kind of leading the charge. They're adopting the technologies and they're bringing them to the table.

And as a result, the security teams have to work with them or at least be able to, uh, have checks and balances on them. Um, and so you, you are already seeing security teams, uh, adopting or at least adjusting to these tools being in existence, but they're still not leading the charge. They're still not the ones mainly, um, embedding and making use of these tools.

But as they become more commonplace, um, I'm confident the security teams will not only recognize them, but embrace them as the challenges that they need to face would require tools like this. Just as I said As we go along, um, is how does policy as code work its way into a DevOps pipeline? I mean, does it go in at each developer or does it go in as a gate somewhere in the process or both, or, you know, what is the right way to think about implementing this?

That's a terrific question, and it's important to note that policy is code by itself give you the answer to that. You need additional tools and additional best practices. Um, but the key one I'd say that is relevant here is, uh, is GI Ops the idea of managing the code flow flow through a source code control.

Um, and here you can imagine how you have different developers, uh, creating different subsets of the code and merging them into different repositories and going through the different checks and balances, tests, benchmarks, code reviews and other challenges to make sure that that code is consistent and meets the standards of the organization. And then continuing on to C I C D flows. Um, so we already have, so one of, part of the beauty of policy code is the S code part.

Because it's code, we already have best practices on how to manage this, but we still need to build the actual flows and actual tools around this. So that's why with permit, we have created, uh, GI ops con, uh, connection directly into the policy editor. So when you generate code there, it goes directly into your gi and that's why we've created an open source project called Opal that enables policy engines to track changes in policy directly from Git.

So it could quickly become your single source of truth for policy. And that's also why I think why AWS has come in and made this so readable. So it'll be easy to manage and communicate to everyone over something like, uh, a get repository and also why they've created their own service on top of this, uh, Amazon verified permissions, which will become available, i, I assume in, in the next couple of months.

Um, so that service also enables you to create, uh, uh, basically deployment flows from your, uh, uh, planned policies code into the actual infrastructure that in, uh, within force or make decisions with death policies code. One of the things that AWS likes tot about all this is that you can mathematically prove that things are secure. So the people appreciate that.

And who's gonna be asking that question? I think everyone's asking that when you come to a new language that is responsible for something that critical, you need assurances on the performance profile, on the, uh, stability of it, on the, um, correctness of it. How do you know that you've written a policy and it would actually, um, um, deliver the results that you want?

And it's actually a very hard problem to do in computer science. How can you make sure that the program that you've created will actually do what you expected to do? It's part of, it's a subset of the holding problem.

Uh, so that's, uh, is really hard to do. And, uh, and it's something that we as a ecosystem, we are all going to have to tackle and, uh, and, uh, and managed. Um, and I think they've taken AWS specifically, and this is one of the exciting parts, the amount of effort and planning that they've put into this.

They've put a lot of energy into running this in a verified way. So for every little changes, uh, change that they do in the language that they ver, they verifi verify that the behaviors of the language, uh, remain consistent and match the expectations of, uh, the people writing with it. And those additional guarantees and assurances, I think, um, basically remove that or at least reduce part of that burden from the, uh, developers at the end of the chain that just want to have, uh, access control as part of their, uh, product.

Um, so I think, yeah, it's, uh, it's something that all of us need to answer and it's good that, uh, a player like AWS is coming in and taking in their responsibility, uh, to make this mature and available for all of us. What's your best advice to figuring out how to maybe get this into play? Or do I just give it to developers and tell 'em to play with it?

Or is there a more structured approach to go with this? I mean, how do I get everybody engaged? That's also a very good question.

First of all, I'd say don't force it. Uh, if you just say, oh, I, I, this looks cool. I I want to, I wanna play with it, that's okay.

Go play with it in the playground. There's a playground on Cedar's website and you can get a taste of the language. But I wouldn't go about forcing this into your production unless you have an actual need, cuz it will make it very hard to kind of harness everyone around the table to, uh, to get this done in time.

But you don't need to worry cuz with access control, it's just a matter of time. Permissions, I like to say is the gift that keeps on giving. It's just a matter of time before a new requirement would come in, uh, i from your customers, from your security, from your compliance, from your own, uh, developers as, uh, new features are built.

And that would be the ideal time to kind of, um, take this to the next stage and, uh, adopt policy code and adopt solutions around it, like permit and like, uh, uh, al and like, um, um, uh, Cedar Agent. So there's multiple ways to run Cedar, by the way. You can run it just as the plain language.

You can run it as, as part of Amazon verified permissions and you can run it as a, an opensource project that gives you the ability to run this like opa, like a standalone demonn agent called C Agent. So you ha you also have different, uh, tools that you can choose how you gradually adopt this and bring this to the deployment that is relevant for what you've built up till that point. All right.

Well folks, you heard it here. Policy is code is gonna get easier and it may only show up in AWS at first, but at least you can be pretty sure that other people will be looking at this and either deciding to use it or copy it. Hey, or thanks for being on the show.

My pleasure. Thanks for having me. All Right, back to you guys in the studio.