Revolutionizing access control with Cerbos | Chris Chinchilla

Unlocking the potential of fine-grained access control

Cerbos is not just another tool in the developer's kit; it's a shift in how access control is implemented and managed across software applications. As Emre and Alex detailed in their interview, Cerbos stands out by empowering developers to map actions to roles easily, manage resources access, and delegate permissions effectively. This capability is crucial for developers seeking to streamline their application's authorization without reinventing the wheel.

Key insights from the interview

A clear distinction between authentication and authorization

Cerbos focuses solely on authorization. This means it operates on the principle of what users can do within an application once their identity is verified. Unlike other systems that try to handle both authentication and authorization, Cerbos provides a specialized layer that ensures precise control over user permissions.

Open source at heart, with commercial scalability

Cerbos is built on an open-core model, offering its base features as open source under the Apache 2 license. This approach encourages adoption and community involvement. For those looking for more, Cerbos Hub adds a management layer on top, facilitating collaboration, CI/CD integration, and policy testing in a more controlled environment.

Deployment flexibility

Whether running in the cloud, on-premises, or even on physical ATM machines, Cerbos offers unparalleled deployment flexibility. Its architecture allows it to integrate seamlessly into diverse environments, from Kubernetes clusters to AWS Lambda functions.

Future-focused development

Looking ahead, Emre and Alex shared exciting plans for Cerbos, including enhancing the user experience for non-developers and leveraging audit logs for security insights. This forward-thinking approach ensures that Cerbos remains at the cutting edge of access control solutions.

Why this interview is a must-watch

The interview with Emre and Alex is packed with valuable insights, not just about Cerbos but also about the philosophy driving its development. It highlights the importance of focusing on core competencies, the benefits of open source, and the future of access control in software applications.

To discover more about how Cerbos can revolutionize your application's access control, visit cerbos.dev. Whether you're a developer eager to implement fine-grained permissions or a business leader looking for scalable access control solutions, Cerbos offers the tools and insights to elevate your application security to the next level.

Don't miss out on the opportunity to hear directly from our founders about the journey, vision, and future of Cerbos.

Transcript

Chris: Hi, I'm Christian back with another interview and demo from a tech startup I have encountered on my travels. This time it is the turn of Cerbos. They have an open source tool and then a commercial product on top that helps developers implement permissions and roles. Let's take a look. I'm joined by Emre and Alex from Cerbos.

Now again I feel like I've been saying this a lot this week. We met at Web Summit and you had a really cool demo that I didn't really manage to capture properly. So I thought we would do it again. And that's what we are here to do. But maybe let's start with a little bit of an introduction to what is Cerbos before we get to that.

Emre: Sure. So first of all, thank you for having us here. Cerbos empowers developers to implement, manage, and delegate fine grained access control in software applications in a fraction of time that it would actually take them to build and maintain it in house. We provide an authorization layer for applications where developers can ultimately map actions to roles and be able to easily manage that.

I'll tell you what Cerbos isn't as well. So that actually clearly distinguishes the developer's mind. Cerbos doesn't do your authentication. Cerbos doesn't do the directory. All of those things happen upstream by another system, like well known ones are, you know, Azure Active Directory, Cognito, Okta, Auth0.

Cerbos is the fact where once you know who the user is and what role they have, for developers to be able to manage, what are the resources that they can actually access and what are the portions they can't. So Cerbos helps with the implementation and enforcement of access control and authorization.

Chris: Okay, just one thing I wanted to check. You have a slight differentiation between open source Cerbos and non open source. So maybe let's quickly clarify the differences between those two as well. 

Emre: Difference it's that one is built on top of another. So Cerbos is an open core, open source product.

So if you're a developer willing to take the core and implement it yourself and run it yourself and, you know, establish all of the pipelines, etc. It's free and available under Apache 2 license. And Cerbos Hub is ultimately a management layer, management interface control plane that sits on top of Cerbos open source and open core.

