Alex Olivier is a Product Lead at Cerbos. It is a self-hosted, open-source authorization layer that separates your authorization logic from your core application code. He joins the show to talk about the company in more detail and what it can offer to its users. Additionally, he explains the process of Testing and Setting it up.  

Hey everybody and welcome to another episode of React Roundup. I am your host today, TJ Vantol, and with me on the panel I have Paige Niedringhaus.

 

Hey everyone.

 

and Jack Harrington.

 

Hello there.

 

And our special guest today is Alex Olivier. Alex, welcome to the show.

 

Hi, very happy to be here.

 

So Alex, why don't you start by telling us a little bit of who you are, what you do, why you're famous, all those

 

Thanks for watching!

 

great sort of things.

 

I

 

Hehehe

 

think fame, not sure if fame is the right word. But yeah, I'm Alex Livia. I am a product lead at a company called Servos. We are an open source solution for implementing roles and permissions inside of your software applications. My background has been in software development, mainly in speed to be SaaS businesses. And this is a problem that keeps coming up over and over and over. So we decided to solve it once and for all.

 

Excellent. So a nice, small and easy topic that we

 

Yeah.

 

can cover

 

I'm sorry.

 

Ha

 

pretty

 

ha

 

quickly.

 

ha ha!

 

Now, I love this because it's one of those features that almost any application needs, right? I mean, who's building serious apps without some sort of user

 

Yeah.

 

authentication and such. So why don't you start by just explaining, I know you wanna talk a little bit about authentication versus authorization,

 

Yeah.

 

but maybe you could just start by explaining the basics, like what are your options today? If I need user management for my web application, what am I commonly doing today? What are my options? Maybe you could walk through some of the basics to start us off.

 

Yeah, absolutely. So you think of a typical web application, you want to have users log in. They want to be able to do various things inside your system, and you want to do that in a secure and trusted way of doing things. So we're in a world where today authentication with an N is relatively a solved problem. You have the likes of Auth0, you have Firebase authentication, log in with Google, GitHub, that whole world, OAuth2, wonderful. There's very little reason these days for you to go and run your own database that has a username and password table. That's just not really a thing you really have to worry about anymore. And there's a whole lot of risk you essentially get to take off your book and off your plate by using a service that specializes in that. But once someone's actually inside an application, there's actually this whole other set of business logic around, OK, this person's in, but what can they actually do? Should they be able to submit that pull request? Should they be able to comment on this? Should they be able to flag a message? level actions and that's authorization. So you know who they are but can they actually do a thing? Should they be allowed to go and do some particular action? And if you look at a sort of traditionally in a kind of typical web API type system you'll have a request come in, you have some authenticated session, you have a JWT or a cookie or something like that where you know who the user is, then you probably have your own sort of user profile database inside your system which contains team, they're in this office, they have this quota, these kind of attributes or sort of directory profile information. And there's solutions for that. You may, legacy systems, you think like LDAP, Azure Active Directory, nowadays you might just have your own database. And then the final step is, okay, using all that context, plus the actual thing they're trying to access, if they're trying to submit an expense, the attributes about the particular expense they're interacting with, you would then end up with hard coding your business logic. proven expense if you're in the admin team, finance team, sorry, and it's less than $5,000, let's say, you'd end up writing an if statement or case switch, case switch, set a logic to go and decide based on the user and the resource, whether they should be able to do the thing or not. And that for a basic application is pretty easy to go and implement simple if statement job done.

 

haha

 

As you start scaling up, you have lots of different resources, lots of different actions that are possible. You're gonna end up repeating that code all over the place. principles and that business logic is going to get more and more complex. Um, if, if you kind of imagine scaling up and you're now in a world of like microservices and things going really well and you having very distributed, you end up thinking special services and special languages cause they're better fitted, you might have a, you know, your API is a node, you might have a recommendation model in Python, you might have some legacy system in.net. Whenever this business logic changes around who should be allowed to do what, whenever the authorization logic changes, you're now going to have to go and take a spreadsheet or a gerotic or something like that, and go and rewrite that logic in a number of languages and redeploy your whole application. So that, at the crux of it, that business logic, that authorization is the area that Cervos is trying to solve using the Cervos as the open source project to kind of do that as a drop-in replacement. So you don't have to hard code all that business logic and essentially decouple it from your application.

 

So is this something that I would work with on my server, or my client, or both, or how is this all fitting together?

 

Yeah, absolutely. So if you kind of step back a bit and look at, what I think has been a really big shift in application architecture, especially recently, so this sort of decoupling of components into specialized services. So, you know, if you go way, way back, when you started building an application, you would have to worry about designing your own database because there wasn't an off the shelf databases to do it.

 

Right.

 

You're

 

Yeah.

 

now worried about like how you store data in flat files and all that sort of fun stuff. That got sort of taken out, you end up with SQL Server, postgres, et cetera, off the shelf solution and specialize, go for the job, plug it in, off you go. Go back about five, 10 years, you'd do the same with authentication. So before you wrote that username and password table, nowadays you go and plug in Okta, Auth0, Firebase, Auth, Google, whatever. And this kind of decoupling of specialized services, same with metrics, same with logging, same with request tracing, as everybody's seen. It's plugged in things and very much accelerated Kubernetes and side cars and all this kind of the modern stack as it were and service is one of those so service is a Standalone service you run inside your system. So you run it on your server And if you're in kubernetes, you can run it as a sidecar if you're in like just running bare metal VMs You can just stick the binary on there and run it if you're in lambda You can run it in a lambda function and so service is a service that's inside your network So you're gonna have extremely low latency for doing these authorization checks so in your code that complicated FL style statement to work out who can do what, you now replace all of that business logic with a single call out to that server's instance. And you say to the service instance, I have this user or principle, cause it could be an API key, could be a service token, whatever, has these attributes, they're an admin, they're in this team, they're in this office, trying to do X action on this resource. It's a expense resource, it's from this office, it's of this amount for the supplier. And that service instance replies very simple boolean allow or deny.

 

