Transcript

Twain Taylor: Hello everyone. Thank you for joining us for this episode of the Amazic podcast. It's great to have you with us. I'm Dwayne Taylor, editor at Amazic, and we bring you all things cloud native. It's what we love. It's what we are passionate about. And Not just this podcast, but we do a lot more at our website, which is Amazic.com. Go and check it out. We've got articles and job listings and event coverage, a lot of interesting stuff that you'd love there.

And for today's episode, I have with me someone who's familiar. We've had him before this once. But it's been almost a year and so you know, he tipped me off that something big just dropped at his, his startup. And so I thought why not have him over and you know, get him to tell us about it.

So I have with me Alex Olivier. Who is the co founder and chief product officer at CERBOS. Alex, it's great to have you with us again. Welcome back.

Alex Olivier: Hey, good to see you again, Thais. Thank you again for having me. I really enjoyed our discussion last time and everything cloud native. So we're definitely keen to speak to you about the latest and greatest in the authorization space and what we've been up to at CERBOS.

Twain Taylor: Yeah, you guys are really exciting time because you're quite early stage, right? And this is you know, you're probably, you're, It's been open source. You have an open source foundation and now building out your product around this. It's a really exciting phase in the journey for serverless, right?

Tell us about that. 

Alex Olivier: So you're right. We have been around for a few years now. We open sourced our. The core engine of Cerbos, the Cerbos Policy Decision Point, Cerbos PDP. That's an open source project. Go and grab it off GitHub, patch your license. We're a CNCF member as well. And that's really the core engine of CERBOS.

And that's what's being used to this day by companies large and small, ranging from early stage startups through to multi billion dollar publicly listed. Companies are using Cerbos to manage their authorization space. And then what we've been up to for the last good year, really is building out Cerbos Hub which we announced at KubeCon in Europe last year in Amsterdam.

And then we opened up access to anyone that wanted to try it at KubeCon in North America last November in Chicago. So it's been a really busy year for Cerbos and kind of growing the company, both the open source project and the product that sits on top this kind of commercial open source model.

It's been a lot of work, but a lot of fun. And we're really excited to get more users on board and helping them rationalize their authorization in their systems.

Twain Taylor: Yeah. Sounds like a really exciting year for you. Probably kept you really busy. Like you were saying yeah. And And have there been a lot of iterations, a lot of new features getting added along the way, because you had seemed like a gradual rollout.

Have there been a lot of new things added that kind of might have been surprised, might have surprised you at all?

Alex Olivier: Yeah, absolutely. So we've kind of got this sort of two tracks. We have the open source project. Cerbos policy decision point and that's kind of been a constant iteration both by our team here at Cerbos, but also You know any anyone out there and we're very lucky to have a very vibrant and active community around the project so we've had contributions from from users our own teams Lots of discussion and input and both are like github issues for for that but also our slack community so the core of Cerbos has actually been extended and iterated on a fair bit in the last year.

So there's been new capabilities added. I think one to highlight which was really driven by the community. is the concept of policy outputs. So just to kind of recap for our discussion last time, for those that may not have heard it, so Cerbos is an engine that allows you to define your authorization logic as policy rather than the code.

So your policy is defined, here are the default here are the different resource kinds in my application, so users, Expenses, documents, assets, whatever your application models, and then in that policy, which in the serverless open source project is a YAML file, very easy to read, love it or hate it, it's YAML.

You define the different actions that a user can do, or a principal can do upon those resource types, and then under which conditions. So you must have a certain role, or a, for your typical RBAC or role based access control model. But where the power of serverless comes in is writing conditions for attribute based access control.

So a user can edit. A resource only if they are the owner of it, for example, and that's where you have a condition that checks whether the user's ID is equal to the owner ID attribute of the resource. So that was kind of those, those policies gave you kind of a Boolean answer. So this, this actually should be allowed or not.

And while the one of the kind of big discussion points points in the Slack community and, and I've got hub as well, it's like. But what if I need more than just a boolean allow deny? What if I want to provide some context about why an action was either allowed or denied? Because let's say you wanted to present a friendly error message or a friendly sort of prompts to a user based on your policy.

So we added the concept of policy outputs. And again, that was driven by the community kind of worked on collaboratively. So now along with defining whether an action should be allowed or not, you can actually construct an output and that could be a string. It could be. An integer can be whatever you want from JSON, you can define it in your policy.

So when Cerbos gives you an application an answer, either allow or deny, it also brings along that output. And to give you kind of a, a tangible example of that is let's say you want some actions to only be allowed if you've had a two factor authentication, say you're like a bank system, we have a lot of fintech users or servers, let's say you only want to allow a user to make a transfer to another bank account if they've done a second factor authentication in the last 10 minutes, or one of the attributes you have about user is when did they last do their 2FA, So that's a timestamp in your policy.

You can say, okay, this action shouldn't be allowed. That timestamp was in the last 10 minutes. And if it's denied and the answer is denied, you want to actually return back to user saying it's denied because your 2FA is kind of stale and you want your, maybe you want to tell your application to go and send the user off to go and revalidate their session.