So as a developer, if you'd like to actually implement Cerbos, it runs in your own environment and it's available under Apache 2. You just download a manifest or download our binary and run it. And if you'd like to actually take advantage of Cerbos Hub. Which is the management layer, all you really do is like one line, two lines of configuration change to point your open source instances to the Hub and Hub is what we're going to demo today to you because that's what what we've recently released and Hub is the management layer that allows you to collaboratively build and test policies and then it was the CICD for those policies to help you may help make deployment very easily as well as building a WebAssembly bundle.

So the same policies can very much so very easily be embedded at the edge. 

Chris: Okay. And if I don't use Hub, where am I running? So it was typically in like a aluster container or something else. 

Emre: Absolutely. So Cerbos runs in your own environment wherever you like to wherever your environment is. If you're running it in a cloud, it runs in your environment in the cloud.

If you're running an on Prem, it runs on Prem. We have customers running it on You know, physical ATM machines, but Cerboss distributed as a binary and wherever you like to run that binary, it's probably we provide a bunch of different ways of deploying it. Typical run times include running it in a Kubernetes Cerbos, Kubernetes sidecar.

We have customers running it in AWS Lambda or just bare metal.

Chris: And just to kind of piece together that final picture of how things connect up. So I have application and infrastructure. I have an authentication Cerbos and then I use serverless in the middle of those to say these users who authenticate with this Cerbos can access these resources. Is that? So if I can, if I 

Emre: can share a diagram from our website, I can very easily take you through that as a high level architecture.

This is Cerbos. as an open source. This is straight out of our website under how it works section. So Cerbos Cerbos runs in your environment. So this is a typical architecture that you would see of an application, right? There's a browser, requests and responses go up to your API. And after your API, once you figure out who the user is and what they're trying to do, your application usually has all of that context.

At that point, whenever an action needs to be checked, whether that user is allowed to do that, your application, using our SDKs and API, would communicate with Cerbos, asking the question, Can this principle do this action on this resource? And Cerbos is a binary, as I mentioned, is running in your own environment, right next to your application, because we want to make sure the latency is as minimal as possible, because this is an authorization check that will be happening on your application.

Every single API interaction with your application. Cerbos looks at it as policies, looks at all of that authorization logic that you've actually extracted out of your code and put it in policy form, evaluates that request and tells you allow or deny. And then your application implements that very simple 

Chris: API.

Policy. You say you define in the application or elsewhere. 

Emre: So the policy where policy comes from is normally traditionally you would have an if then else block on your application. So I'll give you again a great example from our website and normally in. In an application, you would have a logic like this, saying that if the user's email address belongs to my company and they are in a specific region, allow certain things.

These if then else statements, everything starts as a very simple if then else statement in applications. And they start getting more and more complex as you add more departments and more requirements and anything else. And this is, you know, if you have a monolithic application. It's best managed in a library and then you can put all of your logic there and you're done.

But as your application grows and suddenly one monolith starts turning into, I heard this term, I forgot the term, but basically a monolith with a bunch of arms. I didn't talk about it, like when you actually start adding microCerboss. A monolithic octopus? Something like that. A 

Chris: monopus, I don't know. 

Emre: So it's like.

You know, the very first transition is you still have your monolith, but you also start having microCerboss around it until you go into pure microCerbos architecture. This logic now starts getting replicated more and more. And two main problems with this logic when that monolith octopus arms, every time you make a change to that policy, now you have to change this policy in multiple places.

So suddenly, A, that turns into a deployment problem. How do, how do you deploy that all at the same time? And second is, when you have multiple microCerboss or multiple Cerboss, suddenly what happens is, you now need to take this logic or whatever changes you have to this logic, you need to actually translate them into multiple languages and make sure nothing gets lost in translation.

So the API that Cerbos is actually allowing you to do is Taking this logic and putting it in policies, which I'll show you in a second in very simple YAML policies and what they look like. But in return, now you have a very simple API call because now all of that logic, logic check is being done centrally at servers.

Chris: Yeah. 

Emre: Right. So what's turning into is this logic as we were looking at the how it works diagram is now Let me open the open source version first, turning into this policy. So all of that logic is now encoded into a policy, and that policy can be stored anywhere you like, and that policy is still Owned and hosted by you, 

Chris: right?

Okay. Yeah. And I think you were, maybe it was just below the fold on the last page you had. But how, how do you define that policy? Exactly. In open source and Hub, yeah. 

