Ep. #142, Decoupled Authorization with Alex Olivier and Emre Baran of Cerbos

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Alex and Emre from Cerbos. Alex, how are you doing?

Alex Olivier: Hey, good to see you. How are you doing? I'm Alex, I'm the chief product officer here at Cerbos.

Brian: Excellent. And Emre, what's your role at Cerbos?

Emre Baran: Hi. I'm the CEO and co-founder at Cerbos.

Brian: Perfect. Well, I'm actually ready to jump in so, Alex, do you want to tell us what Cerbos is?

Alex: Yeah, absolutely. Cerbos is an open source project that is designed to help you implement roles and permissions into your application in days, not months. Ultimately solving a problem and a pain Emre and I and the rest of our team had at numerous other companies where you want to get those fine grain permissions, like this user can do this action on this particular resource if they're part of this particular team, etc.

All that logic, which traditionally you'd have hardcoded across your codebase. Cerbos extracts it out into something that's far more easier to work with, far more understandable by more parts of your team and your organization and it just runs as another service inside of your architecture so it fits in nicely with the modern stack of which, obviously, Jamstack is one of those.

Brian: Excellent. I'm curious, so I mentioned before we hit record that I'm familiar with this policy management on the GitHub side as a GitHub employee. So we had a very complicated system to manage entitlements and who has access to what and I couldn't get production access to the database.

Ironically, I couldn't get production access to my side-project databases because GitHub had a bunch of locked down stuff so I always had to get some big brother or somebody else who had more access to help debug things which is a good sign for GitHub. They definitely don't want me taking stuff down in production. But I'm curious for Cerbos, maybe Emre your co-founder, how did you see this pain point and how'd this thing get started?

Emre: When you look at access control it's a very wide spectrum. You have access control at so many different levels, right? You have access control in your infrastructure access, you have access control when it comes to wherever you're running your services, AWS, GCP, but you also have access control in the product that you're building.

At Cerbos we're very much focusing on access controls that you have to actually implement within your products. When we look at the world, a lot of B2B products have multiple users in multiple roles because their customers are organizations with multiple users and multiple roles who need to work together in order to complete a workflow. So this all lands on the lap of a developer to implement which user can do what.

It's a slightly different use case than the one that you talked about, but it's ultimately that in any given software there are multiple users and multiple roles. So that is what we are focusing on, because as software engineers, as a CTO and previously as a product manager in various different companies I worked on and various different products we worked on, we always had to handle this ourselves and we had to build this layer all by ourselves.

If you look at software development as history in 1960s, if you had to build your own software you had to build your own database, your data storage layer and you had to start from the very beginnings of reinventing the wheel literally, and building on top of it from the first atoms onward.

But nowadays when somebody builds any piece of software, nobody starts writing their own database. They take something off the shelf and then they actually very much focus on the business logic. However, when we look at the modern stack, especially with all this decoupling, Jamstack and various other things, access control within the software was still something that everybody was reinventing from scratch. That's why we identified this as another part of the software infrastructure layer that needs to be decoupled and made very simple to implement.

Brian: Very cool. Yeah, this is like something from my purview, it's not something I think about a lot. I definitely have a bunch of stuff that we're leveraging off the shelf and we're only just getting to the point where we need to figure out... okay, so I'm the CEO of the company, I helped build the initial product, I've been a little bit removed from day to day engineering but every now and then I have to...

Actually yesterday I had a conversation about access to database to be able to do some sales discovery, et cetera. But then the question is should I have access? Is that too past what I need to be doing, or could I get a sandbox that's read-only? So I'm very intrigued by this product and how y'all are approaching this. You mentioned open source as well, and I'm curious about the choice for going open source too.

Alex: Yeah, absolutely. I guess a bit of backstory, I worked first as a software developer and then a product manager for one of Emre's earlier startups and I was both the developer and later the product person that had to go and manage the roles and permissions inside of that particular SaaS system. It was an eCommerce market platform, big, massive, Fortune 500, FTSE500x companies, and we were going and closing these deals with these big enterprise accounts.

