Emre Baran:
The key for us has been always been from day one, be one with the community and showing them that we're actually building this for developers. This product belongs to them, this product has nothing to hide, and what we don't want to do is go and sell. So we shouldn't be convincing anyone to use Cerbos unless they really want to.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I am Eric Anderson. I'm excited to have Emre Baran on the show today. He's one of the leaders of the project Cerbos. Emre, thanks for joining us.

Emre Baran:
Thank you for having me.

Eric Anderson:
And Emre, how would you describe Cerbos to somebody?

Emre Baran:
There's so many ways of explaining, skinning this cat but, ultimately, Cerbos is an open source, scalable authorization layer for your software so you can implement roles and permissions very easily.

Eric Anderson:
I think a lot of us are familiar with an authentication layer. We've used Autho0 or something, and this is the complement that's maybe more deeply part of our application, is that right?

Emre Baran:
Exactly. If we ever go back to 1960s when our fathers were writing software, they were writing every single layer of the software. They were writing the data storage layer, they were writing the communication layer, they were writing everything from business to infrastructure. And as time passed by, things started getting decoupled. Today nobody writes their own database unless you're writing a database software yourself. You take one off the shelf and implement it.
Similarly, when you look at that software infrastructure stack, things like authentication got decoupled, so nobody really does their own database and password look up. Everybody uses one of those vendors. When you look at a database got decoupled, your mem cache, the data cache got decoupled. What we see is a trend in every single layer being decoupled and ultimately we are the natural step right after authentication. Authentication deals with who the user is. Are they who they say they are? And most often it also includes the directory information and sometimes that can be decoupled on its own into an LDAP, an active directory. And once you know who the user is, authorization is the natural next step where you take that information and tie it into your software, who can do what. Cerbos ultimately makes the implementation of roles and permissions very simple by decoupling the authorization logic outside of your core code into its own centrally distributed component.

Eric Anderson:
And I can imagine for people who've done dabbling in software development that initially all the users, maybe of an app, are the same, they're just a user. But as you add features, you inevitably have admins maybe, and then you get into different assets that are created, might have an owner or editors. These are all the things that I would use Cerbos to implement.

Emre Baran:
Absolutely. Software engineers that do not have that many business requirements, the world is very black and white. You actually have an admin user who can do everything, and sometimes you have a read only user who can only do very limited actions. But as requirements come into software, roles and permissions start becoming more and more complex. Initially, a software engineer very simply implements roles and permissions in a very simple if/then else block. You do a lookup into a database table. You figure out somebody's role and in that if/then else you determine what they can do/they can't. And that's absolutely fine when you're building your MVP. And as you pointed out, as the software starts getting more and more complex, you add more requirements, you add more users, you add more components. Suddenly, that if/then else block, you start either making it more complex and/or you start copy-pasting that into all the other components.
And then once you actually go into a microservice environment, potentially you take that and also translate it into other languages. And that's fine until the next requirement change, business requirement comes in, and you have to actually make a change across every single one of those implementations in everything single language, which is a challenge. And it becomes bigger a challenge when you have to actually coordinate the deployment of all those changes you're at throughout your entire stack. With Cerbos, we aim to solve all that for once so software engineers don't have to ever deal with that and they can actually very much so focus on the business domain problems that they're trying to solve.

Eric Anderson:
Clearly, Emre, you've lived this pain, maybe you can tell us how Cerbos came to be, your role in it, and who else brought Cerbos to life.