Emre: In both open source and Hub, that policy is I'll tell you, I'll take you to here, our playground. Now I 

Chris: remember you showing me this at Web Summit.

This was actually pretty cool, yeah. 

Emre: So you are defining that policy in YAML, and we have a very simple policy DSL here, where it's very similar in essence, very similar to some, it's somewhere between a Kubernetes manifest and AWS IAM. Yeah. Raws and permissions, but it's a very simple yaml that's human reasonable that has been enhanced with Google's common expression language to be able to express any condition.

So we've actually used Google's common expression language. I'll give you a couple of examples from here. Very simple one. And this is a policy. If you can see is I'll make it less slightly larger. So this is a policy from a finance application from an expense report, right? This policy says an admin can do all of the actions an owner, somebody in the finance team or region manager can view it.

The approver field can be viewed by finance and finance manager. But now, so we can actually go into a little bit of a detail, like an owner of an expense can only update it if the status is open. Once it's been submitted, you don't want them to update something. Or we can do things like a finance manager can approve an expense where if they are not the owner of it and the status is open because you don't want people to approve their own.

Or you can actually talk about that. Different limits amounts that you can actually limit. These are all the different things, but so we didn't Cerbos Hub. We have this collaborative playground where you can actually make changes to each one of these policies and in real time, observe what would happen to permission.

So let's just say, you know, denied to this and let's just. Pick a user that's in the finance team, right? So suddenly did, you know, various different and approve fall approve action as actually changes permissions. So what we have is ability to be able to define each one of these actions. Different users, different, you simulate a bunch of different users in different roles with as well as different types of resources.

You can actually simulate depending on what you know, the different types of resources and ultimately have a playground that's collaborative. Multiple people log in as Google Doc, Google Doc style. You can actually edit these policies. The point is, We actually are composing a policy that will encapsulate all of our business requirements in a very safe environment, where you can, we can also write, you know, tests against this.

We can actually say, oh, hold on a second. Some, you know, some permission has changed. So this, you know, this test is failing. So this is where the. Where the collaboration between a developer and somebody who's only updating the policies comes into place, because as a developer of the system, you can actually set all these boundaries with unit tests and make sure that any policy change is not going to actually break an existing system, existing rule.

But it gives a very safe and guardrailed development environment for all of these policies. 

Chris: And just out of interest, this this test side 

Emre: This is all, this is all part of Cerbos Hub. So we, within Cerbos and Cerbos Hub, we provide this platform where, you know, you can actually start writing your tests.

And everything else and Cerbos Hub is in the background running all these tests all the time. So again, it's a collaborative test are also 

Chris: yaml files. 

Emre: Exactly. Tests are so basically in the test, you define your principles, you know how many different users you're going to have, what role they're going to be.

How many, how many different resources you want to actually have? These are your sample resources. And then at that point, you also build your matrix here, right? You also, you have your fixture of, you know, if Sally for expense, you know, what are the actions? What are the expected results for a given? You know, user and resource combination, so each one every time that policy is updated, all of these tests are running in the background.

So if we actually I'm going to change a test, which is not that kosher, but you know, suddenly you'll see it failing because the policy isn't actually. complying with it. Usually, I mean, the, the the flow of this would be, you know, your fixtures or your tests, sorry, what did I 

Chris: allow. You did this on purpose.

Yeah. Live debugging. 

Emre: Exactly. Expected deny, but actual is allow. Which one is this? Sally expense three, which action deletes. There we go. So all the tests are now passing. So normally you would actually be playing with policies and every time you make a policy change, you want to make sure that everything is correct.

But hold on a second. If we ever, if we ever change this policy limit to be at 30, 000, suddenly one of the rules are actually failing because somebody in the finance team shouldn't be able to do anything above 10, 000. Yeah. 

Chris: Yeah. Okay. So this is part one. Okay, cool, cool. Just just very, very quickly, though, if you are not using Hub, then basically everything is just the yaml files.