One of the global airlines in the Middle East, one of the biggest retailers in the US, and they had these teams of tens if not hundreds of thousands of employees who all needed access to the particular system we had built. We'd go in and do this amazing pitch and we'd say, "Right, we're going to onboard you to our system. We have three user roles, we have an admin, we have an editor and we have a viewer." And that was it.

Immediately they'd turn around and say, "I can't shoehorn 90,000 employees into three roles. That's just not going to work." So you end up with these requirements as you start scaling up and building a company around enterprise level, enterprise grade permissions, and this is where you need to now start tailoring access to different parts of your system based on the user, what department they're in, what region they're in, what office they sit in, who their manager is.

This kind of beyond role based access control, but attribute based access control or ABAC. That was a three month project minimum to actually get built, and ultimately at a certain scale it becomes like a blocker to actually getting deals done and getting customers on board and such. We didn't want to waste three months and actually that system, the requirements kept changing and every time those requirements changed it was another three months worth of engineering work.

Those three months of a good team of engineers time, and they take away from building the core product to go and focus on this commodity infrastructure style layer. So when I went on to work at a couple of other startups and other different industries and I had to build the system over and over again, it's like, "Hold on, why am I doing this again and again and again?"

At Cerbos we all come from engineering backgrounds, we all still write code. Whether we should or not is another question to this day. I still write way too much code. The way we look at it is this is something that every system needs, this is something that you shouldn't be reinventing the wheel every single time, so we took a very much developer focused approach.

But we figured the best way of getting started here is actually go open source first. The core of Cerbos is the Cerbos policy decision point, this is essentially this microservice that you pull the container off GitHub or Docker Hub or wherever you run it, run it inside of your cluster, run it inside of your Lambda function, run it wherever you need and that's the core open source engine of Cerbos.

That is the component where you send a request to it, you're saying, "I've got this principle or user or it could be an API key, et cetera. It's trying to do this particular action," so they're trying to edit a report, they're trying to view a record, they're trying to export a download, let's say, on this particular resource. So the actual instance of the resource they're trying to access.

In your application code, you already know those three things because based on the request you've got some authentication token so you know that this person is Dougie, he's got these attributes, he's in this team, he's in this office, et cetera, he's trying to hit this particular endpoint so they're trying to do the edit action, let's say, on this particular resource ID of report 123.

So your application knows from the authentication token who you are, the URL basically dictates what action you're doing or the request for actions you're doing and, the resource, your application already knows what resource it is. Traditionally you would then have this massive If/Else/Case/Which style statement hard coded in there. That's where I always start, even on my little side projects I tinker on.

So if user role equals admin, do the thing. If not, return some sort of error. That gets you so far, but going back to those previous examples and previous companies, those If statements get more and more bloated, they get more and more tricky to understand. As you start scaling up your systems, you've got webs of microservices in different languages, you've got your Node application, you're starting to do some AI LLM stuff in Python over here and they all need different permissions, et cetera.

Whenever those requirements change or when you need to enforce a new permission or you want to, say, change how a feature is packaged to different access models, you then have to go and touch this code which is across all sorts of different parts of your application code. It's a mess, it's a web, and it really gets out of hand. So Cerbos, the way it works is you take the open source product, you define your authorization logic as policy and you suggest YAML definitions. Love it or hate it, YAML is very much here to stay, and it's very clear and very simple.

You define, "Here are the different resource types in my system. Here are the different actions that you can do against those resource types, and then under which conditions those actions should be allowed." So a simple thing is a user must have a certain role. A lot more realistically you end up having conditions which are things like, "This user must have a role and they must be the owner of that resource,"so you would have a little expression in there which says, "The owner ID attribute of the resource must be equal to the ID of the user making the request, thus they are the owner that has attribute based access control logic."

So all these different policies are then loaded into that open source container that you're running inside of your stack, so it's running right alongside your application, so you're not going out of the internet, you're not going to hit some external API or anything. Everything is local to your app, and in your application code before where you had that massive If/Else/Case/Which style statement, you now just make an API call out using one of the SDKs or the API directly, and you simply say to Cerbos, "This user is trying to do this action on this resource."

Cerbos will evaluate the policies, creates an audit log of the decision which is something that's generally overlooked if you had to build it yourself, and then returns back that and allow, deny you the application code. So now that massive logic before is a single If statement, if Cerbos says allow; do the action. If not, return some sort of error. That's the developer experience, and that's why we went open source first because this solves a problem that every application will have at some point.