Hahaha

 

Ha

 

So

 

ha.

 

in your code base, it's now a single if statement to work out whether an action should be allowed or not. Now, the beauty of having this standalone kind of instance inside your system that's doing this and that single point to work out whether an action should be allowed or not, is you're now gonna get a consistent answer regardless of where in your stack you're doing these checks from. So it could be in your front end service, it could be in your backend for your API, It could be calling it from some async worker. It could be calling it from some batch job somewhere. Wherever these checks are, regardless of what language, they're going through a single point and you're gonna get a consistent answer. The beauty of that is twofold. One is when you update the business logic for that service instance, for when the rules have changed, there's one place to update it. And you do that through policy configuration files. And when that change is made, all the tests pass, et cetera, and all your systems get updated at the same time. And there's no need, you don't need to touch your application code. You're gonna get that update propagated essentially out and you're gonna start serving based on the new permissioning logic without any work. And the side advantage is, if you're in a environment that has quite strict rules around audit logging, access controls, regulated industries, about a big chunk of service users today are in FinTech and the insurance tech. Because there's one point where all the decisions you're gonna get a clean and consistent audit log. This time, this principal tried to do this action on this resource and it was either allowed or denied. And so that's the problem that I personally had to solve a dozen times of my career thus far, both as an engineer and as a product person. And we're now, every time we're like, why the hell are we building this system again?

 

Right.

 

Hehehehe

 

Hence we were like, let's go and solve this once and for all. And that's what services are. Again, please open source, Apache two license, grab it off GitHub and plug in and get going.

 

Okay, so how do you tell Servos what the rules are for your particular organization?

 

Yeah,

 

Because that's what I'm

 

Yeah.

 

really interested

 

that's what

 

in.

 

I was gonna ask you.

 

Yeah.

 

Hahaha.

 

I have built, you know, I've worked on teams where we've built our own custom authentication and it is

 

it.

 

a nightmare, just as you said, there's so many edge cases that always end up being real pain. So how do you tell Servos these are the rules or update it once you've got some rules in it?

 

Yeah, yeah. So my mind and the rest of our team's background is from running very large, distributed high throughput, low latency systems, or like 25 billion requests a second, a day, sorry, was kind of the scale we were running at in our previous companies. And so we got kind of familiar with the modern sort of cloud native tech stack, where you're scalable, Kubernetes, serverless, stateless architectures, these kind of things. And one of the principles that is kind of very much in that world is like the whole where if you look at your Kubernetes configuration, for example, you define manifests in a Git repo, that's your source of truth, and you change your deployment options, your cluster picks that up, and suddenly your cluster goes through a reconciliation loop, and everything's now kind of synchronized. So we really like that pattern, because it gives you that, again, sort of audit log of that change history, a single source of truth, and we're applying that to authorization. So the way you define this business logic and these are YAML files. They'll look very familiar to Kubernetes manifests. If you're used to those, a good developers copy, great developers paste. I think that's still,

 

Hahahaha

 

that was a Scott Hanselman quote. And so that format, and there's a really nice tool chain around that today. So you define this business logic as a policy and your policies state here the different resource types. So if you're building like an HR system, resource, department resource, you might have a salary resource, you might have an insurance resource. You define all the different actions in this ML format. So create, read, update, delete are the typical ones, but it's open-ended. So you can have very business-specific actions. So approve, deny, comment, flag. It's open-ended to define how you want. And for each of those actions, you define what the conditions are. So to do this action, particular role. And to do another action, you might have another particular role. And for basic, what's traditionally known as RBAC, Role-Based Access Control, that's really all you need to define. So for this action, you must have this role. And that service instance, when the request comes in, will check whether that user has a role or not. And that's kind of the base case. In reality, though, even if you think you're doing RBAC, generally, things are much more detailed than that. And there's another layer where you're starting to actually check the value of attributes. about

 

Yeah, I was

 

a

 

just

 

person

 

going to ask, I

 

or

 

mean,

 

a resource.

 

can you do your $500 expense approval in this?

 

Exactly. So this is really where CERBOS is focusing, which is ABAC, Attribute-Based Access Control. So as well as defining, you must have this role or you must have this it's a wild card or you have a particular role, you can also start defining conditions. And the way you define conditions is through an expression language. It's called Common Expression Language. It's a Google open source way of defining essentially Boolean logic.

 

Huh, neat.

 

and service itself is running Go, and it's a Go library. And with the service policies, you can define, all these conditions must be matched, or one of these conditions must be matched, or subset of the conditions must be matched, and you can do very kind of and or type structure around the conditions. Then the conditions themselves are referencing either attributes about the principle, so the user or the token making the request, and the resource. particular expense you're trying to look at, it has an attribute called amount. And inside of those conditions in your policies, you're essentially comparing and doing Boolean logic on those values. So you would say something like the principal ID and must not equal the owner ID of a resource. And you can write that out in pretty much pros, because it's a very sort of structured and sort of clean way of defining it. And then that's your policy files. And you can kind of evolve evolving and that over time. One thing you need to be careful of when you define as business logic is making sure you've caught all the edge cases. So one of the bits of tooling that's available is you can actually write unit tests against server's policies. So you can essentially do test-driven development for authorization logic, which if this logic was encoded in your application would be a bit of a nightmare because you're

 

