In The Arena by TechArena - Scalable, Open-Source Authorization with Cerbos

Episode Date: August 14, 2023

TechArena host Allyson Klein talks with Cerbos co-founder and CEO Emre Baran of the importance of authorization solutions and why he founded Cerbos to deliver scalable code that developers can seamlessly integrate into cloud native applications.

Welcome to the Tech Arena, featuring authentic discussions between tech's leading innovators and our host, Alison Klein. Now let's step into the arena. Welcome to the Tech Arena. My name is Alison Klein, and today I have an important guest. I'd like to welcome Emre Baran, co-founder and CEO of CERBOS, to the show. Emre, welcome to the program. Why don't you go ahead and introduce yourself? Thank you, Alison. Thank you for having me here. My name is Emre, as you mentioned, and I'm the co-founder and CEO of CERBOS. With

CERBOS, we are on a mission to make authorization simpler to implement and manage for developers. We can, of course, deep dive into that. So I wanted to just start with authorization. I mean, I think everybody knows what authorization is at first level, but this is, you know, constantly ranks as one of the top challenges of security. And within distributing computing landscapes, those security challenges are getting even more difficult to manage for a lot of organizations. Why don't you just give us a grounder on authorization and why you decided to focus in this area with Cervos?

Sure. Let me be clear what authorization is and isn't, because there is a very closely named sibling of authorization, which is authentication, and people tend to actually confuse those two terms a lot. Authentication is the act of logging, verifying your identity, and this is basically when you're logging into any system, you put your username, password, verifying who you are, And that is not what we focus on. We focus on authorization, which is the step right after you log into a product, a software product. Authorization is ultimately what can you do?

What do you have permission to do and what do you cannot do? What should be available to you? What information should you be able to see? What action should you be able to see, what action should you be able to do versus not. And authorization is a very important part of every software application that has multiple users in multiple roles, because these users usually need to collaborate in order to be able to complete a workflow.

And authorization limits the things you can do, the things your manager can do, the things that your teammates can do. And it's a very important topic because ultimately this is the last line of defense right before you take an action. And it's the last check to see whether a user is allowed to do something or not.

And it's been very important lately. It actually crept up to number one issue in OWASP 10 because it is a very simple attack vector that actually malicious users tend to exploit in order to be able to get certain actions in. It's an interesting challenge. I would assume that malicious actors are trying to appear as admins or giving themselves rights to different areas of the application that they shouldn't have within their profiles. How do they do that and how do you prevent it? How do they do that? They actually pose as somebody else. But the issue, biggest issue is if you have a very basic

software application and you only have users in three different roles, a manager, let's say, an admin manager, and a read-only user. And that's usually because you haven't actually invested too much time into your authorization layer. That's why, because you didn't really define what should be the different roles and permissions that should be assigned to each one of those roles. As more fine-grained you get with your authorization and permissions, you can actually assign many more roles. You can actually caveat different actions, different things around when an admin can actually edit an account, when a manager, what are the different approval levels of a manager? So when a malicious user actually pretends to be someone and all the permissions are very coarse, suddenly a manager, which has important, but it's a very costly and time-consuming thing to implement on an average software product. Now, in reading about Servos, I realized that you've really decoupled authorization from

the application development process. Why did you choose to do that? And what does that give as an advantage to your customers? So we decided to do that because it's ultimately in every software application, the business logic and authorization logic should be actually separated. Business logic is about, you know, what are the users, what can the users do as part of their workflow, et cetera. Whereas authorization logic is, are they allowed to do that? And we decided to separate that because when you actually look at software development, let's go back to 1960s, right? When you had to actually build software, you had to build every single layer of that

software. A very simple example is a database, right? Back then, independent databases, decoupled databases didn't exist. Somebody who wrote software had to write their own database data storage layer. And then later in the later 60s and 70s, databases got decoupled. And if you look at today, nobody writes their own database. They actually take one off the shelf and implement it, and they use its very simple API to store data and to retrieve data. So if we look at software evolution since 60s, a lot of services like this started getting decoupled. When we look at payment systems, for example, the credit card processing got decoupled. Nobody does that