Emre: Whether you're using Hub or not, it's always a yaml file. All the policies are yaml files. You can still use the playground that's in the Hub and build your policies and actually export them. If you want to use them with your with your with but now. And. Regardless of you, whether you're using Cerbos Hub or sorry, I'm just going to switch to this how it works diagram because you're going to get a better understands it, whether you're using Cerbos Hub or Cerbos open source.

Somehow you need to feed these policies into your Cerbos instance. In the open source version, you configure each one of these instances to tell them where the policies are stored. Those storage, different storage mechanisms can be a database, your Git repo, a disk, S3, or GCS storage. So each one of those instances themselves.

If you have multiple instances connected, they themselves connect to that source, and you also specify a timeout, a frequency to check for any updates. So let's say a minute, every minute check if there's an update to a policy. We, within the open source environment, we give you a test framework that you can actually use.

We give you GitHub actions, we give you that playground. Ultimately, as a developer, you're in charge of building that CICD pipeline, every time there's a change, running those tests and deploying it to your favorite storage mechanism. And at that point, serverless instances themselves check that source and if they ever detect an update, they download it, they compile it and they hot update themselves.

So from that moment on, they go with the new, new instance. However, in bigger deployments where you have more than one instance. Suddenly, for that one minute of frequency, or whatever the frequency is, your multiple instances might be actually out of sync because depending on when they have been started, et cetera.

So there comes the deployment challenge for, for a bigger system. And this is exactly where Cerbos Hub comes into play, where rather than individual instances connecting to their, to their policies, Cerbos Hub runs the CICD pipeline. Every time there's a change, Detected in the policy Cerbos Hub now automatically compiles that and runs all the tests and once everything is fine Cerbos Hub and now in real time distributes that update to all of your instances at the same time and Cerbos Hub is also capable of, you know, you can tag different types of instances with different environments so you can actually control which environments get the update, which environments not.

So, okay, 

Chris: yeah. Yeah, 

Emre: I'll show you that within Cerbos Hub very quickly. So we have this CERB Finance application. So what we, number one, what we see is number of builds, right? So these are the builds. Every time there's been an update, Cerbos Hub automatically detected that a change and generated a new bundle.

The new builds. So these builds are also you can actually say you can have different tags for each one of your builds so that you can control which build is enrolled out to which environment. More importantly, every time one of those instances launched, they actually registered themselves with Cerbos Hub.

Right? So now you are in control of how many instances are running, what label they are, they have been labeled with, and which bundle they're running, and what version they're in. So, each one of those little Cerbos instances that we were seeing earlier, are now, are all registered with Cerbos Hub. 

Chris: Okay, is this the version of the policy or the version?

Emre: These are the commits. So ultimately we have all of those policies in GitHub. So you can actually see which bundle, what version of the bundle they have. Each one of them are running. Okay. So going back to this how Cervos works. One other thing I'd like to show is so that, you know, what you've seen with Cervosub is.

That all those deployments, you can have different versions running, but one other side artifact of serverless Hub is this WebAssembly bundle. So just like this binary, we also generate a WebAssembly version of that, sorry, just by the serverless binary, we have a WebAssembly bundle. Of that binary, and this is especially handy for environments where a you cannot run a binary and be you would like to actually embedded as a library than anything else.

So what we see is if you're running an environment, your software in the fiber cell, etc. It's very easy to actually embed this, but a very similar situation is. Let's say you're running a React front end and a back end API, and in the React front end, you want to actually make a bunch of permission checks to actually decide whether to render a button or render a section or render a different tab, and the thing, one thing you can do, you can of course make a full request to the back end, figure out the permissions, and Deliver it back, but another easier and faster way of doing that is with the WebAssembly bundle actually running in your front end, you can make all those checks very quickly, render your UI fully knowing that if anything ever goes wrong or somebody gets in the middle, you always have the back end also secured by Cerbos API and Cerbos Cerbos and the bundle are always in sync.

Chris: Yeah, yeah, yeah. Wow. Okay. All right. Is there anything else you want to show or can I ask some more questions? Please. Ask away. Okay. So let's, let's begin first with you have a fair few moving parts here. When did you start on this, on this journey? 

Emre: So we started on Cerbos journey back in March 2021.