Thanks for watching!

 

going to have to worry about instrumenting and orchestrating the rest of your application before you can even get down to testing that bit. authorization logic, stand alone and defined in these policy files, using the service framework that we give you, you get full test room development. So you give it example users, example principles, and it does full matrix testing of every single combination of user resource and action, and making sure that the results are as you expect. And you can plug that into your CI pipeline, GitHub actions, et cetera,

 

That's pretty

 

to make

 

cool.

 

sure any changes are

 

Mm.

 

as you expect before they get rolled out. And going back to the whole kind of GitHub's you know, you've made your change, it hits what you need. It gets merged into the main branch. And then those serverless instances that are running inside of your stack are getting notified from the Git repo that there's a new update available and it will put it down and start serving based upon that as you would with sort of typical CICD pipeline.

 

So I kind of want to back up for just a second and make sure I understood some of how, how this works. So you, you had said that the actual sort of business logic, the core, um, like sort of underlying policies are defined by these sort of manifest files.

 

Yep.

 

Right. So I'm going to pose you a specific example, just because I'm just trying to think, think through this. So let's say, I'm building a system where certain people on the sales team can approve expense reports. Right. And so I might have a manifest that's like these four people, at the company, these four users are allowed to do it. And then, oh, new person joins, new salesperson on the team, and they're allowed to approve expense reports. If I wanted to add that role to them, am I like manually editing a manifest? Am I building like a UI around this? So like my

 

Thanks for watching!

 

sales director can go in and add the new person themselves. Like, do you have like APIs for like modifying this? I'm just sort of trying to paint a picture of what this would look like,

 

Yeah. Yeah, so going back to kind of that user directory type structure, which some sort of every application has be it a profile database, those kinds of things, that's where you have those attributes. So this person is the sales director, this person is in the sales team, this person looks after XYZ region, let's say. And that's kind of all metadata that's about the user that's in your application and high chance if you're building like a SaaS platform, you already have your own UIs user management, like you don't want to have to go out to some other tool to support that. So where server fits in is taking that context, so in your application code where a request comes in to do a particular action, you know who the user is, you fetch this state and about the particular user, they're in the sales team, they're in this region, etc. And then before you do the action, you send a request out to a server's instance saying I have this user, they have these attributes, they're trying to do this action on this resource, it has these attributes. and the service instances as a whole are completely stateless. There's no database. There's no backing data store that holds who does what. And the policies themselves are evaluating based upon those inputs that are coming in the request to the service instance, which

 

Thanks for watching!

 

avoids this kind of nasty problem in some other approaches where you have to synchronize state from your application to the authorization layer, which is going to lead to all sorts of fun cash misses and delays of getting things synchronized across all your different services and instances. So the service instance and the policies are comparing the inputs and coming up based on the policies with either an allow or deny decision primarily.

 

So it sounds like you're kind of bringing your own user management. You're bringing your own metadata and it serves

 

is actually gaining almost like a protocol or an API

 

as acting almost like a, like a protocol or an API for

 

for lifting the core scene.

 

like enforcing those things

 

So it's a little bit of a different experience. So I'm going to go ahead and show you what I'm doing with the core scene. So I'm going to go ahead and show you what I'm doing with the core scene. So I'm going to go ahead and show you what I'm doing with the core scene. So I'm going to go ahead and show you what I'm doing with the core scene. So I'm going to go ahead and show you what I'm doing with the core scene.

 

or like a standardized way of performing those actions.

 

Yeah, so you can say to your application now it is a single call out. It's a single, you know, cool server stop, check resource, principal

 

Thanks for watching!

 

resource action, and it comes back with an allow or deny the actual logic behind the scenes is defined in those policy files, which can now evolve independently of your code base. And that's where the really power power comes in. Cause if you think, we think sort of, you know, in a company who really owns the requirements for authorization, it's not the developer doing the coding. a product owner, maybe like a security team might have some input on audit requirements and those sort of things. So where SELVUS kind of sits is the engine that the developer sort of implements to check the permissions. But it abstracts the logic out into these policy definitions, which then can be evolved on independently and potentially by the product owner directly without having to open a ticket, put it in the Jira backlog every time that the authorization logic needs to change. And they'll say, come back in three months

 

Okay,

 

So

 

can I pull

 

decoupling.

 

a TJ here and ask and kind of like take us back a second? And

 

Hmm?

 

like, I mean, this is a React roundup. So as React developers,

 

Yep.

 

I need basically know, can I show the button on the page or not?

 

Absolutely.

 

And there's going to be a bunch of buttons on the page, right? So do I hit your API a bunch of times? How do I make sure that I'm hitting it the same way that the back end is? Cause I guaranteed like the microservice is going to be doing this as well. Right?

 

Mm-hmm.

 

I'm not. of have like the API, the AI, and the UI be like the source of truth on this, right?

 

Absolutely.

 

So, you know, so how do I just what's the game plan here?

 

Yeah, so there's kind of two ways to do this. And we see kind of uses for both, but applications architected. The most straightforward, I would say, is actually to have the permissions being returned with your data.

 

Mm.

 

So your React application's hitting your application API, your backend API, the API's fetching something from database or whatever. Along with that response, it's also returning back the permissions that server says this

 

Sure.

 

user

 

Here's

 

can

 

your

 

do

 

list

 

on

 

of

 

the resource.

 

users. You can invite a new user, but you can't delete

 

Exactly.

 

a user. Whatever.

 