So that's the power of using outputs rather than just giving you a binary answer. It actually gives you the context for why an action was either allowed or denied.

Twain Taylor: Wow. Okay. Cool. Yeah. That's like a really good detail actually you know, explanation of what Cerbos hub does and covered a lot of ground in that response.

But I want to kind of break it down a bit and dig into pieces of what you just explained. And I want to just start off with talking about just some of the challenges with doing all of this, the manual way. And the usual way. What are the challenges with authorization? What's, so what's, I'm trying to actually solve?

Alex Olivier: Yeah, absolutely. So every application at the point where you have more than one user or one user role, you're going to have to handle authorization. So just to go back to basics, authentication and authorization are two different concepts. Unfortunately they, they kind of get reduced these days. So just auth Z and even that is a bit confusing.

So authentication is about prompting the user to present a credential and then verifying that credential and you get an identity. So, and you know, your classic login account. And you get back an identity from the GitHub OAuth flow that says, okay, this person is Alex Levieux, this person is Twain Taylor, et cetera.

The second piece is, okay, once you know who a user is, what can they actually do inside of your application? And that's where authorization comes in, Auth Z. And this is the logic that generally is going to be sprinkled across your code base traditionally, and this is certainly where I started. Where you have, like, your request handler and, say, your API.

And you want to make sure that only this particular API route or this particular API action can be called if someone is authenticated and they have the role of manager, let's say. So somewhere in your codebase there's going to be an if statement that says if user. role includes manager, then allow if not return some sort of error.

And for simple apps, simple applications, simple logic, absolutely fine, just going wrong with that. But from kind of my experience and the rest of our team's experience of building these systems at multiple companies from Google, Microsoft, Elastic, you know, all sorts of kind of experience on our team.

That logic is never a simple if statement. There's always going to be a lot of fine grained business logic encoded in it. And I'm sure you can imagine from kind of stuff you've built. How, how hairy and how, how complex that's going to code becomes you end up with a, basically a big ball of mud or spaghetti code, trying to work out what action should be allowed or not.

So Cerbos is an answer to that problem, which is okay. Let's take all that complicated business logic, which is going to be spread out across all sorts of all across your code base and extract it out into a standalone component inside of your stack. And Cerbos is that component is the policy decision point.

And what that now means is your application code. Rather than have to hard code all that logic, which let's say you're a microservices and your services are in different languages. Whenever the business logic changes, you're gonna have to rewrite that logic in n number of languages. Let's say you have in your stack.

Cerbos API. So in your application code, rather than hard coding the logic, you just make an API call out to a Cerbos instance, which For the open source project is a container. So to your service that runs into your stack Cerbos hub, we actually make that a lot easier. We actually generate a web assembly module, which you can essentially embed inside of your application.

You can come onto that later, but ultimately there's a point in your stack now, which is the source of truth for authorization logic. And any part of your application can call, call for that saying, I have this user or principal trying to do this action on this resource, that Cerbos decision point, be it a, the actual container or the Wasm version will evaluate your policies, which you define as that YAML I mentioned earlier, and simply return back and allow or deny with the optional output.

And then your code base is now a simple if statement. If Cerbos says allow. Do the action, if not return some sort of error. So the core problem we're solving here is that complex business logic that's generally scattered across your code base and extracting piece, which is versionable, auditable, testable and, and be verifiable inside of your stack.

Twain Taylor: All right. All right. Yeah. It sounds interesting. And, you know, policies at the heart of it. And you spoke, you mentioned a lot of these things, ideas around policies ABAC particularly. And yeah, it sounds really interesting. But, you know, as you were kind of working on the product, could you kind of shed some light on the journey of getting to.

What, so what's up looks like right now, what are some of the design decisions then that went into you know, making it the way it is today, uh, or in another way what were some of the decisions that you made that said, no, we're not going to do it this way. Even though some people may think this is the right way to do authorization.

Instead, we're going to take this route. And that probably makes what, what is what makes a Wasp Hub unique itself. Could you share some background on that, the whole process of just the product

Alex Olivier: is today? Yeah, absolutely. So. We saw from our usage, a couple of years worth of usage of the open source project, how Cerbos is used as a decision point.

And we've seen this, as I said, from like small startups to massive enterprise businesses are using Cerbos today in production, handling millions and millions and millions of authorization checks a day through Cerbos instances. And so talking to those users and seeing how they've set up and deployed their systems, their pipelines, their architectures to Basically take advantage of the CERBOS we started to come across kind of a few areas where things were a bit let's say more verbose or painful to actually operationalize at scale using CERBOS.

And this is where we started on the journey of CERBOS Hub. It's like how can we essentially give you a suite of tools offering a full kind of ecosystem of support that builds on top of that core model and gives you things that make the operational burden of running a scalable authorization system sort of.

Lessen the burden, as it were, and something that gives you something that's far more scalable and approachable to use. And particularly we're looking at this from the aspect of the people that own authorization in the business is not the developer doing the code. It's going to be that, that product person is going to be the CISO is going to be even in some cases, like the customer team that kind of worry about the authorization side of things.