Emre Baran:
Absolutely. I started Cerbos with my co-founder, Charith, which we have worked together for about eight years in our previous company, where I was the co-founder and CTO of Qubit. We had a marketing technology where all the major retailers were our customers, where we did personalization, A/B testing and merchandising solutions for them, for the e-commerce solutions. And the evolution as I explained it to you, it was very simple. And in the very beginning we had customers and all their users could either be admins or read only, and they said, "This is not enough. We need now editors and publishers and admins and read only people," which was fine. But that took us a good month to implement. And then later on, we signed up global giant retailers where they said, "Oh look, we have 20,000 users. They can't all have the same four roles. We have departments based on geography, we have roles and everything else based on seniority of the employees."
So every single one of these combinations meant they had to have different levels of access. And implementing that was a nightmare. And we cut corners, we implemented absolute minimum as possible because also, at the time, we did not have a dedicated security engineering team. In order to be able to build this layer and make it versatile enough, we had to cobble together different engineers from different groups, built it and then, once we built it, the group disbanded, they went back to their day jobs, which made maintenance or making additional changes to it very hard. That was the most recent experience and, prior to that, I was a Product Manager for many functions of AdSense, at Google. And even when I was a Product Manager for AdSense, this was about six years old or so.
And at the time they had very basic role or attribute based access control. They actually heavily relied on employee contracts saying like, "Hey, don't do that." And it was, again, a challenge of having to go into a system and revamp this access control system once for all. And it was too much of an effort that nobody wanted to tackle. Similarly, I had two other previous experiences where we had to deal with access control and the dealing with it is not the problem. The evolution of it is a problem if you do not have a dedicated engineering team for that infrastructure layer. And on the back of that, after Qubit, me and my co-founder, we decided to tackle this challenge because as we look at the security space in the software infrastructure, we look at authentication, that has been decoupled.
Okta, Auth0, and many other authentication providers do it. When you look at the AAAs, what are they known as historically. Authentication, authorization and accounting or audit. There's also the silent brother in there, which is the directory service that has been decoupled with LDAP years ago. When you look at logs, that has been decoupled, there are a lot of log processing, log storage, processing, but authorization is still the uncoupled piece when you actually look at that spectrum. And we believe with the recent technology changes, with compared going to Kubernetes and various other shifts in the technology, now it's time to be able to decouple authorization logic outside of your code but keep it very close to it.

Eric Anderson:
I can imagine some people thinking that maybe that's hard to decouple it, like your authorization logic is infused throughout the code. There's lots of, as you mentioned, logical statements, as you describe it, and it's really more of a library than it is a service. I'm sure Emre, you face this every day, is that an accurate assessment?

Emre Baran:
Absolutely. You are spot on. It's the hardest among what I mentioned and that's why probably it's the last one. The biggest challenge, when we look at all those other components, the biggest challenge we have is actually of performance. Because authentication, whether you do it in 200 milliseconds, 250 milliseconds, the delay to the user is not that easy to perceive. You click on a button, it says logging you in and logged in. And once you're logged in, you can take that token and cache it, it's valid for 30 minutes, and you can distribute it and validate it locally, anywhere. When you look at the directory, again, you fetch the user's roles and directory information once. You cache it, you use it throughout a session. When you look at the other end of it, when you look at the logs, they're much more of a fire and forget. Once actually a log is generated, you fire it, you send it somewhere, it's stored and eventually it can asynchronously get processed and analyzed.
But authorization is actually something that needs to be done in every API call. Every time somebody clicks on your UI, every time somebody takes an action, every time there's an interaction, you need to go take and fetch new data, or morph data, or do some calculation. Prior to doing that, you have to actually check, can this user actually do this? Does this principle actually have permission to do that? Which makes it very tough from a speed perspective because now authorization check is in the blocking part of every request. You can't be slow. You need to do that as quick as possible because then there's perceived delay on every API call, which sometimes you cannot perceive that in a UI, but if you're processing billion events a day throughout your data pipeline, suddenly that adds up very quickly. And then second part is it needs to live as close as possible to your code and it needs to be as uniform with your code as possible. You cannot have same logic represented differently in other places where there might be actually holes between them.

Eric Anderson:
Going back to the origin story here, so you set out to solve this problem, got the team back together, now you're in a new project, at what point did you decide this would be an open source project?