Yeah. Yes. You might get view allowed, delete allow, create deny. You

 

Alright.

 

end up with these booleans. And then that goes down to your front, down to your front end. And then inside of your, your, um, react app, now you're basically conditioning a very simple conditional show or hide these

 

Yeah, yeah.

 

components based upon it. And the nice thing there, and it is again, you know, it's kind of two orders removed from the front end, but when the policies change in the Serbos instance, the Serbos instance now starts returning different results. your API now starts returning different allow or deny decisions, and then your UI updates without you having to do any work.

 

Oh, I love that.

 

And so it's a very sort

 

Hehehe

 

of clean, you're actually driving your UI from your backend and in terms of sort of conditioning, controlling things. And then if you have multiple channels, you might have a React Web, you might have a React Native app, you might have XYZ other way your data is consumed, much of your pure API, but it's all running off the same decisioning logic

 

Yeah, that's great because

 

from

 

the

 

the system.

 

UI isn't like asking and maybe offering different, like a different assessment of who this person is right in the back end. And so you make sure that those

 

Yeah.

 

two things are in sync. That's great. That's super clean. I love that.

 

Yeah, and the kind of other use case of something like serverless, this sort of decisioning engine around who's allowed to do what, is actually as well as actions upon data. Another really common use case is like product packaging, like feature control. So user A has paid for the premium package so they get all the features. User B might be on the standard package and they only get three of the five features and they have a sort of quota defined. Based on what packages and what features you get, and you have a like permissions endpoint on your API, which is again, passing through those results from the service instance. And now you in your UI layer can actually enforce or conditionally show a hide or you show a teaser screen for different features based on again, the business logic that's defined as configuration rather than code in that sort of policy use case and product packaging use case.

 

Yeah, I like that a lot because I've definitely been a part of implementations where the front end had logic to whether

 

Hmm.

 

to show or hide the button, and then the back end had different logic, whether to like

 

Right?

 

authorize the action.

 

Thanks for watching!

 

And then, you know, maybe the mobile app has

 

Yeah,

 

Different logic

 

yeah.

 

has

 

again,

 

its own has

 

yeah.

 

its own

 

Mm-hmm.

 

check so it can get chaotic pretty quickly. So I like the idea of just consolidating it all in one place. It's an interesting idea.

 

And there might be other things that you need to send. Oh, today it was account balance. And now we're adding some other

 

Mm-hmm.

 

conditional. And so you would have to, the UI would have to go and like, oh, wait, hold on, there's new stuff to send, blah, blah, blah, blah. This is all contained. I love that. That's great.

 

Yeah,

 

Mm-hmm.

 

yeah. And yeah, there's some sort of further, some sort of future feature sets we're working on to sort of streamline the in-browser policy checks. Because not all things necessarily require a round-trip to the server. If you're just like conditionally rendering buttons and you've already got the data in browser, for example, for a detail screen, you can maybe save a round-trip and there's ways of working on the moment to actually do like embeddable authorization as a module inside of your front-end stack. based on the same source of truth without having to necessarily return extra data from the API, but that's coming soon.

 

I'm interested to hear more about the testing that you were talking about earlier

 

Hmm.

 

because I'm very familiar with writing unit tests or integration tests inside of an application using JSON and things like Jest or different testing frameworks. So how do you test servos?

 

Yeah, so you have your policies, this resource type, these are the actions, here are the conditions that must be met for each action to be allowed. And then in a very similar format, and it's a YAML definition, you define some example principles, some example resources, and then Serboss will actually go and test every combination of resource and principle and action, and do a full matrix testing. So you end up with that grid, principle resource, for each and then you simply say for a page for resource one, allow every action read should be allowed, action delete should be denied, action create should be allow and server will actually run all those iterations through your actual policies and give you a test output very similar to what you get from Jest and other testing frameworks that says this test passed, this has failed, here are the things that you're looking at there is when you do evolve your business logic, this will be there to kind of catch when things maybe haven't changed as you expected and you now may have accidentally stuck a wild card in there and god forbid everyone has access to do everything. This

 

Ha

 

would catch

 

ha.

 

things early on and you can fix them before you go anywhere near production.

 

Nice.

 

So I'm curious, Servos is open source.

 

Mm-hmm.

 

What was the reasoning behind that decision and how does that end up working out from a business perspective?

 

Yeah, yeah, we get asked this a lot. And for, you know, it's a very obvious question when you look at something like this. So our view of the world, and this is from our previous experience of various companies is for something like this, 99.9% of our competition is a developer going and writing

 

Yeah,

 

that

 

yeah.

 

that logic block themselves and

 

Yep.

 

you

 

Uh huh.

 

know, you end up writing it five, six, seven times you go over and over and over again. So our view is let's get the core the engine of service, something that is as for a developer to just pluck up the shelf, plug into their app and not write that logic themselves. So that's why we've taken that approach. You know, it's Apache two license. You can use it as and where you wish. You can fork the code if you want, you can embed it. It's completely open that way. Because we just want to make sure no one has to reinvent the wheel of authorization. Because really that's what you learn from doing over and over and over again. So that's how we've been set up and how that affects us kind of as a business. And we're venture backed. We've got some great VCs backing us on this and we're very fortunate to have that backing. But where we're going with this is, the core is the engine that's gonna power everything we're doing. So services, a business, where we're going next is actually, as I was saying earlier, the actual requirements of authorization aren't with the developer, they're with a product owner or product manager, so all the parts of the business, who aren't necessarily gonna be happy about living in YAML files or writing tests and those sort of things. So

 

Ha ha ha.

 