We wanted to get the core out there, we wanted to get the solution off the shelf, we don't want it to be a blocker, you shouldn't have to go through procurement to get a stable solution in your environment and that solution should scale with you. This decoupled approach, decoupled authorization is the kind of phrase in the category we're talking about here, that decoupled approach really gives you this incredible advantage where whenever those requirements change, which I guarantee they will, you just update your policy files once.

They sit in a Git repo, you have a whole CI pipeline running around it, the tooling will be open source as well. Then those requirements change, change your policy, the Cerbos instances pull that latest policy in, and now without redeploying application code or anything like that, all your authorization logic has been updated and you have a single source of truth of what's going on, and what decisions were made from that audit log.

Brian: Yeah, that's pretty elegant. When you were saying the If statements, I felt triggered because I'm like, "Oh yeah, that's my life." Because I literally am working on a little side project, as I do as a CEO, I don't try to do production and block up the engineers. But I do have a Case statement on managing who has access and who's looking at what. That's the best approach to let's just get in front of people and the engineering team can make this polished.

But yeah, what I'm hearing is it's extremely elegant to be able to say, "Okay, we've got an open source solution. Try this out." And I think this was a lot of the big hurdle because GitHub acquired by Microsoft was definitely the biggest company I've worked at, so technically Microsoft. But we were kind of seeing like new steps and hurdles on how to interact with different parts of pieces of the stack.

That was very eye opening for me to know, "Oh, okay. I can't just cowboy code my way into whatever solution and expect this thing to go live in front of a couple of thousand people." Even a couple hundred I'd need to go through some checks and balances. You're right on the money with that audit log thing too as well, because you don't know you need it until you need it, so to have that out of the box is extremely valuable.

Alex: Yeah, the audit log piece and I can definitely speak and understand what you went through. I started my career at Microsoft so I've done the big enterprise, and then I went to startup. So I probably went from very structured to a bit more cowboy and now I'm going back slowly. But yeah, the audit log piece is something that I'm particularly a fan of, I guess you could say, or quite keen to make people aware of because at previous companies as well as Cerbos now, I've gone through ISO-27001,

I've gone through SOC2 compliance, et cetera. I was the one that got pulled into the basement conference room by the auditor who had come over here and I had to demonstrate on demand our access controls and our audit logs, et cetera. Before we had a neat solution I'd be sitting there trying to grip through S3 logs which doesn't really go down well with an auditor.

So having clean, structured audit logs and a source of truth, exactly what happened in a way that's understandable, presentable by someone that doesn't necessarily have the code or wants to look in raw log files is a big win. Really, it's a side effect and a side benefit of using something like Cerbos because it's just capturing the decision that's being made, the actual core decision engine runs and as well as returning a response it just creates that clean and consistent audit log. So regardless of where in your stack you're doing that check, you're getting that log in place.

Emre: One thing that always often gets overlooked, even if you are a developer writing your own code and audit logging, one thing that always gets overlooked is all the attempts, right? Usually people tend to log what happened at the end, but who actually tried to do something? And whether they were allowed or denied, and why were they allowed? Why were they denied? Those are all very important pieces of information, especially for organizations that have their own security teams and they actually look into all these events and try to predict various different frauds or different counterfeiting operations.

Brian: Yeah. You kind of hinted at this, but I wanted to ask the question straight up, which is who's the ideal customer profile? Because it sounds like there's not a size difference. It sounds like I could use this at my seven person startup. But yeah, who's the ideal use case for this?

Emre: So it's actually staggered. The number one ideal user is the developer. Developer, whoever is building this piece of infrastructure. We want to make sure that developers don't get to reinvent security, a developer who needs to first put that If/Then/Else statement which is very easy to put in, but then as requirements get bigger all the bells and whistles come in.

We want to make sure that developers are never tempted to actually start writing that If/Then/Else, and they actually put something in that's very easy to implement and operate.