actually within their code. They call an API and get credit cards processed. Similarly, emailing and messaging got decoupled. Nobody actually builds their own email sending services. And when we look at security, authentication got decoupled by the likes of Okta and Auth0. Nobody actually does their own username and password lookup. The directory, user directory got decoupled with LDAP earlier on, now with Active Directory, Cognito, and et cetera. Everybody stores all that information. And the logs got decoupled. There are a lot of services out there that actually consume your

logs and make them searchable and usable. However, within that security realm, authorization is still something that's being done by developers in application code. And the reason behind that is, it's one of those things that you actually don't really need it as part of your MVP most of the time. You can actually get away with three lines of code. It looks very simple to start with. However, as your product gets more and more complex, suddenly your requirements from it starts

getting more complex. And that three lines of code that actually checks whether somebody is a manager or not now needs to check if somebody belongs to one of those 15 roles. And based on those 15 roles, what are the different actions they can do? So, and especially in the modern computing, now take that same logic with all the microservices and distributed computing. Now take that same code and distribute it 15 times to all the different services that you're using, and then take a look at one line of change of that you need to do to the logic, suddenly how much of an issue it becomes. And we've seen this in our founding team. of that you need to do to the logic, suddenly how much of an issue it becomes.

And we've seen this in our founding team. We've ultimately built authorization layers in the different piece of software we were building up to, we've written and rewritten up to 10 times. And it's one of those things that is interfreciated, doesn't give your product any more advantage than anything else. It's one of those table-staked enterprise requirements. However, yet it consumes an average software team of three, four, but three months to be able to build something scalable and future-proof. And that's why we decided to dedicate our lives to solve this once for all. Yeah, it makes a lot of sense. What has the customer response been and how are people

implementing this? So the customer response been and how are people implementing this? So the customer response has been very positive. Those who have actually seen the pain in their previous lives jump on it and implement it and never look back. The response we get is very positive. And the way to implement it, how to implement it, we try to make it as simple as possible. One of the very first principles that we paid a lot of attention to is a developer experience. We recognize that today applications get deployed in so many different ways, in so many different types of technologies, in so many different types of technologies in so many different languages. So the very first things that we have done with Serbos, we actually paid so much attention to our ecosystem.

We wanted to make sure that SDKs exist in all the major languages. So the request to check whether somebody's allowed to do something or not is as simple as possible, as native as possible to the code. Then we paid a lot of attention to showing developers how and where in their framework to implement Servos. We've done a lot of examples with all the major frameworks showing where authorization comes into play and how to check it. Then, of course, as I mentioned in the beginning of our conversation, authorization never exists

on its own. Authorization actually is a natural step right after authentication. So we paid a lot of attention to showing developers how to couple services authorization with all the major authentication providers, as well as generic JWT token providers. So they get a sense. And lastly, as I briefly mentioned, there's so many different deployment models today in the world. There are still bare metal services people deploy services on. There are VMs.

There are containers, containerized deployments, dockers. There are edge distributions. So we're actually paying a lot of attention to making sure servos can actually play with any sort of system that has one or many of these different deployment models. And it's the still centralized single solution to be able to dictate the authorization rules of an application no matter where it runs.

I'm glad you brought up WebAssembly because I was going to ask you, you know, very popular for edge applications. And is there, when you start delivering applications using Wasm, is there any change in the way you do authorization or is it just simply integration within the finalization of the application?

So there are, the major thing that we pay attention to, of course, you can take Wasm and bundle it into your node application, a backend application, and that's fine. However, when we look at the authorization space and you're taking a Wasm bundle and integrating into your frontend application, such as React or Angular, then an additional consideration come into play. Because inherently, an application that you deploy into a customer's or end user's browser is insecure. So we are launching Service Clouds publicly in about a month, where the WASM bundles are