using the server's core, what's out there today as the engine and the component that is the enforcement of policies, we're building a commercialized management layer that sits on top, a control plane, as it were. So this will be a UI-based workflow where you can start bringing maybe those less technical people in your team to actually start defining and managing policies through a UI, which can be much more user-friendly, let's say, living in Yama files and then a whole suite of tools around that to support it. So things like running the tests and manage CI pipeline for compiling and distributing those policies to all your service instances that are running out in your infrastructure and tooling around letting you know the impact of a change. So based on this change you're proposing, previously where you had 5,000 actions allowed, it's now going to be only 3,000 actions allowed and these kind of things. And there's a whole kind of roadmap we have out around when it comes to compliance and regulatory needs, making sure that you have the

 

Thanks for watching!

 

proper audit logs and audit trails and UIs for actually inspecting those. Having gone through ITO 27,001

 

Oh,

 

compliance

 

ouch.

 

a few times and being the guy that got dragged into a room every year in the basement

 

Uh...

 

by an auditor and had to

 

Tch!

 

demonstrate

 

Ugh.

 

our access controls. Yeah,

 

Oh.

 

it sucked. So

 

Yeah.

 

we're solving for that. It's actually nice actually building a product that solves for pain I experienced myself on a regular basis.

 

Hehehehe

 

Yeah.

 

But everything we're building kind of in that world will sit on this open source core. So there's no special hooks, there won't be a commercial fork of servos, it will be a layer that sits on top and the interface it speaks over is again, kind of be open source. So it was the self is written go, it's gRPC, protobuf definitions for everything. So the exact same interface that we'll be using to build the service control plane, you could hook into yourself integrate it with your existing controls as well.

 

Hold up, do I have to talk to your PC?

 

Thank

 

If you're in no

 

you.

 

JavaScript, we have SDKs that kind of hide all that abstraction

 

Oh,

 

away for

 

God.

 

you. There's an interface, there is a

 

Thank

 

REST

 

you. Bye.

 

API layer on top of it as well as the gRPC

 

Sorry,

 

system.

 

I just do gmpc every day. I'm it hurts literally hurts

 

The core the core API is GFPC, but there is a rest layer on top of it

 

Oh,

 

as well.

 

thank you. Thank you.

 

Yeah,

 

Hehehehe

 

you're welcome.

 

I think it's a super smart business model because I think you're right. It's, it's sort of in a sense, like what developers want is the convenience, but it's going to be hard to convince developers to pay for something like this. Cause

 

Yep.

 

you're always going to fight that like, but I can just write this myself with some if checks and

 

Ha

 

write like,

 

ha

 

uh,

 

ha ha ha

 

some basic stuff, but the enterprise use case is really appealing because they will pay for this to integrate with their whole Microsoft suite that they've,

 

Mm-hmm.

 

they've already got. and the user management software and the auditing and security aspects of this too, I could see a lot of potential. So I

 

Yeah,

 

Yeah.

 

think it's a pretty smart setup.

 

time will tell, but we hope so.

 

Hehehe

 

Hehehehehehe

 

And it's not just like the actual writing policies that if you're a developer, you're happy doing, you know, to run a service like this in production, you're also going to worry about log collection metrics. You need to go like the audit logs that come out, like where do you send those to if you're happy running the elk stack with elastic cache and all those fun tools, elastic, yeah, and Kibana and all that sort of stuff. Off you go, great. So this is cloud native, it exposes Prometheus metrics, it does open telemetry, it outputs standardized JSON line logs. Great. Don't want to run that yourself or don't want to run a CI pipeline. That's where we'll have a solution, where we have a solution that you can just drop in and take all that workload off you. And so you can really focus on delivering the core value of your product.

 

Yeah,

 

Yeah, I think

 

and

 

a

 

speaking,

 

lot of-

 

well, speaking as somebody who has been on products where we get a request from one of our product managers to allow extra users, and it is literally

 

Mm-hmm.

 

just putting in a new user ID into a file, that would be so great if developers didn't have to worry about that. And product managers could add new users as they wanted.

 

Yeah, I've been in your shoes on both as a developer and as a product person. And like I said, we're just trying to get as much of the workload off the team and allow you to focus on the core value of your system.

 

TJ had something?

 

No, I'm just looking over the... It's super interesting. I just really like the model. So I'm just perusing your documentation.

 

Hehehe

 

Hahaha

 

I like your logo quite a bit.

 

HAHAHAHA

 

I...

 

We

 

It's

 

get that

 

cute.

 

a lot.

 

To take a turn from the serious authentication

 

Wait, wait,

 

talk,

 

hold on,

 

if you're

 

I think

 

not,

 

I

 

so

 

see

 

it's

 

this thing.

 

the name of the... It's C-E-R-B-O-S, so you can find

 

Yes.

 

them on GitHub pretty easily. The logo is pretty amazing. I have to know if there's a story behind this. Heh.

 

I think we haven't quite agreed on a single story for this, but Servos, Brain, Three-Headed Dog, Serby,

 

Mm-hmm.

 

that's kind of where we landed on it. Effectively, now in our logo is our Serby. But

 

Ah, that's a great

 

that's,

 

logo.

 

yeah, that's,

 

Oh, it's so cute.

 

it's quite nice. I say we go and we go to a lot of developer conferences. I'm going to be at Cloud Native Security Con next week. In fact, depending when this goes out. summit last year as well. And I think about 50% of the people that we spoke to just came out to the booth and say love your logo. But we always have loads of stickers to give away. So

 

Yeah, oh, what? You need

 

Love

 

a sticker

 

stickers.

 

we will

 

for sure.

 