Back in 20, so let me correct that. The Cerbos as an idea was started back in 2016. When we were working in our previous company. And when we were rewriting our entire authorization layer for the third time. Asking ourselves, A, B, C, Why are we rewriting this again? B, isn't there something we can actually embed?

And the answer was uh, like, yeah, nothing out there really works for our microCerboss deployment and everything else. And we're better off just writing it ourselves, which took a four, a team of four senior engineers, about three extensible and scalable system. 

Chris: Yeah. 

Emre: And that was the last time we did that.

So during that. We even built a prototype of what Cerbos is today and never implemented it because we were like, Oh, this is going to take, who's going to manage this, who's going to actually improve this, it was baked into our product and back in January 21. We revived this idea. We got great feedback from various different companies that we were design partnering with and March 21, we started as a company and the first open source of Cerbos was rolled out was released in.

August 21 and then CBOs and about 33, ver 31 versions of CBOs. Later, we rolled out CBOs Hub back in November. Mm-Hmm, . 

Chris: Okay. Is it just the two of you or is there more? No, 

Emre: absolutely not. Well, okay. and the founding team is three of us who lived through this. Okay. But today we are 15. We are fully remote, uh, from New Zealand to West Coast of U.

S. and a long way around the world. 

Chris: Okay. And what happened in 2021 that made you want to finally do this in the intervening years? 

Emre: Oh, well, we were, I was looking into, you know, what the next venture to start. And I was looking into, you know, what are the different opportunities and, and, you know, one of the, one of my mentors said, you know, focus on things, you know, focus on the domains, you know, rather than.

Just chase money chase, you know, financial opportunity. And then when I was ruminating through all of the previous pains as a, as a CTO and as a development team, we had to go through this one just stuck out and it stuck out as an. Unaddressed problem, right? Cause when you look into authorization or when you look into a security layer or software, what you see is authentication, authorization, directory, and logs.

Authentication has been addressed by Okta, Auth0, and similar companies. Directory has been addressed since the 1980s or so, starting with Aldap and various other. In three incarnations of that logs have been addressed for a while ago authorization never been addressed because authorization among them is the hardest one to decouple.

Right. Authorization logic is very close to business logic and it's very, it's not very easy and clear how to really separate that. And our very first, you know, very first months, we were very much so focusing on what's going to be our very clear API, like what's the API to authorization where. You know, business logic ends and authorization logic begins.

And that's exactly the API. You know, the very first API we implemented, which is, can this principle do this action to this resource? And then the answer is allow or deny and that everything started with that. And then we built around it.

Chris: I mean, you've gone really in the relatively short space of time, you've gone really heavy on the integrations as well. I guess you kind of have to in this space. A lot of language support. Obviously a lot of the identities as well. So most of the major ones, I think people would. would think about and the deployment models as well.

Yeah. How, I mean, even 15 people is not a massive amount, although you could argue it's possibly a good amount. How did you decide? Which of these things to implement? Was it just like, these are the big players or was it based on what people asked for? 

Emre: So we start with, you know, what's needed in this ecosystem for this to be successful.

Number one, as we integrate with applications. Number one was SDK support, because we want to make sure that although we are decoupling authorization from your main code, we want to make sure that it is as native, as natural as possible to the developers making that call. So that's where we actually started building our SDKs.

And building SDKs were both easy and hard, but relatively easy because of a couple of design decisions we've done. We use, we heavily use. Protobuf and Protobuf as our definition. So everything is typed, et cetera. So a generation of that generation of SDKs were okay. And we very much so focused on, again, SDKs efficiency by using gRPC and various other things.

So there is, there is a commonality across all of these SDKs, but we want to make, we wanted to make sure that all of these SDKs. We're available. So it's the developer. It's natural. Then when, when it comes to you know, looking at integrations with different frameworks or identity providers, at the end of the day, our API is this still the same API.

So these are all examples of how to integrate with different frameworks. So they're not necessarily. Out of the box integration. So if we actually, sorry, if we discount the first three, which I'm going to go into in a second, but with all the other major frameworks, it's a very much so examples of where to best intercept that call, where to best make that authorization decision call, and how to.

