Jamstack Radio podcast: Revolutionizing access control

EEmre BaranFebruary 26, 202429 min read

In a recent episode of the Jamstack Radio podcast, Cerbos' CEO and Co-Founder, Emre Baran, alongside CPO and Co-Founder, Alex Olivier, delved deep into the evolving landscape of authorization systems. The discussion centered around Cerbos' innovative approach to simplifying and securing access control, marking a significant stride towards more robust and adaptable authorization solutions.

Read on for the summary of the episode, as well as a transcript.

Summary of the discussion

The episode began with an exploration of the foundational principles that guide Cerbos. At its core, Cerbos is designed to democratize complex authorization logic, making it accessible and manageable for developers of all skill levels. Emre Baran emphasized the importance of this accessibility, noting that traditional authorization systems often require a steep learning curve and substantial development effort to implement effectively. Cerbos addresses these challenges head-on by offering a solution that is not only powerful but also straightforward to integrate and use.

A key focus of the discussion was the unique approach Cerbos takes to handle authorization logic. Unlike traditional models that intertwine authorization rules directly within the application code, Cerbos advocates for a separate, declarative model. This separation means that changes to authorization policies can be made swiftly and safely, without the need to alter the application's core codebase. Alex Olivier highlighted how this model not only enhances security but also significantly reduces the time and resources required for development teams to manage access control.

Another significant point of conversation was the scalability and adaptability of the Cerbos solution. As organizations grow and evolve, so too do their authorization needs. The Cerbos model is designed to scale seamlessly, accommodating the changing demands without compromising on performance or security. This adaptability ensures that businesses can continue to enforce precise, context-aware access control policies as they navigate the complexities of growth and transformation.

In conclusion, the podcast episode provided valuable insights into the future of authorization systems. The main takeaways underscore the importance of accessibility, separation of concerns, and scalability in developing effective authorization solutions. Cerbos emerges as a pioneering platform, poised to redefine how businesses implement and manage access control. By embracing the principles discussed, developers and organizations can look forward to a future where authorization is no longer a bottleneck but a catalyst for innovation and security.

Transcript

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.