I will send you some stickers. Don't worry.

 

Oh yeah, that'd be

 

Hehehehe

 

There

 

great.

 

you go.

 

Okay, so one question that I have is if I wanted to get started with Cervos, what is your recommendation for somebody who's new to it?

 

Yeah, so we have kind of multiple avenues in depending on whether you're someone that learns by doing or learn by reading If you're a kind of a doer we have a load of different starter projects in different languages and frameworks We have like an XJS app. We have a Nux demo. We have a SvelteKit demo as well Which gives you a full setup server front-end service instance policies and you can experiment with that You can find all that on the ecosystem page on servos.dev. If you want to just dive in and start working with policies directly, we have an online playground, which is play.service.dev, which allows you to write in your browser, prototype, test, evaluate policies, and it gives you real-time feedback of the impact of that particular policy. And there's some example projects as well, like an expensive tracking application I've mentioned a few times, that's in there. And then if you're one that's more for site, docs.service.dev, and there's a multi-part getting started guide that walks you through from nothing in your dev machine to a fully deployed environment at the other end, having written policies, evolved them, taking advantage of all the different kind of functionality. So that's kind of the tool that's kind of the resources we have out there. There's a whole YouTube series as well, if you want to hear more of my voice, unfortunately. thing to kind of call out as well is the way we recommend you start introducing this into an existing project, because this comes up quite a lot, is start off with just sitting down with whoever has the requirements authorization and getting down on usually a spreadsheet, resources, roles, who can do what, and you end up with this kind of tick box and you very quickly realize that some of these are conditional. So you end up with

 

Right.

 

true, false, maybe, or sometimes in some of the cells. And that really helps everyone kind of understand a line on that and we actually have a whole guide of how to go from that spreadsheet through to actually writing policies in a way. And we recommend starting with like just one of the resource types in your system. Cause you can incrementally adopt servers. You don't have to rip out everything and start from scratch. You know, if you're building an HR system, start with just the expensive section and you have an expense resource. And take that if else logic that's in your code, replace that with a single call out for service instance, have a single policy type of expense, and then build up from there And if at any point you get stuck or you're not sure what to do, we actually run free workshops as well. We can just book on our website and you'll get myself or one of the other members of the team and we'll interactively go through your use case, build it in the playground with you all for free to help you kind of get up and running and help you start your journey on decoupling authorization from your application.

 

That's really nice.

 

Nice,

 

Yeah.

 

that's a real selling point, yeah.

 

Not good.

 

Thanks for watching!

 

So what's coming up next for Servos? What do you have in the works

 

Mm.

 

or what sort of stuff are you looking into?

 

Yeah, so on the open core side of things, we have always been kind of iterating based on the feedback. So recently we've added support for some more metrics and more telemetry. We've had a few community contributions as well around that and also kind of enhancing the types of conditions that you can do. So, you know, we recently added like hierarchies and hierarchical functions. So if you have like a nested tree of data, you can actually use service policies to kind of inspect that tree and make a decision. iteration. And I mentioned this before, we're working as well on this Serbos cloud commercial offering, which is that UI based workflow for managing and evolving policies. We are starting to test this with some of our early users, and we'll be opening up that to kind of more uses over the next couple of months. If you want to find out more, you can register interest at serbos.dev slash next. It's just a very simple form to put in, and we'll be that gives you that full end to end managed environment for getting your policies in, defining them, evolving them, compiling them, distributing them, and then getting back the audit logs and the other tooling around it. And that's, that's kind of where we're going over this year, really, to enable that and bring those other personas and other roles into the world of authorization, allowing them to own it and much more sort of self-service around it, rather than have to go and rely on developers all the time.

 

Very cool. I love the design of the whole site. I was just looking at your next site and I was also looking at your playground. It's super well done. So

 

Thank

 

nice

 

you very

 

work

 

much.

 

on that as well.

 

Yeah. Again, like everything we're doing is just making it the nicest sort of developer experience that you can. And there's, we know there's a lot more we need to do, but, um, that's really has been our focus because at the end of the day we're competing against building yourself, so

 

Right, right.

 

Yeah.

 

making it as easy as possible.

 

Are there

 

Hehehe

 

architecture guidelines on there? You mentioned that really great, basically, return permissions as part of, well, not permissions, I guess, well, yeah, permissions, I guess,

 

Yep.

 

as part of the payload. Is that up on there? Is like, hey, this is our recommended architecture.

 

Yeah, there's a lot of documentation we also are publishing at this rate. It's about a guide a week on our

 

Woo!

 

blog and different different architectures and ways of deploying servers. We're defining your policies, sort of everything from very technical through to more philosophical ways of approaching authorization. So, you know, just trying to firstly get the word out that there is a difference between authentication and authorization going back to

 

Ha

 

kind

 

ha.

 

of where we started this conversation and then the different approaches to do it and how you can sort fix your mental model of how these things will stick together and obviously doing conversations like this as well as trying to get more people to sort of figure out where this sits in their architecture

 

This has been great. Is there anything about Servos or really anything at this point that we've missed? Anything else you want to make sure to share or flag or make sure our listeners know about?

 

Yeah, there's one interesting challenge with decoupling authorization, which you don't really realize until you try and implement it yourself, which is what we kind of refer to as the listing problem. So it's all very well having a resource, you've hit some API, you've got your object, and you want to check whether you can do an action on it or not. But imagine if you're trying to present like an index page or a listing page of all your employees or all your comments or all your There could be hundreds, thousands, millions of these records in your database. And the bad way of doing it is to actually get every single one of those records, do a check for each of them, and return maybe the five or none that that user is actually authorized to access. So Serbos has something that we believe is fairly unique, which we call a query plan. So

 