And these aren't people that are going to be living in the code base. These aren't people that will know Java or Go or Rust or whatever your code base is in. So we wanted to come up with a solution that kind of sits on top of the core, but then gives a collaborative platform and a collaborative environment to have the relevant people inside of a business use authorization.

And the way we kind of look at this is. Authorization should always run inside of your environment. What you don't want to do is have someone like cloud hosted API thing that your application has to call over the internet to make an authorization decision that is going to be bad for performance because unlike authentication.

Which is like a one off task and you get a token that's valid to say 30 minutes Authorization you have to check on every single api call And if you're going to go out over the internet to some cloud hosted api etc to make an authorization check you're going to add n number of milliseconds to every single call which from a architecture perspective is Obviously not recommended.

So, the way we designed and architected and one of the key decisions we made with Cerbos hub is it is a managed control plane that sits on top of the open core. So architecturally, the decision points are still running inside of your cluster or inside of your architecture, inside of your ecosystem, you know, wherever you're running it.

But they connect out to Cerbos hub in order to get their configuration. So Cerbos hub is a managed control plane, but it's not the data plane if you were to use that terminology at all. So we did a lot of work to Get that, that, that synchronization and that, that connection in a way that is scalable is a way that's performant, but most importantly, it doesn't, it's not involved at all in the actual decision making that happens still locally inside of your cluster inside of your environment.

Twain Taylor: Interesting. I like I found it interesting what you spoke about that you know, authorization needs to happen natively. And you know, it can be hosted somewhere in the cloud. And I want to just dig in to ask about what does that mean in terms of. You know, implementation, especially for you, you know, building a product with this idea, what are some of the changes of you know, building Cerbos hub to run natively and you were hinting at even WASM so if you could kind of like on just this whole idea of you know, what this means and how, what are the challenges involved and how you've made it happen.

Alex Olivier: Yeah, absolutely. So keeping the core decision point inside of your network inside your application is kind of the number one design decision we came to. Cerbos hub essentially should be an op is and should always be an optional component that you plug in on top of the open, the open core, the open source decision point.

So from day one, we had to design, okay, how can we. Basically design the apis for this control plane in a way that we can open source those as well So the actual api definitions the actual interfaces that Cerbos hub users communicate to the policy decision points and vice versa Those actual apis are public, you know, they're in the open source repo You can go and look at the protocol definitions And we we we also approach that You know, hopefully we think serverless hub is the best way of doing this, but the APIs you could actually go and build your own control plane if you wanted on top of it, which, you know, some might say is madness.

We think it's just kind of the right thing to do. Particularly as we, you know, we, we very much subscribe to the, the CNCF kind of philosophy that everything should be open. Everything should be extensible. Everything should be you know manageable by yourself. sO getting that API interface, right.

And then essentially open sourcing that. It was something that we took a lot of time over to get right because we needed to make sure it was feature rich enough for the capabilities we wanted to build with Cerbos hub now and in the future. But also make sure it's sort of grokkable and understandable for anyone that did want to go and extend it themselves.

So I would say it's kind of the first, first point. The second piece was like, okay, now we have this management control plane and we have the decision points are running your stack. Like how do we keep those two and seeing how do we reconnect those. So Cerbos itself is running go, um, it's, you know, that Cerbos hub runs in communities or that sort of stuff.

The interface we naturally fell into is that gRPC. So Cerbos hub and the policy decision points speak to each other over a bidirectional stream. So leveraging again, this whole ecosystem of CNCF projects to kind of build out this, this whole ecosystem around Cerbos The actual decision points themselves, they ultimately need to get one thing, which is the policies.

So how do we get the policy files from wherever they are into the decision points and for any sort of scalable or I guess production deployment or service or an application, you're never going to have a single instance of service. You're going to need that high availability. You're going to need multiple instances.

And actually with service going back to that performance piece, you actually want to run around service as close to your application as possible. So the approach we always recommend is a sidecar if you're in Kubernetes. So you literally run a Cerbos instance alongside every application instance that you're running.

That means you now have this synchronization problem. If you have five instances of your app running, you're going to have five instances of Cerbos running. How do you make sure those five instances of Cerbos are running the same version of the policy? And this is one of those operational points that we've heard from users over and over again.

It's like, you know, Cerbos is good, it's working, it does what it says on the tin, but whenever I have to push a policy change out, each instance of Cerbos in my application has to go and fetch this policy separately. So as Cerbos Hub, we flip that on the head. So Cerbos Hub ultimately at Think is Core is a CI ICD pipeline.

And the CD part of that is a, the component which synchronizes the rollout of policy changes. So whenever there's a policy change and you push that to your own repo, which you own and control. Cerbos Hub is connected to that repo gets the web hook from GitHub, let's say, that says, Hey, there's new Commit servers Hub picks up that change runs the ci.

So it'll run any tests that are going on. If all the tests pass, it will then compile a pre optimized and pre compiled version of your policies. So that is a basically a binary representation of your policy files and then notifies all the connected servers, servers, PDP instances that, hey, there's a new version of your policies available.