However, let's take that startup choice lifecycle, as that startup starts growing as Alex mentioned earlier, requirements start coming in. Whether it's from the business teams, whether it's from the project management or security teams, and all those requirements turn into, "We need a new role, we need a new way of authorizing people or deciding on somebody."

So suddenly it goes from the developer into a team, like a product management team or product development team, so now suddenly we have a product manager and a developer. Now, as the organization grows more as we've just mentioned, security starts becoming more of an issue. Suddenly it becomes an enterprise problem of who has access to what, whether all of that is in check, whether all of that is being audited.

Suddenly the see-saw starts getting involved in that. The ideal user of system is depending on the evolution of a company, it can be one, two or three of all those different roles. The ideal customer profile is ultimately companies who have to handle authorization, whether they are a simple startup, a just coming up startup and they want to implement something that's completely scalable and extensible throughout its lifetime.

Or we also have several very large enterprises who are actually rearchitecting their system, they're going from monolithic applications into microservices and suddenly they don't want to translate the same logic into four different languages and maintain parity across all that logic. They're actually centralizing it. Cerbos, they get a single API that speaks the same truth no matter where you're accessing it from.

Brian: Yeah. I'm curious, because I imagine there's a lot of folks listening already and also been triggered by the conditional statement. I guess what are some good rebuttals for folks who are thinking, "Oh, I'm not ready for this"? Or, "I don't need it yet," because it sounds like this is something you want to install into your system earlier before it gets too complicated or before you end throwing weird stuff around in your monolith.

Alex: Yeah. So I think there's certain industries and verticals where you're going to be thinking about this earlier than you may have to. We have a lot of users in finance and fintech and regulated industries. This is just foundational stuff you need from day one, and anything you do that isn't scalable is definitely going to burn you down the line as you start scaling up.

For getting started, early stage, you're hacking on a weekend project or you've got a little side thing you're working on. The advantage of putting something like Cerbos in now is the hooks are already in place, so you're saving yourself the refactor, you're saving yourself the rearchitecture that Emre spoke about. You're saving yourself the headaches down the line, and for the little bit of work now, the payoff is exponential.

So going back to my previous example, every time we had to change the logic in some of these applications I worked on, it was three months of an engineering squad's time to do this properly over a moderate sized system. It wasn't insane, you're looking 30 or 40 different microservices in a few different languages, but it was three months of engineering we had to refactor and rework and reconfigure how this authorization logic works.

So it does take a bit of forward planning, let's say, or foresight and confidence, I guess, that your application is going to be massively successful, your platform is going to be great and you want to get these things set in stone early. Really, the best parallel to look at is authentication. Today, rarely you would probably go and build your own authentication system. There's lots of either open source or commercial products out there.

You've got tokens, you've got the Auth0, you've got Auth Kit that came out a few weeks ago, you've got Clerk who's doing really well, and it's kind of a no-brainer to go and put in authentication using one of these services or open source projects yourself because that's a whole ball of mud that you don't want to go down the route of managing yourself. Hashing, sourcing passwords, managing SSO, managing social logins, et cetera.

You just go and drop in a library, you go and drop in a service that does tit for you. Authorization is the next one of those, and hopefully you can hear from our experience and, Dougie, yourself around that list. It's something that does get painful, and you can just tick something off the list very early on by putting a solution like Cerbos in from day one.

Your logic can be very simple, you're doing those simple role based checks and your policies are very simple, and your deployment is very simple at that point. But it will grow with you and will put you in good stead so down the line when you get those big deals or you are going for your ISO or SOC2 compliance, or you are going to be a multinational business, et cetera, all the foundations are in place and you haven't wasted your valuable time and money in the early stage to do something as foundational as authorization. Just drop in a solution that works for you and will grow with you.

Brian: Excellent. My next question is how does one get started with Cerbos today?

Alex: The line we always use with this is 99% of the effort is actually understanding what your requirements are first. So really thinking, "Okay, what are my different user roles? What are the different resources and actions inside of my system?" And literally do that spreadsheet, do that matrix, "This user should be able to do this action. This role should be able to do that action. This action, X, Y, Z."

And some of those cells will be a yes or a no, some of those cells will be a condition, "This user can do it only if they are the owner." If you're a solopreneur, getting that down on paper yourself and just get it straight in your head. But if you're working with a team, making sure everyone is aligned, you've got a sales team, you've got a customer team, you've got a product team or whoever is involved in decision making, getting all that down on pat.