you know, how to handle it. The, the first three are actually implementations of our API for different ORMs. Or the examples we have there is, because authorization is not necessarily only at the API time, API request time, checking if somebody can do something or not, but sometimes You have, you know, a billion records in your database, and you want to actually display only the records that a user has edit access to.

Yeah, yeah, yeah. And the absolute worst. Most inefficient way of doing that is fetching all the billion records and checking them one by one or in a batch, which was our initial approach, right? We said we'll come to that problem later, but now Cerbos is fully capable of giving you a list of predicates to apply to your data fetching.

Layer to be able to only fetch those relevant records based on your author based on the user's authorization. And that's when we actually built integration samples with Prisma, SQL Alchemy and Mongoose. Cerbos itself is agnostic to whatever your data searching layer is. Cerbos itself gives you an abstract syntax tree of all the conditions to apply.

Your data fetching. And then, uh, of course, somebody, whoever has is implementing it, they need to implement it in their code. So we actually wanted to give examples that are also very much useful for the most common or M's out there. So that's where we built the. Those, those three, then coming to the authentication again, authentication happens upstream from Cerbos.

Cerbos is capable of consuming the user information, the directory. The, the roles and departments and any additional attributes. So all of these examples actually show how you can get that piece of data and how to integrate it into a Cerbos call. And part of that is, you know, the generic JWT token. And Cerbos is also fully capable.

And we, this we show here, if You don't want to do your manual integration. You can actually just how to provide the job token and how we can actually validate the token and be able to extract values out of it. Yeah. And lastly, 

Chris: you just want to get to these deployment models. I just maybe it's a good opportunity to clarify something just in case people are maybe not completely clear from the conversation is that when we talk about the the, the, The authorization access we see things like Kubernetes, et cetera.

This is all application level resources. It's not like, we're not giving people access to Kubernetes resources or things like that. 

Emre: Exactly. This is, we are very much focusing on, Yeah, above the infrastructure, the application you build and having to handle permissions. And so a very good example of it is like think about whatever application you're building the moment you need to enforce the roles and permissions of users in your application, which.

And I always say if you leave the world to developers, there'd be only one that'd be a super user who can do anything and everybody else couldn't log into a system, but the reality is the moment you're building business software where. There are multiple users and multiple roles and they need to collaborate to get a workflow done and you don't want anybody to step onto each other you want to have proper governance and responsibilities roles and permissions come into play in any workflow and this is to help you enforce those.

Chris: Yeah, and I would think I come from my entry into this world, it was CMS's and CRM's, open source CMS's and CRM's. And of course, everyone at some point builds some kind of authentication option. And probably back in those days, it was extremely basic. Yes. And we've all done it. 

Emre: And that's part of the issue as well, right?

So in a lot of those systems, you have people. You know you have generic three or four permissions and everybody tries to shoehorn somebody in some role into those four and in a Cerbos enables you to be able to break through that mold and where it's very easy to be able to compose a new role with a select.

Actions, right? So even when you think about multi tenant enterprise systems, two tenants, no two tenants are the same. You know, we, we've run an enterprise marketing software, right? We have companies where one company had three people in it and everybody was a mom and pop shop. They had great revenues, et cetera, but there were essentially three people trying to do everything and they didn't want any of these walls on the flip side, we had, you know, 20, 30, 000 people, marketing departments of a global, you know, stationary store where definition of a marketing manager.

And one of the states in the U. S. is completely different than a marketing manager of Germany. So how do you take each one of the actions and be able to define a region specific, not only permissions, but also data access and various other controls? 

Chris: Yeah. Yeah. And by based on region and et cetera, and even just necessity, someone in the States doesn't care about greetings cards for Germany per se.

Absolutely. Okay. It's really, really interesting. The Hub has been out since November. It was a few months ago, I guess you're still sort of, uh, working with that quite a lot and refining it. What's what's next what's in the next six months to 12 months. 

Emre: I'll let Alex answer that because I mean, he's, he's a very patient 

Chris: there.

Alex: Thanks. Yeah. So we are at the stage now where we have kind of users on board and really kind of testing several subs to as extreme as you could say. And what we're really looking at is, okay, we've got developers up and running, they are happy with their systems, they've got serverless Hub manager, the appointments, etc.