And then that gets pushed down to all the instances and synchronizes the rollout and change. So what you actually get using Cerbos hub along with serverless policy decision point. is a far more consistent set of policies across your architecture. So whenever there's a new build or your Cerbos hub or your Cerbos instances will get that update and your application dust will serve a consistent authorization decision in regards to how it's deployed and set up.

Twain Taylor: Really cool. Yeah, it sounds very interesting that you spoke about how you implemented it in the CI CD pipeline model. Yeah, that sounds really interesting. Maybe we'll dig into a bit of that later. But for now, I was wondering if you could actually give us a little walkthrough or glimpse of SubOS Hub in action, take the covers off, show us the product itself and

Alex Olivier: what it looks like.

Yeah, absolutely. So let me just share my screen here. So I'm actually going to start off with a diagram. I think for, for sort of anyone that's in this space. You know, we don't like doing slides, et cetera. We like to kind of talk a bit more concrete things, things, how, how things work. And, and you know, again, make sure you get the architecture right in your head is kind of a key one of those.

So architecturally, this is ultimately how server works. Serverless and Cerbos hub works together. So on your left here, you have your end users. So these are in your client applications, be it a mobile app or web app, et cetera. And they're interacting with your API. So requests are going from your client to your API layer.

Your API layer could be essentially anything. Cerbos is agnostic to any particular deployment or architecture. But at some point, you're going to have some service, which is going to handle a particular request that comes in. So that app service, based on the request, really knows two things. Firstly, that request is going to be authenticated, most likely, so you know the user's identity.

Be it, you have a JWT token, or you can go out to an IDP provider, you know, Auth0, Cognito. Super tokens, whatever you're using for authentication, and you can go and fetch back from that IDP, the details about the user, so what team they're in, what roles they're in, what organization they belong to. You might have a di actual directory, like a active directory or an LDAP or those kind of things to get further context.

Second thing, you know, based on that request is what resource that user's trying to access. So they're trying to view a report, they're trying to edit a p invoice, they're trying to export a purchase order, let's say. Again, that's all kind of business specific but your application database obviously stores that information about the resources.

So you can go and query your database to go and fetch that particular resource. Now at that point, going back to what I was saying earlier, traditionally you would write a massive if else case switch star statement to work out whether an action should be allowed or not. Using CERBOS, instead you run and deploy a CERBOS policy decision point alongside your application.

So in your app service, you now make an API call out. Either directly or via one of our SDKs and you send a request to that local instance running alongside your application saying got this principle because it could be a user, it could be a API service account, for example, trying to do this action on this particular resource.

These CERBOS policy decision point instances will then have them loaded into the policy and those policies will be evaluated. It will then create a log. So every policy decision point you set up where you want to send the logs to, you know, standard out to be picked up by your log collection system is a good example of typically where they go.

We have support for other backends, Kafka being one that was added by the community recently. And it will create a log entry that says at this time this user tried to do this action on this resource and it was either allowed or denied by this particular policy. So then what comes back to your application is either an allow or deny decision if you're simply asking for what we call a check permissions, or you get what we call a query plan.

So CERBOS has a kind of a unique capability, which is what we call kind of the sorting or the listing or the index problem. So one of the issues when you decouple authorization logic out into a standalone service is how do you filter your database results based on permissions when the permission is going to be dynamic based on policy.

So what CERBOS has is something called a plan resources or a query planner capability, where you can say to CERBOS, I have this user trying to do this action on this kind of resource. So what happens inside of the policy engine is rather than it returning a Boolean, it works out which conditions need to be met for that particular action to be allowed by this particular user.

So what you now get back is the smallest set of conditions possible for you to apply to your data fetching logic to return just the records from your database, let's say, that that user that those conditions would need to be met for that action to be allowed. So what that gives you is essentially a WHERE clause that you pass into your SQL query or whatever you're using which is dynamic based on your policies.

And thus what the query you can then run will return just the records that user would have access, that have that permission to access. So that's kind of the set, the two types of response you get from Service. And that's all part of the core open source project. If you just need that. Go and use it, go and use service policy decision point, the open source project.

You never need to talk to us. Where Cerbos hub comes in is that layer on top of it, the management control plane. So in this environment, we try and represent by these boxes, at least that you have a cluster, you have replicas. You know, you might have some on prem, you might have some cloud, you might have some edge compute, et cetera which now means you have to do authorization in lots of different places, be it it's just a replica or actually maybe you're in a completely different environment, but you need to make sure the permission checks are the same and that's where Cerbos hub comes in.

So Cerbos hub primarily is this control plane. You connect Cerbos hub to your policy store. So a GitHub repo being the most kind of common and most obvious one and the one that's supported today. So you'd have a repo that again, you own and control. This is. This is yours. You should keep it. You should keep it safe.

You should exist in your org. We're not forcing you to use any other storage. You authenticate Cerbos Hub to your GitHub repo via GitHub app we have. And now Cerbos Hub is basically wired up to run a CI pipeline whenever there's a commit to, to your repo. So the core Cerbos hub is, it gets that commit hook, commits the change surplus hub rhythm runs the tests.