part of it. And with that, what we enable is being able to do all sorts of same server-side checks within the browser, within the application. So that actually gives it a lot of performance for all the UI. I think all the checks that you need to do in the UI, but everybody, a smart developer can actually circumvent that and directly hit an API. So what we do is we're making sure the Wasm bundle that's actually deployed in the browser is synchronized to the same policy that's running on the servos engine at the API. So in a sense, we make developer life easier or we make the development and the user experience

very fast by being able to check all these permissions within the browser. But then once the request actually hits the API, it's actually validated again before it gets committed. Now, Emre, I know this is not your first company that you founded. You were the co-founder and CTO of Janja, one of Turkey's largest social networks. You were the co-founder and CTO of Qubit, now part of Covio. So you've got a really nice history of innovation. What is your vision for your current company in terms of aspirations and where are you on that journey? So I would say, first of all, we are at the very beginning of that journey. The aspiration that I have is, so if I look at my journey with Yonja,

we did a B2C, right? It was a social network dealing with consumers at the end of the day. And prior to Qubit, I was actually a product manager at Google. So I've seen a little bit of B2B, B2C there. I was a product manager in ads. With Qubit, we was actually a product manager at Google. So I've seen a little bit of B2B, B2C there. I was a product manager in ads. With Qubit, we actually tackled B2B e-commerce mainly, but B2B. And the way that we're now, what we're tackling with Servos is a B2D, and which in a way, I see it as a nice intersection of B2B and B2C world where the end users very much so the developers behave like a B2C customer because you can't really just market them or sell them. They need to like the product and buy it on their own.

And then the selling process, actual commercial process very much so behaves like a B2B because you have to go through notions of a commercial company in order to be accepted within their ecosystem. And it's a very challenging intersection of those two worlds. But the way that we see this is we're ultimately building towards a whole new standard, how the software applications are developed. We're seeing this when we look at the world, we see this trend towards decoupling, all these services being provided to developers and

developers more and more focusing their time on their core business requirements rather than having to build infrastructure. And we want to be a part of that journey where we provide high-level, high-quality security layer to software so that they can actually focus on their core business. And I would say we are at the very beginning, we're starting with authorization. And in the short to medium term, we don't want to take our eye off authorization. But in the long term, security and all the developer tooling around security layer is very big. I think that's almost an endless pursuit in terms of all of the security capabilities for distributed applications. Exactly. And that's the world that we're

preparing CERBOS for because there are some applications that when we go and talk to large enterprises who've been around for 20 years, they have so many different systems and all these different types of technologies. And we wanted to make sure when we're building CERBOS, one policy can actually apply to every single application that they're running. Or their cell applications still have some of their data in the mainframes and some of their data

exposed in a mobile application. How do you actually have a uniform authorization layer across all of that ecosystem is what we're trying to deliver towards. And we do that by having a very uniform API and an application that can actually be distributed and run in all of these environments all at the same time. One final question for you. This interview has been really interesting, so thank you for being on the program today. Where can folks find out more about CERBOS and get engaged with your team

about evaluating your solutions? Absolutely. So CERBOS is CERBOS.dev, that's C-E-R-B-O-S.dev. But we are, as I mentioned, we are behaving very much like a B2C company. Everything we have about Serbos is on our website. And we also have a Slack community that users can engage in if they're actually playing with Serbos, going through a documentation, playing within our playground.

If they have any questions, we'd be more than happy to answer them. And then we also offer sessions to talk much more about the specific business domain requirements and figuring out how they can actually write policies for their requirements. We also have an upcoming launch of a Servos cloud managed control plane, which actually helps manage

different Servos deployments that you have. And for any information on that, they can go to servos.dev slash next. Fantastic. Well, thank you so much for your time today. It's been a real delight to have you on the Tech Arena. Thank you very much for having me. It's been my pleasure. Thanks for joining the Tech Arena. Subscribe and engage at our website, thetecharena.net. All content is copyright by The Tech Arena. Subscribe and engage at our website, thetecharena.net. All content is copyright by The Tech Arena.