Emre Baran:
Very, very early on because we were building a product where a default engineer's attitude is, "Oh, I can build that." And they can in a very simple environment. Secondly, we need to show them that this is not just beyond that if/then else statement, this is actually a very complex task. There are very many dark corners that you need to actually take care of it. And we wanted to show them that yes, you can do it given enough time and money, but here's a version that actually takes care of everything else, and look at it, play with it, and feel comfortable with it. And the second part is this needed to be open source because this is a product that lives at the heart of your network, at the heart of your application, its servers are self-hosted. So you actually put this in the heart of your environment. The very natural question is, "How secure is this? Hold on a second, I'm putting something in the heart of my network, it's going to process requests, what else is this going to do?" So we needed to get over those two hurdles very quickly and that was when we actually decided to make it open source to give comfort to the developers who might be actually using it.

Eric Anderson:
And there's been a couple attempts at this of late, and one of the debates is whether you create your own language to describe these kind of policies, where did you come out on the need for new language?

Emre Baran:
It's a very valid point and, actually, when we were building Cerbos, our very first hypothesis was Cerbos has to be very simple to implement by the users. And what that meant was let's not require all the developers to learn a whole new programming language in order to be able to program their policies. When we built Cerbos, our very original premise was let's turn this into a very simple configuration that is stateless that every time somebody looks at it, it's the same thing. That actually enables 99% of the developers very easily ... That they can look at documentation and implement it very simply. So we started with a YAML (love-it-or-hate-it) configuration that can also be represented in JSON, but we found that we could actually put almost 99% of the requirements into this spec, that Cerbos decision points can actually take, compute and return. And the key thing in there when we were designing Cerbos, it was an architectural decision, which was actually every Cerbos instance is stateless. You can spin it up for one request and throw it away, and everything you need is in the request. Everything [inaudible 00:13:36] as a data point and everything you need to make a decision is actually already in the policy that you have written.

Eric Anderson:
Got it. So maybe give me a feel for what it's like to implement Cerbos. I'm developing an app in the language of choice, JavaScript or something, and you give me some kind of SDK where I can say, "I'm now making a call to a user," or, "A user needs to do something and I need to check with Cerbos first."

Emre Baran:
The process is very simple from a perspective of, first of all, just like every other product, you need to define your requirements. What are the requirements do I have? Well, what does a role of a user mean in your application? What does an approver mean? What does an owner mean? You very easily define that in our YAML specification. For every advanced case, actually, our YAML configuration also incorporates Google's common expression language, so you can actually do all sorts of computations, and you can very easily try that On our website. On our website we have a playground where you can actually compose your policy, you can mock a bunch of different users, and validate your policies, and you can even write unit tests against them so that you know that every time you make a change, you're not breaking anything. Once we actually come up with your policies, the implementation is you deploy a Cerbos instance in your environment.
It can be as a Kubernetes service, it can be a Kubernetes sidecar, it can be deployed on a VM as on bare metal as a binary, we compile a bunch of libraries. You can also implement it as an AWS Lambda function. And what you do is you then connect your instance to your policy, which can be hosted on GitHub, we support all sorts of GitHub actions and CI/CD GitHubs on top of all that. And once Cerbos' instance is up and running, which is literally three lines of code, you then have your SDK. We have SDKs in every major language, and you implement Cerbos checks from anywhere in your code. The question that you ask at any given time, "Can this user do this action on this resource?" You go to the service API by using the SDK, Cerbos gives you a very simple yes or no answer. So as a developer then all you do is implement that response. In case of yes do this, in case of no do that. And from that moment on all of that logic is now on the YAML file. Whether you do it, whether a product owner does it, or somebody else does it, you can actually independently change the policy than your code. Your code can stay the same as long as you're not changing your input data points.

Eric Anderson:
Which I guess means that if a product manager, if somebody else needs to add a policy, a kind of user type, they don't need to ask the engineering team to make a change. They don't need to wait for a software push.

Emre Baran:
Absolutely. And our aim here, this is actually one of the things that we are working right now we're releasing very soon, is a control plane that actually enables non-technical users to be able to edit these policies and collaborate with the engineers, where engineers don't have to spend any time taking their requirements, translating them into policies and implementing themselves. Once the initial implementation is done using Cerbos Cloud in the UI, you can actually edit policies and deploy them.