It creates an optimized format binary and then it. If the tests pass and if the conditions are met, it will then go and push out that change to all the serverless instances, regardless of where they are running. So it could be in a Kubernetes cluster, it could be some edge somewhere, it could be in your, it could be in your you know, on prem, doesn't really matter as long as they're all connected, or as long as your Cerbos hub instances are connected to the policy decision points.

Those real time updates are going to flow through and keep everything in sync. The, the kind of benefits here are everything's now in sync, but we also think inside of Cerbos Hub gives you this kind of collaborative environment. So you can actually work and iterate and evolve your policies in an interactive playground, which I'll show you in a second which is a fully sort of collaborative IDE that you can use to manage and evolve your policies.

So that's the core of Cerbos hub. So you may be wondering what this other line is, and this lovely WebAssembly logo, which I promise is not us just jumping on the hype of WebAssembly. Amazing technology. But for serverless, we actually have, there's a real kind of use case for authorization for using Wasm and WebAssembly technologies.

So as part of the CI pipeline, Cerbos hub also produces a secondary output, as well as the policies that go to your containers, into the instances running in your architecture. Cerbos hub also generates a Wasm module. Of your policy logic. So there's essentially a second runtime for evaluating on serverless policies.

One is the PDP service that's running in your stack. The second one is this Wasm module. So Cerbos hub again, runs a test, makes sure your policy is valid, and then also produces a Wasm module, which we then push out to a CDN. And what that now means is you can start putting your policy files and essentially embed the authorization logic into an edge function or pull even directly onto the client via web browser, mobile app, et cetera.

And there's a whole group of authorization checks that we kind of call like presentational or UI type authorization logic, which you don't need to require a full round trip to a back end and such to do. Classic example is let's say you're like showing a user a form to edit some resource. And that user's, what they're allowed to do to that resource is varied based on your policies.

So you, maybe you want to show or hide fields or disable or enable buttons or show or hide menu items based on the resource. At that point, the resource is actually already loaded into the client because you pulled it back from your API. You've done the server side check to make sure that user can access that resource.

So the content, basically the JSON blob or whatever, is now back on the client. But now you actually want to conditionally render components on the page. That doesn't really necessarily necessitate a call back to your backend to then call Cerbos and then for that full round trip. So what you can do is then, using the exact same SDKs, rather than hitting a server side PDP version of Cerbos, you pull in that WESN module.

And then all the evaluation is done on device or at edge and sample in an edge function So it's going to be super fast because it's essentially all local on the edge and you're getting the exact same response format response type Into your application. So those show and hide logic that's allowed denies will happen directly on device far more snappy save the load on your back end and but the key thing here is the policies are always synchronized with what the policies are that are running in your back end as well Because Cerbos hub is managing that ci for you and then coordinating the rollout and the push out Of both the decision points running in your back end as well as pushing out the update to the wasm module That's sitting on a cdn.

So your clients can then pull that in and start Authorizing with the latest and greatest version of your policies. And so it's consistent everywhere. And wasm is the technology that really allows it because wasm, you can run basically anywhere these days.

Twain Taylor: Okay. Okay. Very cool. Sounds like there's a big focus on just performance especially you're talking about how you know, it seems that this, this metadata kind of thing that you you have something indexed where, you know, policies are kind of abstracted.

And I like what you spoke about where you know, Cerbos hub looks for the bare minimum policies that need to be met for someone to have access to a resource. That was really interesting. And I think those kinds of things are what really add up to making performance really, you know, low latency and field time.

And no matter where it is like you were mentioning, even On the edge, it could be on a device and, you know, still need that performance. And these are the kinds of things that really make that possible, wouldn't you say?

Alex Olivier: Yeah, absolutely. So performance is the heart of every decision we make. With, with Cerbos because we are aware both from hard experiences learned from, from at scale systems, you know, my, my background is managing systems that did tens of billions of requests a day through them.

And there's certain architectural patterns that just break at that scale, particularly if you're trying to store state and cash things at the edge and those sort of things, they, they will fall down. It's a matter of when, not if we're at that kind of. Scale and all the fun of essential consistency, et cetera.

So we've taken those lessons and we've applied it for how we built both serverless and Cerbos hub for this performance piece, because authorization is going to be, and has to be in the blocking path of every single request that your application is handling. So serverless itself needs to be as.

Formant as possible and it's not just us making sure our code is like built sensibly But our decisions in terms of using things like a grpc api than http Is the way we've Cerbos is completely stateless So all the context about what your authorization authorizing is provided in the request thus Cerbos itself doesn't need to maintain state It doesn't have its own data store or anything like that.

Thus, you can actually have multiple and many, many, many versions of serverless running inside of your stack. Hence, you can use like the sidecar model. And that way, the network time between your application and getting your authorization decision is minimal to none, depending on how you deploy it. And then with the Wasm piece as well, removing unnecessary network time completely.

So actually pulling it, the policies directly onto device or into an edge function and those kind of things via a Wasm module. Removes the whole need for that as well for those use cases So again, it's all about performance because we're just super focused on where, where authorization needs to be done.