Once you've got that, it's actually pretty trivial. So to get started with Cerbos if you like to run everything yourself, you can go and just grab it off GitHub, spin up the container, you can write some policy files and load them in, and you basically get that API immediately. We also have Cerbos Hub, Cerbos Hub is the managed control plane that sits on the Cerbos open source project.

Then there we have an interactive, online playground where you can actually build, test and iterate policies directly inside of your browser. We guide you through exactly what to do, we run all your test cases, we give you much better feedback around formatting, et cetera. There's a whole environment where you can define test cases and get up and running, and really nail your policies without having to run any code or any infrastructure yourself.

Then that's the whole environment that goes on, it's a whole managed CI pipeline that enables you to run your policies both as containables, or as a WASM module if you want to do things at Edge or even on device. Really, it is getting that business requirements down on paper and write them into policy, and then you'll be up and running in... I don't like saying minutes because no one believes minutes, but you can do it in a couple of hours.

Brian: Cool. Yeah. I do want to ask is there any exciting things coming up on the roadmap or that folks should be paying attention, or maybe that just shipped?

Alex: Yeah, absolutely. So I just mentioned that Cerbos Hub. We launched this at KubeCon North America.

Brian: Nice.

Alex: So that is now out there in the world. Cerbos the open source project, Cerbos Policy Decision Point is still out there, that is the foundation of everything that Cerbos does. That's actively being worked on, not just by people inside of Cerbos but also the wider community which warms my heart every time I see a pull request from one of the users out there.

Cerbos Hub is just the added layer on top which gives you a much more of like a managed environment for defining policies, managing policies, and managing lots of the operational burden that can be introduced when you're running a large cluster. Cerbos Hub manages the rollout and distribution of policies, and also enables those other use cases around running Cerbos policies either at Edge, say in Edge functions and workers and those sorts of things, or even on device.

Cerbos Hub also generates a Web Assembly module version of your policies which you can run in far more places where you can't necessarily run a container. Then we have a whole roadmap going into this year that really supercharges that environment and gives you much more tooling, firstly for developers but going into product teams and security teams over the rest of this year to bring more of those stakeholders, bring more of those users and bring more of those teams on board and hopefully taking some of the burden off the developers down the line.

Brian: Excellent. Well, honestly I'm super intrigued. I'll definitely be following up about Cerbos and what we do at Open Sauce because I think we definitely have a use case that we should be paying attention to. Access control and et cetera. Yeah, I'm looking forward to digging in. I hope folks that are listening to the conversation will also dig in and reach out to both of y'all for demos. There's a lot of demos on YouTube, so look for Alex' face walking through the hub.

Emre: One more thing to add there is a lot of people... Earlier I also mentioned B2B use cases, in every B2B product you have to implement it. But what we also tend to see a lot is for many other products, B2C products, et cetera, the same use cases exist for the back office. So you can think about Uber, for example, Uber app doesn't need any roles and permissions when you look at it.

I just call a cab and it shows up. But now think about the back office operations of Uber, who's actually allowed to onboard a new driver? Who's allowed to issue a refund? Who's allowed to see trip information? So a lot of these B2C use cases, actually when you get to the back office, the internal control systems, et cetera, there's still developers building those systems and they need to limit access or they need to implement fine grained authorization. So the way that we always look at this as use cases are endless.

Brian: Yeah. That's a good point too, as well, because I know Uber had some issues years ago around who has access and who could see certain politicians in their rides. Twitter had an issue with folks getting access to their, "God Mode." I come from 10 years ago building Ruby on Rails apps. That was like, "Oh yeah, let's just get God Mode and anybody can go assume the role of a user across the company."

Emre: And it's nature, right? It's nature. Everyone very much so focuses on the core use cases of their product and nobody really thinks about these, and they're like, "Oh yeah, it'll be a problem when we have to deal with it."

But by the time they realize they have to deal with it, it becomes a big monster that they need to implement and suddenly, especially in organizations that do not have their own dedicated security engineering team to build that layer, they start pulling people from your top engineers from different parts of your system that know your system in order to be able to build this.