Eric Anderson:
This seems like it would be quite a productivity benefit for the engineering team, but I guess also, you mentioned security at the beginning. Part of the reason people have gone to outsourcing their Authen, I guess, is because we're told not to roll your own crypto, and you'd feel silly if you had designed your own authentication and then found bugs later on. How much of this is a productivity benefit for developers versus a security where people feel like they should just not do their own authorization? It's just bad practice.

Emre Baran:
I mean that's absolutely what we preach. Again, what we're trying to say here is if you do not have a team that's dedicated in building this and maintaining it and evolving per your requirements, this is one of those things that you shouldn't be implementing. And then if you look at the OWASP's top 10 vulnerabilities, what was number three that became number one is actually all the vulnerabilities that come through all the roles and permissions. And the reason is very simple, going back to the very original explanation I had, usually this code is implemented in a bunch of different layers, bunch of different ways. And as something morphs, usually people are people, there's a bug introduced, somebody misses a component, somebody mistranslates a certain requirement, and that's what actually starts opening up holes. And one bedside benefit of Cerbos is because it becomes that central decision point throughout your stack central but distributed a single one, Cerbos gets to see every single request that users make, every single action that users try to do, and it decides whether they're approved or not. And as a side benefit, you get actually a very consistent log throughout your stack, who tried to do what and whether they were approved or not, and why. Which policy it matched or which policy it didn't match.

Eric Anderson:
Another distinction I wanted to run past you is I hear about these authorization patterns for internal apps, production environments, and then I hear about them embedded in a single application. Do you see a distinction? Would I use Cerbos to give my development team authorization within a Kubernetes environment for example?

Emre Baran:
There are absolutely those tools. You can use Cerbos for that. However, we are very much so focusing all of our efforts right now in the application layer. There are some other authorization products that actually deal with service to service communication, or container to container rather than service to service. They focus on networking. At Cerbos, we very much so focus on whatever it takes within the application, whether that's user taking an action or you are having actually two microservices talking to each other. And that's why, on purpose, when I say our API accept a principle action and a resource, that principle can actually represent a user, that principle can represent a microservice. But at the end of the day, all of these things live at the application layer of your software.

Eric Anderson:
Another aspect I think is interesting about this market is that if you try and sell someone a database, it's really hard to sell them after they've built the application. Mongo had to find people when they're building the application. I imagine a lot of people get started with their own authorization, as we mentioned, and then they hit that pain at scale. And maybe it's easier to find companies at scale. You have something to offer for existing applications.

Emre Baran:
We tend to see two natural points on that. One of them is exactly as you described. They implement something, they've implement an if/then else statement, they kick the can down the road and, as they're scaling or as they're trying to go more enterprise ready, they have to revamp this and that's a great time to consider Cerbos. And another one is, actually, we have a lot of users who are experienced technology teams. That means this is not their first rodeo. They've been actually through that pain in other companies where they had to actually rewrite it twice once they were actually going. Potentially, if we're talking startups series A, their MVP turned into a more serious product, they had to address it. And sometimes those companies actually, as they go more upper funnel into more enterprise, suddenly your three roles aren't enough. You need to actually reconsider it or, potentially, give your customers a way to be able to implement multiple roles per customer. A lot of enterprise companies when they use SaaS, they would love to mirror their internal structure into that product in terms of permissions. So those are the main two times that we see. Either they're revamping it, or actually experienced founders who've been through the pain of having to rebuild it themselves, know the pain, and they say, "Sod it, we're going to actually take this off the shelf and move on, and never ever look back."

Eric Anderson:
Going back to the open source discussion. Maybe you could tell us what's been your experience in kind of bringing Cerbos to life, and to what extent has that been community building? Any tips for us and how you can grow a project like yours.