But really, when you look at authorization, it's not really developers that are the ones that hold the requirements, it's the product owner, or in some cases, the kind of the security team or basically the person that has that happens out of a business. So whilst we've made this kind of what we think is like a very nice developer experience, we're also aware that these are the kind of other roles, other personas, other role, and departments of our business that are also involved in authorization.

So we're looking at unlocking more of those and bringing more of those into the serverless Hub kind of platform. So the very, one of the things we did early on with the the playground, you saw that kind of IDE environment, it's just really collaborative. So you can actually, we typically see a developer sitting with their product manager or so, Either in the office or fully remote or collaborating policies together And right now it is yaml which at least is understandable, but maybe someone that it doesn't spend a lot of time in code but we have kind of plans like how can we kind of smooth smooth experience and kind of get to a place where Policies can be evolved and maybe not necessarily having to write code.

So that's kind of the first area we're going to and then The other kind of, I think, the secret superpower, you could say, of Cerbos is actually in this audit log that the systems produce. Every decision that goes through the Cerbos containers and the Cerbos policy decision point inside the infrastructure is generated in a log.

At this time, this principal did this action, and those running roles, it was either allowed or denied policy. 

Chris: Yeah, I did 

Alex: see this 

Chris: logs box the whole time. Yeah, we never 

Alex: Exactly, yeah. So that logs every single decision that Cerbos makes generates a log and right now how your Cerbos has been used today in both the open source project and with the Cerbos Hub layer on top is those logs are generally picked up by the infrastructure and sent off to the existing log collection system, which it's great for like maybe developers to use or SRE teams or DevOps, et cetera.

But again, those are tools really targeted at, you could say like maybe power users, maybe vulnerable, kind of more technically mild. But when it comes to authorization, these logs are actually far more powerful and far more kind of useful and needed by the person that holds that kind of security in the business.

So we do lots of interviews and testing and such with kind of CISOs, people that sit in like the security and audit parts of these big businesses, because we have small startups through to billions of enterprises using Cerbos, and the requirements change a lot. And one of the common things we're seeing is like, Access to audit logs, access to really actually understanding how our system is being used, either practically to understand what's going on, or maybe reactively when there's been a suspected security incident and you really want to really nail down exactly what happened, who did what.

These logs are invaluable to that and they're very distinct to application logs. So where we're going with Cerbos Hub is actually using Cerbos Hub as that central point to collect all those logs from all the different decision point deployments that are out there and present those in a unified interface and giving the right tools to these security teams and audit teams to actually access and use these in a, to achieve what they need, which is Yeah, 

Chris: it's so your, your client ticker has been distracting me the whole time because it's sort of scrolling along in the bottom right of my vision.

So um, yeah, you have managed to fill that very unique kind of gap of a, of a technology and a product that everyone knows they have to handle it. Well, not everyone, but a lot of people have to handle at a certain point and generally they just roll their own and you come along and say, well, let us do it for you.

And someone says, actually, that thing we always did on our own was kind of tedious anyway. So, okay, this actually looks quite interesting. So very well done on actually finding. A gap that could still be filled, which is, which is an achievement in itself. And yeah, we've already mentioned there is an open source version.

So if people want to experiment, they can even your managed tier on the free plan is actually. Quite fairly generous. Yes. Yeah, if you want to see what Hub offers without committing too much to begin with. And then I would say even your paid tier is not, it's not, it's not crazy expensive if people do want to experiment properly.

So I highly recommend people take a look at Cerbos. dev. I think when we last met you gave me some cool stickers as well, of this little now what did you say the animal was again? We call him Cerbie. 

Emre: Cerbie. Cerbie. It comes from Cerberus, the dog who, that was, Yeah, of course, yeah. That was, you know, guarding the, And it's, it's quite a scary dog, right?

Three headed dog where we, we all started with what if it was a friendly dog? What would be, what would it be called? And we came up with Surby and then from there, like, Oh, Cerbos and I would love Cerbos because you know, CERB operating system or CERB open source, the OS, there's actually different, different plays on that.

So yeah. 

Chris: It's all come together fairly well. So, yeah. Guys, thank you very much for joining me. And I wish you the best of luck in the next few years. Thank you very much.