Then the pain comes when you need to actually extend it or make it scalable, the second iteration, the third iteration. This is what we have seen in many organizations ourselves, this is what we have heard from a lot of our users and customers, and ultimately we've dedicated our lives to solve this once and for all so that nobody has to actually deal with it.

Brian: Yeah. Fascinating stuff. I think we can probably talk a little bit more about this, but I do want to transition us to picks. So folks, definitely check out Cerbos.dev and it's probably a good fit for you if you're not doing any of this stuff already, so definitely check it out. But now we're going to move other to Jam picks, these are things that we're jamming on, that keep us going throughout the day.

So I know we talked about this earlier, but if you guys don't mind I'll go first with my picks. First pick, actually I think we mentioned this in passing as a use case, case study. But Zeni.AI is my pick. I've been managing, as a founder of a small company, the finances myself. I've got a finance degree so I can zero base a budget and I can do a bunch of other stuff, but I don't want to.

So Zeni.AI is an app that basically connects to your QuickBooks, which again I can be dangerous in QuickBooks but I don't want to anymore. I want to move onto bigger and better things. It connects your QuickBooks, connects to your bank account and they give you a really elegant onboarding experience to understand things like burn and meant, which meant RIP on that thing that's now going to be dead pretty soon.

Understanding what you're paying for and where money is going, and really as your businesses operate it's a nice place to offload that experience. So if you're a very new founder, Zeni.AI definitely worked getting in early into your product and it was cost effective for us. So yeah, definitely check it out.

Emre: I'm laughing here because my pick is very much the same use case but another product. It's called Pry, it's P-R-Y-dot-Co. It's very much the same, it hooks into your bank account, it hooks into your accounting system. We use Xero and then it let's you model your entire company spend so you can actually put all your projected things and spend, you can put all your hiring plan.

Actually, every month it reconciles with your accounting system and says where you're overspending, where you're underspending based on your budget, and as a startup founder... In my previous company I was running the entire product and engineering team, I had to do all of this in a spreadsheet and that spreadsheet had to get reconciled and then CFO actually did the whole company-wide thing, et cetera.

With Pry, when we first started I tried to replicate that spreadsheet and it was a nightmare, and then came across Pry and like, "Oh my god, it does it in here." What I love about it, it has also a Git Ops approach so you can actually make branches of your plan and you can have different scenarios. But that's been, again, as a startup founder, cash is very important, your runway is very important.

Yeah, that's been my CFO basically since day one for the past three years. I believe recently they have been acquired by Brex, but they're still operating as an independent company.

Brian: Oh yeah. Yeah, very, very familiar. It's very familiar to Zeni, so yeah. I did not know of Pry, but definitely looks like it's worth checking out. Cool. Alex, did you have any picks?

Alex: Yeah, absolutely. I'm not going to go finance. At Cerbos sometimes we get bucketed as infrastructure or deep tech type solution, and I feel like there's a lot of these companies that don't necessarily get as much publicity as they deserve given how good their tech is. So I'm going to go quite niche and quite technical, a company called Buff. There's a technology called Proto Buff which Google led the lead on many years ago and runs things like GRPC and such out there.

Buff is building this whole developer ecosystem around Proto Buff, making them far easier to work with and is an amazing tool chain. Buff.build is their website. We're heavily, heavily using it at Cerbos and it allows us to definitely type and strongly define your APIs and then we're consuming those definitions across our frontend, our backend, our queue works, et cetera.

We have a central source of truth, much like we do with Cerbos authorization policies. We have a single source of truth for our message types and our data types as Proto Buff definitions and using the Buff ecosystem or tools on top to do a lot of the code generation and even some documentation and validation stuff on the fly using their tool chain.

It's one of those technologies that I think you can very quickly brush off as being a bit unsexy, but it's actually a really, really nice way of working. We've built a whole stack around it, and I just like to shout them out whenever I can because they're doing some great work over there.

Brian: Very cool, yeah. Well, thanks for the picks and thanks for the conversation, and talking about Cerbos. I'm excited to dig in and punt this over to my engineering team pretty soon, so thanks so much for the time. Listeners, keep spreading the jam.