Twain Taylor: And, you know, another piece that was, I think, really short stood out in your explanation and the architecture diagram was just enabling collaboration and the two way sync that you mentioned And just making this even possible you know, no matter where your your application or cluster is could you talk a bit about that?

And it seems like the IDE has something to do with it. And you're mentioning you'll give us a glimpse of the IDE as well.

Alex Olivier: Yeah, absolutely. So one of the things we, we kind of discovered quite early on speaking to users of the open source project is that it, it is always a collaborative journey to have write your authorization logic, because the requirements again, aren't just a Jira ticket is going to be the work of.

The product person responsible for the product is going to work inputs from your CISO, let's say, for security standpoint. You might have inputs from your customer team, you might even have inputs from your sales team around how access should be defined inside of a system. And so what we were generally seeing is there would be a developer, a product person, some other representative or stakeholder in the business, all sitting around Writing policy together, and we always tell users to start out, like just get a spreadsheet, have all your different user roles, have all your different actions, and then start by putting yes, allow or deny in each of the cells.

And then you very quickly realize that actually some of these are not allow or deny, it's allow or deny or allow or deny under certain conditions. And then you end up with basically the matrix of what permission should be. From then, converting that into policy is actually pretty simple, but as we saw, you know, we built.

Cerbos during, you know, the, the, the coronavirus years of everyone remote, et cetera, we are fully remote company is we end up, we were seeing lots of users just like screen sharing their IDEs and running tests, et cetera. It's like, well, how can we make this a bit easier to do? And with Cerbos Hub, we have a fully collaborative IDE environment, which I can pull up an example of, uh, in a second.

And basically this is a IDE environment, which. Is collaborative in the sense that it's, you know, a la Google Docs where you, you know, multiple users working together on policies and the serveCerbosrless hub playground uh, is exactly this. So you get a very familiar kind of IDE environment, if you know, VS code, et cetera.

All of your policies, and these are pulling your policies from your get repo, or you can create files directly in here. And as well as giving you your very standard code editor with all the things you expect in terms of autocomplete and snippets and such, you also get a value add kind of capabilities.

So as well as just giving you an IDE that gives you your policy files and having multiple users in it. So if I, for example, put up a second window off screen here. And I go into the same file. This highlighting stuff is very much like, you know, your Google Docs style experience. You can see the different users inside of a file, etc.

And we also give you this, this side panel here, which will be kind of cool, the explore panel. So as you're writing policies inside of this IDE and this side of this playground, we're also evaluating those policies based on given inputs. So as well as writing your policy logic, you can define your tests.

So and you write fixtures for those tests. So here are my reference principles. Here are my reference resources and then Cerbos hub as you're editing things in your playground here is actually evaluating those policies So if I go and look at different resources from my fixtures, hopefully below you can see as I click between these We're actually getting different answers, different results, different decisions.

So this is the tooling that has you as you're collaboratively working on your policies, see the impact of those changes you're working on in real time. So I can go and change these policy files and actually make this a deny. Now, firstly, I'm going to make a typo and say, Oh, and you get that feedback that you're kind of used to of like, okay, what's wrong with my file.

You get IntelliSense, all the fun stuff you're kind of used to as well. And then once you do actually make those changes, we're constantly really evaluating those inputs and giving your different actions. And the second piece we're doing is running the tests so as well as defining your reference fixtures, you're going to write your tests with your actual and expected values of Whether an action should be allowed or not And then we're evaluating running those tests as you're writing and then you can go in as you update your tests and such So what we were seeing and the kind of journey we saw so with users during our Sort of a development of this is where you would have generally a developer to work on the policies.

You might have that product person sitting on or looking over the shoulder and as your clarity working on things getting that feedback and really understanding what's going on. And then it's a very natural progression. Once you've got your policies, your tests to then push into a CI pipeline. And then with Cerbos hub, that's where the build piece comes in.

So as every time you push a commit, we're running the pipeline. If for example, the tests fail. We give you the output of what kind of why the test failed, etc You can drill down into that exactly what's going on. You can jump straight to the github commit and that is both for the service version So the container version but also the embedded version So that was a module Cerbos hub is running through the pipeline And then when your decision points are actually out there, we give you essentially the snippets to go and integrate it into your environments.

This is an example of how you go and integrate the wasm version Into a javascript framework. So you install a package you point out the euro we give you and now The application or the edge function or that client is always going to get the latest version of your policies So it's a complete ecosystem of tooling from collaborative policy editing through to Manage, build, test, deploy and then giving you the, the steps to go and actually run the decision points inside of your environment or inside of it as a module.

And then we'll give you the feedback as well in terms of which instances are running, how many which version they're on, which version of the policies are deployed, et cetera. So it gives you the insight piece at the end also. So again, it's like a complete end to end way of managing and scaling your authorization logic on top, built on top of the open source service project.

Wow.