Hmm.

 

this is kind of like a partial evaluation where you say to Serbos, I have this principle. So this user, this ID, these attributes, who's trying to do the view action on the resource kind of expense, for example. So you're not giving a concrete resource, you're just saying the type of resource. And this is a secondary endpoint in Serboss. And Serboss will give you back what we call a query plan, which is the smallest set of predicates that you need to apply to your data fetching layer, be it a WHERE clause or a Mongo filter, to return just the instances from your data storage layer would have permission to access.

 

Wow, that's neat.

 

So inside the Serbos engine, based on the context we have, so we know the principle, we know all their attributes, and based on the policies for that resource kind, Serbos gives you back one of three results. It says, always allow, because there's some wildcard and this person should always have access. Always deny, because there's some rule that says this person should never have access to this resource kind. Or a conditional. And that conditional is an abstract syntax tree, an AST, or conditions, that are defined in a very standardized way, this field must be equal to this value, this attribute must be true, this attribute must appear in this list, et cetera. And it does lots of deduplication and optimization in that query plan. And you'll get back into your code base, those filters. And you can adapt that into aware clause of Mongo filter, an API lookup, whatever makes sense, because it is an abstract tree. We have pre-built adapters and things like Prisma and SQLAlgomy that converts automatically into a filter, but it's abstract, you can plug it to anything. as far as we're concerned, the only way you can really do scalable decoupled authorization, because you're only gonna be fetching from your database or your data storage, the instances that that user would have access to, still based on those policies which are being managed by your product team, your product owner, in a decoupled kind of approach. And that is a component of Servos, the query plan, which truly helps you build a scalable, stateless authorization architecture for your systems.

 

That is very cool.

 

Quite tricky

 

Excellent.

 

to build.

 

Hahaha

 

Ha ha ha ha!

 

Well, Alex, this is, this has been a lot of fun and I'll just encourage people. If you, if you, even if you have no interest in auth authentication or authorization, you have to go to servos.dev just to look at the, just to look at the logo

 

Ha

 

and

 

ha

 

I mean, if you do have authorization and authentication needs, or I'm sorry, I should know this by now, if you have authorization needs,

 

There we go.

 

you should check out

 

Right.

 

servos.dev

 

Don't mess

 

is

 

that

 

really

 

up,

 

this

 

man.

 

good. I it's

 

I'm

 

yeah,

 

sorry.

 

I've been listening. check.

 

Is it like A something N versus A something N? Or is it like how many

 

Well,

 

letters

 

authentication

 

it is?

 

is like authen and then authorization,

 

Oh.

 

depending

 

Yeah.

 

if you're American or British, is either authz or authz.

 

Hehehe

 

Excellent. Well, with that, why don't we move into our picks where we just pick something fun, shows, kitchen gadgets from our around our lives and Paige, do you want to kick us off?

 

Yes, I will kick us off for this week. So my pick is going to be a portable monitor screen that I actually got for Christmas. And I had the chance to take it with me on a trip last week. And it is from Amazon and it's called the Arzopa, A-R-Z-O-P-A, portable monitor. And what's so nice about it, cause I actually got this recommendation from a coworker who brought it on a work trip, is that it is, maybe it's half a pound so it's like eight ounces or something it's very lightweight it's a 16 inch monitor and it connects to my MacBook with just one USB-C cable it doesn't need a power source it it just plugs in and it's pretty much good to go so you know if you're a person who travels at all for work or you just want an extra monitor because maybe your laptop screen is a I would recommend it folds up. It has a cover. You can kind of jet the cover out so that it will actually hold the monitor up or make it stand up at different angles. It's really nice and it's not extremely expensive like some of the ones that I've seen. So it's maybe 150 to 170

 

Oh, that's not

 

US.

 

bad. Yeah,

 

Yeah,

 

that's not crazy.

 

it was really reasonable compared to some of the other ones that I've been looking at in the past. So, you know, if you want something like this, I would definitely definitely say check it out. It was pretty handy to have and it was very

 

I bet.

 

easy to get started with.

 

Does it come with a cover to like protect the screen or?

 

It does, and the cover actually has little hinges in it, so when you're

 

Huh?

 

using it, you can just kind of unhook the cover, because I guess it's probably magnets that keep it in place, and then use that as the stand and just have it at different angles.

 

I'll have to check this out, because I always get annoyed. I'm a multiple monitor person, but

 

Oh,

 

obviously

 

definitely.

 

Ha ha ha.

 

with traveling, it's like,

 

It's hard.

 

historically, you've just been kind of out of luck. So I'll have to check

 

Right.

 

this out.

 

It's like you always want, you always imagine, I'm gonna work in the hotel, you know,

 

Mm-hmm.

 

after

 

Yeah.

 

the day, and

 

Yep

 

it's like, and they get there and you're like, oh, I'm gonna laugh, oh god.

 

Yeah,

 

I'm just waiting

 

and you

 

for

 

hunch

 

the

 

over

 

AR

 

your

 

glasses.

 

tiny monitor.

 

Yeah...

 

Yeah, put on the glasses. I've got monitors everywhere.

 

Ahahaha!

 

That's the future I want.

 

That would be cool.

 

Jack, what picks do you have for us?

 

Sure. So I've been obsessing on cleaning my desk and getting it with absolutely nothing on it, like the

 

I'm gonna

 

zero

 

go to bed.

 

desk thing, except for like monitor mounts and that sort of stuff. And that has, I've involved now a lot of 3D printing. So I've been like 3D printing

 