Emre Baran:
For us, it was crucial to open source it because we had to gain the trust of developers and showing them how performance Cerbos was and how robust it was. And building it in the open has been a very interesting journey. We had contributions from users as you expect at the edge, mostly at the edge around their use cases, and in having to connect to different SDKs, connect to different components on their end, or a great enterprise client had specific login needs, and they had to go in and modify how login was done or filtering at the login level, et cetera. The key for us has been always from day one, be one with the community and showing them that we're actually building this for developers. This product belongs to them, this product has nothing to hide, and getting them to adopt service as their own authorization layer. What we don't want to do is go and sell.
So we shouldn't be convincing anyone to use Cerbos unless they really want to. Working with developers, you can't force that. A developer is going to love the product. They're going to try it, they're going to wait for the use case to come up and implement it. And we've been through all of these different checkpoints throughout our development. And I would say still we are at the very beginning of our journey. Cerbos is not one of those projects where you have a hundred thousand GitHub stars because everybody can actually try it in any given day and apply it to a use case. How often do you actually change your security? The consideration times for security revamp are limited in a lump company's lifetime, but it's a crucial point to get it right.

Eric Anderson:
We've kind of danced around the fact that there are other approaches to this, and you've mentioned before that you take a policies configuration style approach. Help folks maybe navigate if they're choosing between some of these alternatives where Cerbos makes sense for them.

Emre Baran:
Yeah, absolutely. So there are two main alternatives to authorization that have been emerging lately that's working on the same principle of decoupling authorization. One of them is companies that are commercializing Google Zanzibar paper, explaining how they do authorization for Google Documents, YouTube, et cetera, where you have a product catalog or a catalog of billions of documents and you need to actually manage random access to those. And if you have such big catalogs that you can actually externally manage permissions for it, Zanzibar might be a good fit. However, where we don't see Zanzibar fitting really well is imagine you're building an expense system. And when you're building an expense system, all of your database records are part of your own environment. They're not actually externally hosted. Every invoice line is part of your environment. You don't want to replicate that data and maintain it in two different places in order to figure out the permissions to every invoice line.
So that's where we Cerbos works well. And the other category is all the companies out there that are commercializing open policy agents. And open policy agent is a more closer architecture to Cerbos where you have policy decision points that are deployed within your environment. But open policy agent is also designed for your entire stack. It's more designed for your Kubernetes management, your infrastructure, your network management. And of course you can shoehorn your application in there, but when we do performance comparisons, Cerbos is about 10 to 17 times faster in decision making, which matters massively. And one last thing, both of these Zanzibar and OPA based solutions, ultimately their policies are actually written in a policy programming language that you have to learn, you have to figure out what state it's in, you have to actually manage. Cerbos differs from them in terms of a very simple YAML configuration that is stateless.

Eric Anderson:
And what does the future hold for the project?

Emre Baran:
The future is ultimately we have worked on the open source solution that we are giving to developers. It's free, it's available, it's Apache 2.0 license. We invite everybody to try it out and help decouple authorization off our site, of their core code. And we are also working on Cerbos Cloud offering, which actually makes the deployment and management of all these policies and the logs much easier. I would love to invite everyone to sign up for our upcoming beta at cerbos.dev/next and give Cerbos a try.

Eric Anderson:
This is the feature you talked about earlier, Emre, where non-technical users could adjust policy in a control plane and have that impact the application without any changes to the code itself.

Emre Baran:
Absolutely. And beyond that, it also helps developers. So developers do not have to maintain their own CI/CD pipeline. They don't have to manage how to deploy policies. They can all be done in the Cerbos Cloud control plane in real time, distribution, and management of the policies.

Eric Anderson:
Awesome. And folks can check that out today?

Emre Baran:
It is not released yet. We are in the beta release process. However, they can all sign up at cerbos.dev/next. However, the core service offering is available today.

Eric Anderson:
Awesome. Emre, anything we didn't cover that you wanted to today?

Emre Baran:
I believe we've covered it all. And ultimately, I would love to invite all the developers to check it out and give us feedback. Because we are at the very beginning of our journey. We're very much so focusing on bringing valuable time back to developers so they can actually focus on building their product rather than infrastructure. I would love them to check out Cerbos, play around, give us feedback, and help us evangelize the decoupling of authorization so it's not part of your core code and it can be managed in a much more secure and a reliable way.

Eric Anderson:
Awesome. Thanks for this kind of gift to the world and the community in Cerbos, both the open source project and in the commercial offering. And thanks for coming on the show.

Emre Baran:
Thank you very much.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.