Twain Taylor: Really cool. Yeah. I think it's really cool. And great analogy of Google Docs as well, something we all use every day. And yeah, I think really amazing that you are taking some of those concepts and applied it here to Cerbos hub. I want to ask about just Like if the, what about, you know talking about just how authorization decisions are made if, if you try to try to make any of that into the product as well, where, you know, because there's, these are the actual policies but how these policies get defined itself, you know, there's this whole discussions behind those policies everywhere, all over the place in person and JIRA tickets and Okay.

What else? Any, any efforts or any thoughts on that? You know how do you capture the sort of Decision process behind these policies and how they get framed anywhere to write notes or comments or even have discussions on Particular policies anything on that thought.

Alex Olivier: Yeah So this is always one of those challenges where you're kind of essentially building like a workflow tool.

It's like how do you integrate into users existing ways of working because we could go and build a whole You know, JIRA type tool or a linear or whatever into Cerbos hub. But then what's the incentive to go and use that over your existing tools if you already have a process and particularly For someone authorization that does touch so many different parts of a business and so many Different parts of an organization with various different stakeholders.

Yeah, you really don't have to pull people out their existing tools existing workflows So the way we kind of approach it Anyone that goes and uses Cerbos hub, we kind of point them in the direction of sort of best practices But we're not forcing you into any particular way of working Until the point where you're actually taking your business logic and turning it to policy And that's why we did invest in doing things like the collaborative editing The actual id environment the playground environment because that's the point where You will be out of your existing, you know, Jira, Asana, linear, whatever you're using and it's actual implementation mode.

And then that's where it kind of makes sense to give you an environment that goes beyond just giving you a code editor, but also enriches it with the tooling that you saw where we run the tests. We give you that real time feedback, et cetera. So there's a, we decided not to go down the route of like building a sort of a Trello, Asana linear type capability, like go and use your existing thing.

Where it does plug in though is because Cerbos hub. Keeps your policies in your existing github repo your workflow in terms of how you manage and do prs Etc in your development team doesn't change because it's just another repo in your existing github organization So we integrate at that point.

And that way you're not, you know locked in to Cerbos Hub at any point. We even went to the point of setting up such that if you wanted to rip out Cerbos hub because you're fed up with it for, you know, whatever reason, hopefully you'd talk to us first rather than doing that. It's just a one line config change in your serverless policy decision points to just pull the policy files directly from your GitHub and bypass serverless hub.

So the onboarding and offboarding is both. As seamless as possible, it's literally a config change to go from Cerbos pdp pulling from github to pulling in from Cerbos hub or vice versa. So again, it's about no lock in, it's about making sure that we fit your existing workflows, and it's about making sure that You are working in a much more scalable way than having to build everything yourself when really you should be focusing on building your actual application.

Twain Taylor: Yeah, and as we're winding down, I want to touch on this topic of the CICD pipeline that you mentioned, kind of also has just ideas around GitOps and using just. Is updating them, which is already part of your workflow. And I wanna ask about, you know rollbacks, you know I'm sure that you know, it, it, it's, it's really simple for you to roll back to a previous state in any of your policies.

Could you talk a bit about that? How easy is that and how, how does that work? And yeah, just anything as we, as we wind down on just GI tops model, the ci cd model, how that makes all of this possible.

Alex Olivier: Yeah, so Cerbos Hub is designed as GitOps, ultimately. GitHub is, your Git repo is your source of truth for your authorization policies.

That should always be the case. And it shouldn't be some random cloud service that you're provided to that holds your truth. You should own and control everything that goes on. So Cerbos Hub is the CI layer, CI CD layer that sits on top of that source of truth. And it's triggered by any changes to the underlying repository.

And then the way we've, we've added on top of that is rather than every commit going straight out to production or whatever environment you want, you know, so you don't want that is we have the concept of deployment labels inside of server side. So a deployment label is a configuration file that sits alongside your policies inside of your, again, your Git repo.

It's now the YAML file. But this time it defines a pointers ultimately. So you can create as many labels as you want. You might have one for production. You might have one for latest. You might have one for dead. You might have one for stage. You might have one for some feature branch. And then you define to which GitHub which Git commit, which Git branch or which Git tab tag that that label points to.

So that is a dynamic mapping and you can update that and change that as you wish. And what Cerbos hub then does is when a commit comes in, it works out which label, if that bill passes, it point points to that particular commit or that reference. And then when you deploy the decision points in your stack, be it the service, the container or the wisen point you, you define which label that decision points you receive policies for.

So in the case where you wanted to have your production environment that maybe is a tag, let's say. You like a tag, a commit, and like, this is your production deploy or a branch. Even your label file, your mapping file would say, okay, the lab, the, the, the Cerbos hub label production points to the tag production or the branch production.

So only when CI passes and those labels match, those references match, do the policy changes get pushed out to those particular environments. So you could run. Production staging dev local edge, whatever your different environments and all you need to do is in your configuration file for your decision points Just tell it which label for it to look out for and which label for it to subscribe changes to so Rolling back and those kind of things It's just another commit to your repo that you're used to And then all the connected all the registered decision points will receive the updates as and when and need be kind of as you're used to And that label file is just another asset in your Git repo does itself is versionable.