not.

 

brackets for my headphones and all of that

 

Cool.

 

close off. But of course nothing off the shelf matches my stuff. So I need to create it on the fly. And like I've just, I was going around trying CAD tool for those free, you know, and it's always like, it's whatever, there's a whole bunch of things. And I finally found one Autodesk 360, Fusion 360. Turns out there's a free, it's free for you, just basically personal use for making like a headphone holder or whatever. And it's just great. It's really fun to actually make some model on your computer, just like take out the calipers and figure out how to make it, right? And then draft it up. an hour later, it's in your hand. I think it's just so, if you've got a 3D printer, it's just so cool. So, been really geeking out on that lately. And now my desk is like perfectly clean. It's great.

 

So are you designing like hooks? Like you say headphone stand, is this like mounted under

 

Yn ystod y cyfle, mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

your desk or?

 

Well, I've got a boom arm

 

Mae'r cyfle wedi'i ddod yn ystod y cyfle.

 

that holds my microphone, you know, so

 

Yeah.

 

I might as well use that, you know but to clip onto it, you know, was kind of a pain because it's got a, you know, it's a circle, right? So I ended up like creating

 

Okay.

 

like a thing that would wrap around a circle and then kind of come out and then you'd hang your headphones on that. Very nice.

 

Cool.

And that way, this is one, I mean, there's like everything, you know, I've got my record, my video

 

Yeah.

 

recorder, all of that stuff, you know, like my desk was barely messy.

 

It's the life of a YouTube superstar, right? That's

 

Ha ha ha

 

the downside. You have so much stuff,

 

Hehehehe

 

yes. Yeah.

 

ha ha ha! That right.

 

As long as it's out of frame, it's okay.

 

Yeah,

 

Yeah

 

no kidding. Yeah. Although so many people are doing like the in like Alex has got the big mic. Well, everybody's got the no actually page. You don't. That's good.

 

Yeah.

 

Yeah. Oh, there you go.

 

Yeah,

 

My yeah. Page

 

It's just

 

is right below.

 

out of frame.

 

Yeah. Just

 

Yeah.

 

outside. There you go. Nice.

 

things you gotta do for audio quality.

 

Oh yeah.

 

All right, my pick for this week is gonna be National Geographic and specifically

 

OOF their newsletter, which my wife got me interested in because she had gotten into it. And basically, it's a newsletter with all their articles that they put out, which I found are incredibly high quality and very interesting, especially if you're into historical things. They do a lot of like, what's the latest going on in archaeology and different animal studies and whatnot. articles a month and then you can sign up. That's sort of their business model. You can sign up for a monthly subscription if you end up reading enough of it. But even if you just sign up for the free newsletter and just like peruse the headings, I find it pretty interesting. Although you can lose a lot of time that way. So if you're trying to avoid spending time reading random articles on the internet, maybe not for you, but if you're

 

Mh.

 

interested in that sort of stuff,

 

I'm sorry.

 

I've enjoyed it quite a bit.

 

Cool.

 

And Alex, what picks do you have for us?

 

Yeah, so going on what Paige is saying about traveling and having second monitors, etc. I spend way too much time on airplanes and I think it's something like 50 something flights last year.

 

Oh

 

And

 

no.

 

one thing that kind of annoys me is I've got my AirPods or I've got my like Bose headphones, but occasionally there's actually something I want to watch that's on the in-flight entertainment thing. So my pick is something called an RHA wireless flight adapter, the headphone port on the in-flight entertainment and then you connect your Bluetooth headphones to that.

 

Ooh,

 

So I can use

 

Yeah.

 

my Bose

 

Nice.

 

headphones or

 

that

 

my AirPods

 

is clever.

 

to plug in to Bluetooth to this box, which then this box is plugged into the in-flight entertainment and it's still a wireless etc etc. Chargers of USB-C, it's a very tiny little box, fits my backpack and yeah you can enjoy decent the airlines little tiny, you know, $2 headphones

 

Hehehehe

 

that they give you so you might actually be able to hear the film.

 

I'm such a klutz though, I foresee myself like, kind of like knocking it off or ripping it like I'm trying to get up to go to the bathroom or something like that. I mean the seats are always like so tiny.

 

Yeah, the nice thing here, this the box itself is battery powered. So it literally just slides in and just sits kind of flush against

 

Oh

 

the seat.

 

wow. Oh, okay. That's cool.

 

And it's got battery in it. You just charge it with USB-C.

 

nice.

 

And so you are truly wireless. You're not tethered to your seat. So when you know, I'm the same when you do get up to go to the bathroom or whatever, you're not

 

or you could

 

yanking,

 

actually still be listening

 

yanking

 

to

 

the

 

your

 

headphones.

 

show.

 

Well, all that.

 

Yeah, I mean, why not? Really,

 

When you're queuing

 

you know,

 

up.

 

right, exactly. There's always a line for the bathroom.

 

Yeah, indeed. One of my various travel must haves.

 

That's

 

cool.

 

cool.

 

Well, excellent. Alex, this has been a ton of fun chatting. My last question for you is if people want to follow you, whatever the case may be, is there a good spot to go for that?

 

Yeah, absolutely. Yeah, follow me on Twitter if that's still around by the time this comes out. I'm just at Alex Olivier.

 

Thanks for watching!

 

It's A-L-E-X-O-L-I-V-I-E-R. And yeah, happy to chat

 

Excellent.

 

there.

 

Well, it was awesome chatting with you and see everybody next week.

 

Okay, thanks.

 

Bye everybody.

 

See you then.

 

Bye.