 Hello, everyone. Welcome to Cloud Native Live, where we dive deep into the code behind Cloud Native. I'm Annie Talvaso, and I am a CNCF ambassador as well as a lead marketing at Vision, and I will be your host tonight. So every week, we bring a new set of presenters to showcase how to work with Cloud Native technologies. They will build things, they will break things, and they will answer all of your questions. So you can join us every Wednesday to watch live. So this week, we have Alex here with us to talk about modernizing authorization. I'm very excited for this. As always, this is an official live stream of the CNCF and as such, it is subject to the CNCF Code of Conduct. So please do not add anything to chat or questions that would be in violation of that Code of Conduct. So basically, please be respectful of all of your fellow participants as well as presenters. With that done, I'll hand it over to Alex to kick off today's presentation. Great. Thanks, Annie. Hi, everyone. Very happy to be here today. Speaking about authorization and SerbOS, which is an open-source project that helps you decouple authorization out of your application code and into something that's a bit unmanageable and scalable. So just to kick it off, make sure we're all on the same page. Today, we're going to be talking about authorization and not authentication, which are two terms that sound very similar, and we all shorten them as we do as software developers to things like Auth N and Auth Z. But they are two very different concepts. So authentication is about really identifying who the user is. They provide some credential, you get back some sort of signed token or something on JWT that certifies that person is who they say they are. Then authorization is about, okay, now you know who the person is, what are they actually allowed to do inside of your system? So this being CNCF, I'm sure many of you are familiar with Kubernetes and things like RBAC inside of the Kubernetes system and RBAC being role-based access control. That is one type of authorization. Today, we're going to be talking about application layer authorization. So once you've got an application, you have your end users. Those users might have different roles. How do you actually manage what those users can do inside of your application in a way that's manageable, scalable, very cloud-native in the way it's deployed and managed, very Kubernetes-friendly, et cetera. To do this, we're going to go through a journey of actually implementing a very simple application with no permissions and go through the growing pains as a way of implementing authorization and then demonstrate how you can use the open-source project Serbos to do this. If you want to dive straight into Serbos, you can find it up on github, github.com. I think we'll put the link in the chat shortly. There we go. If you want to go to dive straight in or serbos.dev is the website. So let's go and kick it off. I have a very simple Node Express server here and we are going to basically go through and implement a create-read-update delete as well as some kind of application-specific permissions. Now to quickly run you through how this application works, it's going to be a simple service. It's in sort of Node TypeScript. That's just what I'm most familiar with and because we're going to talk about authorization and not authentication, we're doing some basic fake authentication where we're passing through a header in the request of a user's name and then behind the scenes we have a database of these users. So this would be usually coming from your identity provider or your own application authentication system. Maybe it's a no-auth exchange. Maybe you've got a JWT token. But each user has an ID. We have some rules. So these could be like claims inside of your token even. So in this case, we have users, we have admins, we have managers. And then each user has some attributes. In this case, we have a couple of attributes around what department they belong to and what region they belong to. And these you can imagine in like a sort of typical, maybe like SAS type of application. These would be your users in your database. In turn, what the application does is for managing expenses. So Andy and I were just talking. We were at KubeCon a couple of weeks ago and we have like expenses that we need to claim back. So we want to submit these into our system and an expense resource inside of our system has this shape. So it has an ID. We have some attributes about it. So the owner, their ID, when it was created, who the vendor was, the amounts and the status. Is it open, approved, rejected, et cetera. So our basic API here has a few routes. One for getting an expense, one for seeing who approved an expense. We've got one here for actually doing the approval. So the person that maybe in your web UI, you've got mobile app that's hidden this API for actually doing the approval. Updating, delete, you need typical crud things. So this API is up and running and I'm using kind of postman here just to kind of show you some requests. So we have requests coming into a particular expense. I'm gonna tend to be different users by setting a different header. And in this case, all users can do all actions because there's currently no permissions in place. But from like a business process point of view, I've actually implemented the main actions and we can pretend this is updating a database and those kind of things behind the scenes. So now I'm the developer. I've gone and got a set of kind of requirements coming in from my like product team, which in this case is also me. And we wanna go and implement some roles and permissions for this. And these, oops, sorry. And these permissions are gonna be varied based on what role I have. And there's some conditions that must be met for a particular role to be allowed or not. And so we've got this ticket that comes in and we've got some rules here that says, so if the person is an admin, then they should be able to do all actions. So they should be able to do those create, read, update, delete type permissions. If they're in the finance team and the finance team is defined by someone having the role of user and in the department of finance, then they should be able to view all the expenses, view who had approved all the expenses and then they should be able to do the approved action only under certain conditions. And these conditions, sorry, my camera's gone very blurry. And under these conditions is where we start coming into the difference between RBAC and ABAC. So RBAC or Rollers-Based Access Control is the way of doing permissions where you simply check whether a user has a particular role or not. So if this admin use case is pretty simple, we wanna go and check whether the user is an admin. If so, let me do the thing. But in reality, and as we've seen by these other rules here, that we're gonna have to do some more checks. And this is where ABAC or Attribute-Based Access Control comes in. Because now we're not granting a permission just based on whether you have a role or not. We're actually granting permission based on whether you have a role and under certain conditions. So the approved expense example here is kind of a good example. So you're only allowed to approve an expense. If your role is user, the department you belong to is finance and the actual expense resource that you're trying to interact with has the status of open. So here we're actually inspecting the attributes of the permissions. And most systems that you may think or you may see of being like, oh, back in reality, I'll probably gonna do more ABAC-based logic. Because they always wanna go and inspect and make decisions based on the actual attributes of the resource you are accessing or trying to interact with to make those decisions. So if we go and take this logic and if we go and look at a, just create the implement this logic in kind of the classical way or the way that most systems when you're starting small would do inside of this view command, you're gonna start doing basically some if-else statements. So our first rule was, if you're an admin, you should be able to do all the actions. So for this view route, we basically wanna go and write a big if statement. So if the user dot roles dot includes admin, then we go and do the action. And then in this case, we're just returning the response. And if you don't match that case, then we actually wanna go and return back to that API. I got 403 saying error, action not permitted. And here we've just done the very first check where we work out whether you're an admin and that's a pretty simple one. But now if we go and look at, okay, the next case, so the finance team, your role as user, your department of finance, then you should be able to view all the expenses. Okay, so we go like, if user roles dot include user, and we go and actually look at an attribute of the user, if user attribute dot department equals finance, then our logic says, you should be able to view that expense. And we again return the response on that request. And then finally for our general user role, you should view the expense if you created it. So the logic will now be quite similar if user roles dot includes user, and we now wanna check with the owner. So our user ID must be equal to the expenses attribute owner ID field. Then we go and return it to the API response. And now we've implemented just that logic required for that view command. And now you can sit here and start iterating through all those different setups and you're gonna have to go and do this for each of these. I'm gonna flip over to an example rather than coding this all live, but you can see here we've implemented all that logic. So here's that view rule we've done with the checks on the attributes. If we go and look at the approve status, so if we go and look here, so admin can do all the finance team can approve if it's open and they didn't create it. So we're gonna look here. We are now we said admin can do it. In this case, we're just like returning some error returning the approve message. So for the case where you have to be the owner, we're checking if your user, you know, finance team the status of the expense is open and that the owner did not create it or the person making the request did not create it. So you can't approve your own expenses and make sure they're not equal. Then we return the extra expense if not returns of error and we can go and keep evolving this and adding more logic. And this is great, you know, getting started with something quick, off you go, implement that if else statement and the queues are very simple. But now if you imagine our applications kind of evolving, we now moving to microservices because we've got an SQL Nessie's cluster we've got teams building services in JavaScript teams building services and go that teams burn servings Java. When the requirements change which they undoubtedly will anytime you have to go and implement logic you're gonna have to take essentially that business logic so that that ticket we've got and take this and kind of map it into JavaScript and map it into go and map it into Java and map it into XYZ other weird wonderful language that's come along this week into your system. And this is where things start falling down because you're now gonna have to go and touch all your application code when the requirements change and you're gonna have to go and rewrite and re-implement that logic each time re-release your application having hopefully all the tests are passed and kind of hope that the logic is implemented correctly because you've had to do it in multiple languages. So what's the alternative to this and this is to move to a policy or a configuration based workflow rather than hard coding that logic in there and this is where Serbos is the project that we're gonna be talking about today that helps you kind of implement this business logic as configuration policy rather than code. So we're gonna use these playground and play.serbos.dev as just a quick sort of IDE to look at how we go and implement this business logic and then we'll look at how we then go and put this into the application. So this is a playground instance we have created. I've in order for us to actually get some real time feedback based on whether the logic is implemented correctly I've set up some example users. So these users are the same one we just saw in the application. So they have an ID, they have a role, they have some attributes and then the resource they're trying to access. Here are some example resources of different amounts and it's the same kind of object we saw. So we're working with the same kind of test data here. So if we go to go and implement a policy for our resources. So expense is our first resource. We're gonna create this expense resource. We're gonna give the name of the resource and expense and there's some example actions in here which we're gonna go modify. So our first rule again was admins can do all actions. So we're gonna create a wild card rule and this is essentially all the different rules all the different actions that users can do upon an expense resource. And we're gonna say that for all actions the effect of this should be allow. So in the case where this matches you should be allowed and we're gonna say that for this rule says for all actions if you match the role of admin the effect is allow. So this policy and these roles are looking at the request or looking at the user that's making the request in this case user and then for all actions you should be allowed and that will always match. Now if you're gonna implement that same rule that we did when we hard coded it which was sorry I did say we're gonna break things. So read or view. So how who can go and view a resource. So going back to our business rules we're saying to view so admins we already covered because this wild card will match it. For the finance team you're allowed to view it if your role as a user and your department is finance or you have to view it if you created it. Now in this case I could go and write a lot of repeating logic for the cases of both the finance team and the owner in this case for a view resource. So the way I could do this is go and set up and write that logic as an expression in here but what I'm actually gonna do is create something called a derived rule. So derived rules allows us to essentially at request time based on the inputs of who the user is and what the resource they're trying to access and set up and derive a further rules for that user for the scope of that request. And the most common example for this is an owner role. So our owner role here is a derived role that says if the parent role is user so the request coming in has a role of user and here we define a condition and here we're saying that if the request resource attribute owner ID so we're looking essentially at every payload that comes in at request time and we're inspecting down to the object and we're grabbing the own ID field if that's equal to the ID of the person making the request then we should grant that user essentially this extra owner permission at request time. Now these conditions here are using self common expression language which some of you might be familiar with. It's an open source Google project where you can get quite well very expressive with your business logic and it gives us basically ability to drive binary type logic or logic based on inputs and the inputs in this case are the person making the request and the resource they're trying to access. Going back to our use case, a case again so this finance team member is actually another kind of derived role so this person is a user but they also have to be in the department of finance. So rather than typing it out I'm just gonna go and copy this over. So now we have this another derived role that says you get or you're granted the finance role if you are a user and your department is finance and that matches this data point here. So with these two derived roles of owner and finance we can cover these cases of finance team can view all expenses and a user can view an expense if they created it, else they are the owner. So jumping back into our policy file here I'm gonna go and import those derived roles common roles and then for that view I'm gonna say you must have the owner derived role and I keep touching my trap head with my palm or finance. So now hopefully you've seen as I've been typing down here on the bottom right we've been getting some sort of live feedback as we kind of experiment and work on these different policies so I'm currently being someone that's in like the IT department so I have the admin role so I do have permission to view this particular expense if I go and look at different expenses they're gonna be allowed allowed and this one's owned by Sally so if I go and look at one that's owned by someone else so here we have the owner Frank if I go and look at this as someone that hasn't got the admin role in this case a user, in this case Sally she gets access denied so cannot do the view permission or cannot do the view action upon that particular resource that's making a request. So going back to our business logic again we have all this logic around who can approve so we're saying it must be opened the status must be opened and if they mustn't have created it is the only and you must be in the finance team to go and do the approval so what does that look like I am going to go and grab a snippet again just to say topping out and we'll talk you through it so we have another action in here which is approve and we'd say for the approve action it should be allowed if you again you have that derived role of finance so you're in the finance team and this time we have a couple of conditions in place so as well as checking that you're in that team by looking at that department attribute we're also now checking for these two conditions of if it's open and they didn't create it so here we're saying there's two conditions which both of these must match so if they didn't create it aka the owner ID is not equal to the principal ID or the person making the request and the status must be open and now if we go and look at here we're getting that feedback as we sort of go and look at different resources who can be allowed to do what if we go and look at someone that's in the finance team here they're allowed to do the approve on this particular resource because it is status set to open and the owner ID is not their own ID and so we could build up these quite complex policies of defining the authorization logic and we get to a point where we're kind of happy with our logic and we want to actually go and actually implement this inside of our application so let me jump back to another here we go I'm going to jump over to this example which is our exact same API but here we've actually implemented the call to servers so the way servers runs is a container that you run alongside your application in the Kubernetes world we always recommend running this as like a sidecar and we have Helm charts as well for any of the services, et cetera but the idea is that server's instance is running right alongside your application and so it's going to be a very fast lookup from your service to a server's instance that server's instance has loaded into it the policies that are currently defined and then in your application at the point where you want to check permissions rather than hard coding that big if else style statement that we were coding in this previous example we just make a call out from our application to that server's instance saying I have this principle so this user, they're gonna have this role they're in this department, they're in this team open for you to define they're trying to access this particular resource so you pass through the resource, it's an expense has this ID, it has this amount it has this status, et cetera and what action the user's trying to do I'm trying to create, read, update, delete view, approve, open-ended based on you to define inside of your policies so that server's instance is in this case I'm just running it locally so we've imported the server's SDK there's SDKs for most of the language out there now find it all on GitHub we connect from the service to that server's instance in this case I'm just talking to local hosts that's where I'm running it if this is inside your cluster it might be the cycle path or might be like service, stop server, stop, service, stop, cluster, local or it depends how you want to deploy it and in this case we're actually using GRPC as well again it's very focused on performance authorization is in the critical path of every request so you don't wanna be going out over the internet especially to make authorization checks so this is designed to be all local can be completely air gaps there's no external dependencies and this server's instance is you talk to it from your application then going down to the actual request handlers where before we had these big if else we had these big if else case switch style blocks in the server's version we simply make a call to it about server's instance so we've set up server's SDK we've got our expense and we pass into it the principle so in this case the user that made the request the resource, so we're telling it what kind of resource and we're passing in that full object of about the resource that user is trying to access and what action they're trying to do in this case view and further down we have like the approve action and here we have the update to the et cetera then what comes back from Serboss is for each action a very simple boolean is this allowed yes or no? So what's going on here behind the scenes request comes in from your end users to your service your service is grabbing that user's identity from your IDP or the token is grabbing the resource that user is trying to access from your own application database so you might be doing the SQL query you might be going to hit some other API you might be calling another service and then rather than in the application code doing that big if else case switch style statement we pass that context from inside your app to that Serboss instance running right alongside it saying I've got this principle trying to do this action on this resource and it was should it be allowed or denied? Inside a Serboss, Serboss has taken that input of principle resource and action evaluating your policies and then simply returning back and allow and deny decision which means you only have a single if statement now inside your request handler which says is this particular action allowed or not? And in this case we're saying if it's not allowed then we return some sort of error if it is allowed we then go and actually do the action and return back on the API what should happen? So at this point we've just gone and basically replicated what we had hard coded and here I actually have the policies similar to the ones we had in the playground with all that this is logic defined et cetera and I'm gonna go and start up a Serboss instance so I'm gonna start Serboss this is now running locally in my machine our API is now up and running and I'm gonna use Postman to go and hit it and here we're getting kind of back decisions and there we go I got a action denied response for trying to get this particular expense expense for which I just know from the implementation is that not one that this user in this case Sally is allowed to access and if you actually go and look in the Serboss logs we can confirm that that request has been denied Serboss itself creates full audit logs so every decision that the Serboss instance makes will go and actually log that and you can send those off into your own log collection system for kind of reporting and analysis and it's one of the kind of the side benefits of decoupling your authorization logic out into a standalone service such as Serboss and in regardless of where your application permissions or regardless of where your architecture you're doing authorization checks come from because they go through a Serboss instance it will always be logged and you have that cleaning system audit log of exactly what happened so now here's when it gets kind of interesting so because I've done the work now of decoupling my authorization logic out I've updated my application code to call a Serboss instance what happens if the requirements change so we have another ticket or another issue here from said annoying product manager me and we're saying we've had some client requests and we want to have a different option a different permissioning type role inside of the system and the business logic for this particular example is we no longer want to have a single finance kind of role we want to break it between finance team and finance manager and the business logic says that if you're a regular finance team member you can only approve expenses up to $50,000 if it's over that you must be a finance team manager and if you imagine we had this all hard coded before we'd have to go and update all that if else case switch style logic in not just this service but every other service that relies on the kind of those permissions to handle this and that logic is going to be spread because across potentially many request handlers across many services and many numbers of languages because we've done this decoupling there's now one place and one source of truth for what our permission logic is so let's now actually go and implement this finance manager role and we're going to do this without touching our application code we're purely going to be touching our policies so first thing first we want to work out who is a finance manager so in our IDP, in our like user database we now have a new user role which is manager so if you're using some self hosted authentication system you're making a managed service for your identities or directory you imagine you might have some attributes about your users like before we're now adding this manager role to our users in our kind of identity provider and that's passed through to the application in the token or wherever you get your credentials back so Derek here is now our manager in the finance team and thus he should be able to do the approvals of $50,000 or more whilst Frank here is just a regular user in the finance team so he shouldn't be able to approve over $50,000 so let's go and look at our policies as before we're actually going to create a derived role here just to kind of simplified some of the logic so we now have that finance derived role which we had earlier which just checks if you're a user and in the finance team whilst our finance manager derived role here is a parent role of manager so that's coming through from your IDP so we're checking whether that exists and your department is finance so now we're creating this derived role at request time for every request that comes in and in our results policy we want to go and look at the approval logic so here we have our approval logic as before but now for our regular finance team members we have a new condition which says that it must be less than $50,000 the amount field so the amount attribute of the expense that this user is trying to approve must be less than $50,000 in this case and if you try and approve it and you're just a regular finance user and it's over that amount this will fail and you'll get permission denied as you kind of expect based on our business role so that now means we need to go and create another case another rule for this so we're gonna say also for the approved action we want to allow this if you have the derived role which we just created of finance manager and in this case we're gonna have essentially the same conditions as before but we're gonna take away that $50,000 sort of limit so just to recap we've added a new derived role of finance manager where the user has the parent role of manager and they're in the finance team we've added a new rule here that says the action should be approved excuse my typo the action here will be allowed if you have that finance manager derived role regardless of the amount and we've added the condition here which says to do the approved action in the regular finance team the amount must be less than $50,000 so because we're a big fan of the GitOps style workflow we're here at Serbos and being kind of a player in the cloud native ecosystem everyone loves GitOps we can actually go and write full unit tests against it which I won't dive into here but I'll point you to the documentation for this but we've written some examples of conditions that we met and example inputs of resource and actions to check that your policies pass I can go and run these tests locally so we have CLI tooling say look it's telling me I've got a typo in my policy which I do somewhere there we go derived roles run this test again still got another role bear with me oh that should be a list that's why there we go there we go and all my tests are passed beauty of tooling I'm actually going to push this change up so update to add manager manager role so that is now all going up so depending how you deploy your Serbos instances you can figure where it gets its policies from if you're following the high call kind of get up style workflow you know imagine you have your pull request you have a whole CI pipeline running in there and then your Serbos instances themselves are going to pull down that change from your Git repo on some sort of basis for simplicity I'm using the Serbos cloud version here which is doing the builds for me we can see here that a new build was generated 18 seconds ago we can go and see it how many tests are passed the status of all the tests, et cetera kind of the typical things you would get in a CI pipeline and that Serbos instance that I am running I am running is pulling down that update and is now serving decisions based upon these new policies just to show you how this kind of works I'm just going to create an empty commit just to show you kind of the workflow so that's pitched up Serbos cloud goes and builds it and the CI pipeline is running and in this case that update gets pulled down straight away based on the new commit because all the tests are passed because the policies are valid are loaded into memory and the Serbos instance or instances that you're running because you can run many of these in say, cycles we'll go update to that latest logic and so if we go back to our application and all things being right we have our new user if we go and get expense number four sorry, expense number three sorry as Frank this is an expense that's 80,000 Frank here is our regular finance team user so if we go and see whether he can go and do the approved action on it action on permitted if I swap to a user that we set on our database as the finance director can he do the approved action? he can so what we just demonstrated is the business logic for authorization has been updated of a change in policy and pulled down to the Serbos instances without me having to touch the application code so my application code going back I have not changed this lookup Serbos is receiving the principal, the resource and action from the application Serbos is then evaluating whether permission should be allowed or not based on the current policies that are live and returning back as the same allow on the decision back to my application code and I don't need to make any changes here in terms of how that's handled it's simply saying should is the approved action allowed if yes we then go and do it if not return some sort of error and thus we've now decoupled that authorization logic out it's now in policy we can have a full get up style workflow where we have a CI pipeline that runs those tests as you kind of saw and changes can be reviewed, approved tested and then deployed out and now you can update add roles change requirements for authorization or via policy rather than hard coding it and so every service that now checks permission via Serbos gets that update without you having to redeploy retest, recode all that logic so just to wrap up and point you to a few resources if this says set any light bulbs off or answers maybe a pain you've had in the past where you kept getting requirements changing for authorization do go and check us the Serbos project out github.com.searchserbos play.serbos.dev is the playground that we've been be showing you today and then Serbos.dev is the website which is a lot more about this everything's open source Apache 2 license you're free to go and use it as you wish we've got users both big and small now using this project and love to kind of chat more and answer any questions you may have you can book a session through our website if you want to chat with us and hopefully see you around perfect so time for the Q&A then so now is the perfect time to send in your questions if you have any obviously you can chat with Alex as he kind of said there in the future as well we all the different means that he said there but if you have any questions now you can type them into the chat and we'll get them answered while we wait for those questions to hopefully roll in if anyone has any I would have a question so we spoke here about like the modern take on authorization and whatnot and covered a lot of different topics but what would you say are the next steps for Serbos is there something that you can kind of sneak be from the product roadmap going further or so forth yeah absolutely so Serbos we really focusing on the developer experience so I mentioned quite a few times that the tool in the CI and sort of pipeline you can set Serbos we're constantly iterating and evolving on that to make sure that you have not only a kind of smooth pipeline for getting policy changes out but even up front in terms of making sure that the IDE and the workflow for actually writing policies in the first place is slick so recently for example we published the schemas for those policy files you've seen so you can light up your IDE with intelligence and also complete and those kind of things we have the Serbos CLI tool which allows you to run those tests and run a server locally etc and then if you don't want to manage a pipeline yourself we have the Serbos cloud which we announced at KubeCon actually which is a managed pipeline that deploys and manages and tests and deploys policy changes in a synchronized manner across all your instances and built on top of the open source source engine great and then we have a question from Sharon they ask how to integrate Serbos with API gateway great question now we get asked this quite a lot because there's a hot topic right now particularly also the service mesh side of things as well so where Serbos sits is in the application layer your top level kind of API gateway or type access is possible to write kind of an extension and have your gateway call to Serbos based on purely the request parameters so in that case the only context you'll have about the user and the resource is maybe the authentication token a JWT and what route to the channel request so you could pass through the URL the headers those kind of things and make policy decisions upon that and that totally works and there's users out there doing that today where we generally see Serbos implemented and the kind of the place where we see and Serbos implemented the most and kind of how we designed it is now actually inside the application so after the gateway someone's actually now in the context of say a request handler where you know much more about the user because you can go and fetch state from your own user database we know all the information about the actual resource they're trying to access so you can go and fetch that from your own database you have full access to all the attributes about that particular resource and this is where that RBAC, ABAC kind of story comes in because in most cases the permissioning as we saw the examples here is actually more about the specific attributes if we take the example of the action should only be allowed if the amount is less than $50,000 if all you have is the URL you're not going to be able to kind of derive that so inside of your application level kind of permissions and request handler is when you have access to all that state and that's generally where you would implement Serbos to do those permission checks because you can pass through all the states from the request plus your own kind of application state to Serbos and use that as inputs to make decisions upon inside of your policies Perfect now if anyone has any more questions send them in and I would have now a question from a bit of a different direction kind of I love talking about people with this so what do we say since we've not been talking about authorization and RBAC and whatnot do you have any estimation or any hopes for how this field will evolve in the future? How do what would you like to see coming up? Yeah, great so when I kind of look at this space and kind of where Serbos sits we're in an environment that isn't in isolation you know we have the authentication piece and we're now in a world where there's really kind of good standards around authentication you got OAuth2, you got JDBT's as a kind of token exchange that's kind of a very kind of standardized place authorization today is not quite there it's still quite open for how you go and implement it and this whole concept of decoupling is actually still relatively new so really the big focus that we've been with this project for the last 18 months, two years since we open sourced it is like how can we get everyone comfortable with this idea of decoupling the authorization logic out of the application into a way that's far more manageable and scalable and easier to kind of reason with because it's not deeply coupled to your application code and that's kind of a space that there's many different ways of doing it there's lots of interesting approaches the different access models and we think Serbos is a good fit for kind of your typical SAS, B2B applications or internal services and that's kind of the use case we've built upon but there's also a third bit which is the audit story, the accounting story so authentication, authorization and accounting and generally what that looks like is the audit looks so now you've authenticated someone you've authorized them how can you actually keep track of what they've done or what they're doing and that's why the audit kind of story was built into Serbos in day one is really capturing the output at this time and this principle showed this section of the resource and I think there's a whole interesting ecosystem and future around what do we do those audit logs from an application level to actually make much more informed decisions or around how we should reason up policies or maybe users are over or under permission and those kind of things and then I think there's great opportunity and great space there to really innovate and build much more interesting projects and that kind of help with that accounting and audit story. So good, a lot of answers and then we had Shubma asking about the recording and don't worry, the recording will be immediately essentially available in for example, CNCF YouTube so you can check that out from there I think it's under the live streams tab there so CNCF YouTube is the place to go for that and then Alexander also had a question is it possible to do a partial check as OPA? You ask server service which resources the user has access to and it returns a list and so the service consumes this list? Yeah, great question I think this is the first sort of stumbling block people run into when they want to decouple the authorization logic because if you have a database or records of millions of records and you want to just show say on a listing page those ones that a user would have access to you're not going to go and fetch all million records send them to an authorization service just for it to return maybe the one that record that user might have access to highly inefficient. So Serbos we have something called a query plan where you say to Serbos I've got this principle trying to do this action on this type of resource and what Serbos gives you back and I'll give you a live example here is a query plan so query plan from Serbos is a abstract syntax tree in AST of conditions which are computed live based on the policies that are currently implemented and this condition tree can then be mapped into something like a SQL ware clause it can be mapped into a Mongo filter it can be mapped into some filter on an API call somewhere because it's agnostic to any particular data storage technology and my background's from like high throughput low latency systems where we store data in very specific databases for very specific reasons mainly for ground performance so our data wasn't all in one big Postgres database it was split between HBase and Redis and some SQL service so we haven't coupled the Serbos query plan to any particular storage technology it is abstract and a very predictable and well it's an abstract syntax tree of conditions basically which is dynamic based on who makes the request and you'll get a different response back and this is built into our playground where you get a different set of conditions so for this person try to view the resource the expense resource kind here are the conditions that I would then convert into a SQL query and we have plugins for like Prisma, SQL Alchemy as kind of the two common RMS but we've had users that map this into also some weird and wonderful storage filters and this simply says that the use particular fields must be of this particular value and Serbos behind the scenes is doing as much optimizations as it can to return the smallest set of conditions that you apply to your data fetching layer just to return the instances of that resource so that user would be able to do that particular action too Great and then I think there's no more new questions at the moment but final call if someone's typing away send the questions in so while we see if anyone's entering it Alex do you have any final words or anything that you want to kind of mention at this point? If you found this interesting or if you feel like this is something that is a pain you've had if you had to go and deal with in the past please go and check us out Serbos.dev is the website github.com slash Serbos as well for the EPO as I said, everything's open source go and use it we have users ranging from small startups to multinational enterprise companies at this point and we're here to help we have a Slack community if you want to jump in there we can ask questions we're a globally distributed team so there's always someone online and yeah feel free to reach out to me on Twitter or email through the Slack community and always happy to chat about authorization how we can make people's lives easier Perfect I think making people's life easier is a great note to end today on and so thank you everyone for joining the latest episode of Cloud Native Live it was great to have a session about modernizing authorization we also really love the questions and the interaction from the audience always happy to see that and in the coming weeks we have more great sessions coming up and thank you for joining us today and see you all next time