And that's kind of evolve and change and go with the whole GitOps philosophy.

Twain Taylor: Oh, really cool deployment labels. I think, yeah, there's one more example of just how use metadata and abstract all of that complexity and just make it more usable. Yeah, really interesting. So for, for people who are listening to this.

And you want to get started using Cerbos Hub, how would you recommend they get started?

Alex Olivier: Yeah, absolutely. So we always say recommend just the best way to get started is go and try out the playground So you can get started just go to serverless. dev and there'll be a link in the description of this episode as well I'm sure and then that will take you through directly into Cerbos hub Where do you land on the land on the Cerbos hub same page?

The very first thing we prompt you with is hey Go and open up this existing sort of reference demo playground that we have And that playground has some example policies loaded into it and you can start iterating and evolving those to match your requirements Until you get to something and that is a bit more aligned with what your requirements are and if you manage them all your requirements great You can go to the next step which is going actually create a whole workspace which sets up the ci pipeline Connects to a git repo that you have etc But the best place to start is just go straight into a playground and start playing with it, ultimately, and try and model your, your authorization requirements using serverless policies.

All right. So

Twain Taylor: there you have it, folks, fresh off the oven. We've got go ahead and check it out. I think it's really cool the way that. Alex presented it today, and I think it's definitely going to simplify a lot of the issues around authorization. If you had them, it's time to say goodbye to all of them.

So really stands out, I think, in terms of just how it focuses on performance. And how it enables collaboration. I think these two really stood out for me and just how it really blends into your existing workflow as well. If you're already on your journey advancing in cloud native, get off CICD platform engineering you know, then so what's it going to fit right in whether you're getting started, I think if you're more advanced and you've got more complex problems, I think so was it something you should give you should look into.

So thanks so much, Alex. But before you go, got a couple of questions to get to know you a bit more. Don't ask could you name one? Could be a tech company or a tech product, could be a software, could be hardware device, anything at all that you've been using that that inspires you something that you love you being CPO, Chief Product Officer as well.

I'm curious to know what product or products inspire you

Alex Olivier: these days. Yeah, I would say completely away from the world of authorization and just like my own, you know, scratch my own itch or whatever phrase you want to use there, that I'm really interested in is actually the home automation space.

So I spend a lot of time winding my wife up with all sorts of smart stuff inside of our house, say buttons and switches and such, but going with my kind of core philosophy that everything should be open source. I have a massive fan of something called Home Assistant, if you haven't heard of it which is an open source home automation.

System and that you can run on a Raspberry Pi or something inside of your house that connects to your existing smart devices and then kind of how that plugs into the wide awake system of services and APIs and such. And there's now people doing crazy stuff with LLMs where you can have much more interactive discussions and do voice detection and such to basically replace your existing Alexis or Google homes with something that's fully self hosted that you own and control.

Obviously ties in with serverless there. That whole project, that whole ecosystem is amazing and I highly recommend you go and check it out. What's, what's the name again? Home Assistant. Okay, it's open source, is it? It

Twain Taylor: is. All right, all right, cool. What's what's your favorite source for finding out what's new and happening in tech?

Alex Olivier: So if you asked me that a year ago, I'd probably said you know Um, but the one that we, I spend more time looking at is daily. dev. I Have it as my like new tab in my, my browser. So unfortunately every time I open a new tab, I usually get distracted by something. But I don't know what magic they're doing behind with the algorithm and such, but everything it recommends to me is kind of spot on.

And that's sort of one of the places that I go look and also just listen to a lot, a lot of podcasts and such. I would say it's the other one. First

Twain Taylor: thing I haven't thought of this. I'm sorry got a bad throat. I Would ask maybe a last question.

What's the open source project you spent the most time with?

Alex Olivier: Oh, that is a good question. I mean, outside of work, definitely Home Assistant. I think the one I spend the most time with now. We use gRPC a lot with Cerbos and there's a great. Company and open source project out there called buff, build a buff, which buff build which is makes kind of the gRPC ecosystem and the workflow and the developer experience around it much saner that say there may be some of these original gRPC projects.

So definitely worth checking it out. Connect RPC is their kind of implementation of gRPC which we're using extensively inside of CERBOS and I, I kind of look to them and how they approach. How they do their open source, how they do their documentation, et cetera, is a really kind of good standard to aspire to.

It's quite niche. It's quite in the weeds, but it's a really fascinating project and ecosystem they're building there.

Twain Taylor: Well, it's really neat. Yeah. Sounds awesome. Yeah, I'm still recovering from a flu. So yeah, got a sudden uh,

Alex Olivier: there's something horrible going around at the moment. So I hope you feel better.

Twain Taylor: Yeah. Thanks. It was lovely talking to you, Alex, and wish you the best with Cerbos Hub. And hope to have you again after a while when, you know, something big comes by and you guys are up to something cool, definitely come back again and tell us about it. Absolutely. I'd love to. All right.

Thanks all of our viewers and listeners for tuning in, and we will see you on the next one.

Alex Olivier: Bye bye.