 My name is Roscoe and I hope you hear me well I'm the head of DevOps at permit IO and today I wanted to talk with you about policy as code about How it can actually change your your way that you basically look at your security all across your stack so starting from the DevOps from the infrastructure going through the back end maybe databases and also the front end and We will start by actually understanding what authorization authentication access control means. I will start by scaring you a bit Why it is such an important thing and then we will understand how we can solve everything by policy as code It's not that simple, but I will I will try to convince you that it's simple. So let's start so First of all, welcome everyone to kube.com Paris. I hope you are doing Good time here for me. It's amazing. It's good food good weather. So I'm doing good and there are a lot of I don't know interesting companies here Everyone is trying to integrate AI inside their product. So it's nice to see actually how it's getting traction I don't know getting some improvements through the time and eventually We all have one goal doesn't matter if you are DevOps doesn't matter if you are data analyst developer product manager we all have one simple goal and it's to get our application to production, right and That can be simple, but through the time we understand that are a lot of small things that I will make a life really miserable But we did it. We deployed our application to production. We're super excited about it and now we need to understand What else we can just you know, we made it but unfortunately, this is not enough and Most of the time we understand that Deploying and you know making an ICICD making a well-performance code it's not enough and You guessed it, right? We always have this small pull request that says urgent security fixes Starting from vulnerabilities in our code or I don't know maybe other cloud misconfigurations and stuff like this and This is nice, but this is not solving all the security issues that we have and We can talk about security again Around the code maybe in the docker image or something like this But we can't forget the security inside our application so the first step that I'm going to talk about or the fist the first thing basically is authentication and authentication is Something very very important because if you think about it Maybe our code is very secured, but maybe everyone can access my application Maybe it's you know free free for all and you know just come in do whatever you want, but no we need to first build this first gate of Who can access my application and for this we have many tools many open sources. I won't Say the names, but you can guess it and you can understand that today Authentication is something that you can just take maybe pay maybe Deploy it yourself using open source, but you can do it yourself basically using other tools. So it's very nice But this is really the first thing so authentication will be kind of the first gate and then Okay, you are logged into my application, but what can you do in the application? that's a very important question that we need to solve and Think about it. Maybe I'm developing an insurance application So what will happen if you log in and see other customer or other users? Insurance documents or something like this may be a medical application. So this stuff should be controlled somehow, right and The next step will be authorization So this is really the difference between authentication and authorization authentication again is just the first gate Understanding who is the user and the second step will be understanding what the user can do. So It all ends up always like this, you know, just create a ticket for this We don't have time doesn't matter if you're a startup doesn't matter if you're a big company It's always let's just build something very very easy Just create an admin role and everything will be alright but most of the cases It's not good enough and we will create a ticket, but unfortunately we will also have to implement this authorization layer someday so I'm not here just to Give you an attic about what is authorization I'm here. I'm here also to make you understand that authorization and access control is very very important So all us for those of you who don't know it's the open-world wide application security project I'm also I need to read it because it's too long But they released every few years kind of a nice top-ten list of the risks of application security sometimes they release an API security risks or something like this something more specific But this is the really the Kind of the general list. So you can see in 2017 and they basically claim that broken access control It was in the fifth place, but it it had a good place I think and authentication you can see it was in the second place And you can see that in 2021 it became not only the first place We will see in a second that it it got many places not only the first place, but It really went from the fifth to the first. So it's not only a risk it's a very very impactful and it's very very important to take care of and Also, you can start looking at the least and try to find authentication Authentication got a new name on the seventh place. It's called identification and authentication failures I don't know why they call it like this But basically what I understand is that authentication is not such a big deal right now Because we have these all of these products and tools that I showed you that's great And now we need tools also for broken access control broken authorization, right? So Also in 2023 they released always released a top 10 API security risks. So this is more specifically. Oh That's interesting because I can see it Okay Interesting That can be my next talk maybe Anyway on that top 10 risks of API security risks They said not only that the first place will go for broken object level authorization, which is me They gave also the third place which is broken object property level authorization and the fifth place So they gave it many names. I don't know why but it got three places in the scary list of You need to take care of this right now. So After scaring you a bit, I'm going to scare you a bit more So this is these are stories about companies that did authorization and access control not good enough And I can tell you a secret Everybody's not doing it enough good enough, but uber admits covering up message Kind of data breach that caused by broken access control mail chimp It was act again again by access broken access control Microsoft extension servers are suffering from zero-day exploits I think few months after or before it happened for them again. So poor Microsoft and First American and Cambridge Analytica all of these stories. I basically Me trying to scare you that you need to do authorization better. Okay, that's that's kind of it and This was the scary part and now I'm going to tell you how we can do it together a bit better So starting by introduce myself. So I'm Ross Cohen. I'm an interpreter from Israel. I'm 26 years old You can see all the things. Yeah, so I'm a web server. I'm a best player I'm passionate about traveling and food. That's why I love Paris And I have eight years of experience in development DevOps platform. I don't know you name it and That's kind of it. I'm going to talk about policies code now so before one one moment before I wanted to say that Currently we are building in permit a yo kind of a full stack solution end-to-end solution that will basically Trying to give engineers Basically the solution to not build access control again So One moment we will meet Sandy. So Sandy will be our developer for today and Sandy is basically again Doesn't matter if she's in in a startup or in a big company cooperate She's trying to build her application right now And she's trying to build authorization because she got the ticket from her manager and now she's trying to understand What she needs to do so she will try to build something very very basic so the first thing she will try to do is building kind of a middleware inside her code and this middleware she called it off Z which is a short name for authorization and What she's doing basically is something very very Basic like I said before she's giving the opportunity to to her developers to Kind of assign admins to specific endpoints. So now she has this Document endpoint which is like creating a new document in her API and now she's protecting this API endpoint Using this role called admin. She can basically change it to a different role, but it's only one role So an admin and non admin kind of model That's what she built right now and obviously that's not enough that might be nice for the first couple of days So she tried to do something a bit better. She's trying to build kind of a multi role Access control. I will give it a good better name in in a second But what she's trying to do is basically protect a specific endpoint Using few roles so you can see here that not only an admin can access the document or maybe the lethal document or You say whatever Now also a paying user can do so. So if you are paying good You can create and delete the document if you're I don't know an admin also good but if you are a reader that's not enough and That's what we call in the industry role-based access control and You might have heard about it mostly in Kubernetes or stuff like this also Kubernetes is using role-based access control. So On the right side, you can see a pretty pretty simple example. So you have Joe, which is a viewer Unfortunately viewer cannot delete the document, but he can read a document Delete and read yeah and send the she's an admin So she will be able to delete a document and also read a document again very very basic and This model policy model role-based access control is widely used in many many applications You you name it again. I said Kubernetes and that's a good example. I think and Also, it's really easy to define. So for send it will be very easy. It gives her Kind of a good moment to finish the ticket and she's saying okay good Let's let's move on right but unfortunately Really high-demanding consumer comes to our manager or comes to the product manager. I don't know and he says Please role-based is not enough We need something that will help us to not only observe the user but also observe the resource that he's trying to to Interact with or maybe I want to know better my user. Maybe my user is now from Paris But I want him to be able to interact with other resources only from France or from Europe or stuff like this So this why we need smarter policy and this why we need attributes. So in this example again, I'm not going to Too much drill down in this code, but in this example we can see in the API endpoint section That Sandy Enhance this decorator a bit and now it can also Accepts key and a value so you can see that now this API endpoint accepts a role, which is an admin, but now Like he will be able the decorator will be able to also accept A key and a value which is location and Paris so you can you guess it right now Also an admin that is located in Paris will be able to access that document and not only this I can say maybe that If the user is using a device Which is a phone it will be also able to do specific stuff we can say whatever basically can inject any data that we want and By this we can basically inspect the user and not only inspect the user We can also inspect the resource that he's trying to Interact with so maybe I want to say that the document is a specific document Maybe I want the user to be able to interact with only Datasheets or maybe DB a kind of document. I don't know so that was attribute-based access control and on the right side you can see Sandy and Sandy is from is an she's an admin but Sometimes she's from the US and I will not let her kind of delete documents that are somehow related to European documents and only when she is from Paris I will let her to do so so this policy is becoming a bit more complex a bit more smarter and Not only that we are able to now inspect and make much smarter Decision-making we can handle also multiple data sources So if you think about it now I can take the data not only for my DB I can take data maybe from other APIs maybe from Stripe Salesforce and I can somehow integrate this data to my policy Okay, so this can be very very interesting and now we can build a much complex More complex kind of policy It's really really scalable, but unfortunately as As long as you're pushing more data and trying to handle more data sources It's becoming a mess and it's really hard to maintain. So keep that in mind also configuration can be an nightmare and now another customer comes and this customer asks for relationships and This can be a bit confusing. So I will give a good examples of what relationships mean what relationships in policy means and For this example, I will take Sandy and Joe again and Sandy now Sandy now she's an owner of a folder. So let's say that Sandy now is an owner of the R&D folder for example So she will be able to delete a file Joe is just a viewer of a folder So Joe will not be able to delete a file that located in this folder Another example that I can give here is that Sandy Sandy. She's not an owner of the folder of marketing, right? So she will not be able neither to view delete create documents under the marketing folder. So that's also important to understand Some good examples of relationships based access control that we have today that I guess most of you are familiar with so we have We have Github and Github now kind of trying to Model their access control with organizations and repos. So think about it I I am A part of permit IO Organization so I can maintain I can push code to my repos under permit IO But I cannot push repos under let's say some other Companies repos. Maybe I do I don't know but for sure I cannot delete the repos So that's something important to understand. This is the relationship. So the organization is the owner of a repo and In Google Drive, we have something A bit more complex but easy to understand. So we have Directories we have folders and inside the folders. We have files like just like I said, so On the left side, you can see also the example of I want to share the specific folder of this Specific file with someone so I can invite someone I can say that he's now an owner or maybe she's viewer on this file and By this I can share access to my folder and by sharing the access to my folder. I'm also sharing access to all the Documents and files inside of it and in permit IO we call it role derivation. Basically, and that's how we Wanted to make our user understand better. What's relationships are so if I gave you a role of a specific Instance of an object, I want you to have the roles all of the hierarchy inside of it so that's how we call it we call it role derivation and Relationship based access control again is it's a bit complex But the easiest way to think about it is when we are talking about graphs so think about graph based database and Now think that we are building all of your Application all of your objects inside of the application with kind of graphs and connections So you have the entity let's say a user or API key doesn't really matter maybe in the next few months, it will be an AI AI agent and now this AI agent needs some kind of access, right and Once I give this AI agent an access on my organization Maybe now this AI agent can do whatever he wants it wants on my organization, which is very scary Right, so we want to build a good relationship based access control which limits and also create good access to my entities and When we are talking about graphs, I need you to stay with me with the graphs because with relationship best access control what we can do is not only ask Maybe sandy can delete a file or do sandy does sandy can maybe create a folder We can also ask the opposite we can ask the reverse of this question So we can ask maybe who can access this file, right and when this comes into graphs It's very easy to understand and very easy to answer right because it's just going through the graph and Using a simple database will not be enough here So most of the times when we are developing this relationship base access control most of the time. It's really in graphs And with this claim we can understand that it's also very easy to scale right because I don't know We have this graph and now we have 10 billion of entities. That's good We understand better and we can answer pretty quickly, but as soon as this graph is getting really really big We need to understand that the performance might be a bit Not that good Also a good example here is Google so Google released in 2019 a white paper called Google Zanzibar for those of you who know or don't know Google Zanzibar is kind of a white paper for released by Google that giving us a teaser about how they manage permissions and fine-grained access control and authorization on their platforms on Google Drive or all of their suite of tools So you can also access this white paper and try to understand and also there are a lot of open sources that I tried to Implement Google Zanzibar into their own open sources. So this is really nice. I will talk about it in a second But as you understood, it's really really really hard to implement yourself and maintain So I really don't recommend to do it. Just grab a tool grab a product The market is I think mature enough to offer this kind of services now And also as I showed you in Google Drive, we have this UI nice UI that we can share my Document I can share my folder and these interfaces are always needed think about it We have good access control what what about when we want to share the access control to other users Maybe I'm a user in the insurance app and I now I want access to my I don't know my children or my other Family member insurance. So I need this kind of good front-end interface that will let me do so So this is also something that we need to take care of So I talked about three policy models that are fairly and really Important to understand and really used in the industry Which was role-based? attribute-based and relationship-based access control and we need to understand that authorization is really ever It's not only in the back end like I showed that Sandy developed Unfortunately for Sandy she will need to develop the same thing for her front-end and maybe the DevOps and the infrastructure she will need to to understand what she's doing and What I'm talking about is that on the infrastructure side if you think about it. We deploy a new code, right? We maybe Deploy a new Terraform or Pulumi kind of infrastructure and Maybe we destroy an old component and maybe we do specific stuff that is really really dangerous So we also need to understand how we do it good and not destroying stuff without any permission, right? We need also access control on my infrastructure The same goes for the front-end. So we need to understand how we develop good Interfaces like I talked a second before and also if you think about it, let's say I'm a paying user on my application right now but Other customer is not paying and I don't want him to be able to see the buttons on the front-end so I need to hide these buttons for non paying users and this thing called feature toggling or feature flagging you can say you can call it whatever and The back-end is what we talked until now protecting our endpoints and when we're talking about data for example That becomes a bit more complex So think about it. I want to send queries to my database But only queries that the user can send. I don't want my user to be able to send queries that he's not Permitted to do right and that's how we call Partial evaluation we want to be able to send specific queries to the DB and Unfortunately, we always have these legacy services that we need to take care about This is not something I'm going to explain how because I really don't know how And Again, we have more things that we need to take care of so we need the performance to be well, right? Because if every endpoint call to my API Becomes a bit let's say Maybe half a second slower that means that every API call to my back-end will be slower because of my authorization So I need to take care of that my authorization layer is very very fast And well for well performing I need to take care of my monitoring because again How can I know that my authorization is slow? If I don't have a monitoring or good monitoring system on my on the authorization layer By this I also have and I also need audit logs because what happens if some Some kind of a user gets access to a specific file that it doesn't Shouldn't have permit permission to see this file or something like this. So I need to understand What's the permissions that my user are getting? and About user management So this is the UI and front-end interfaces that I talked about and this comes in many many colors and ways to implement and Unfortunately, we need also to operate this thing and maintain this thing to understand how we can maybe deploy new policy or stuff like this and With this I'm coming So we have more things we have also compliance and security that we need to take care of And we also have other stockholders that we need to think about right we have maybe customer success management and Product managers and we need to understand how we give them the power to control the policy because if my policy is inside a code I'm doomed because every new policy means new Version of my code, but if my product manager says okay now I want the policy to be a bit different that means that we need to create a new ticket for this for the R&D But that's not what I want. I want my product manager to be able to change the policy. However, he wants right So I'm going to talk a bit about the top five best practices that I think are the most important about authorization. So we have the agnostic to the permissions model and To explain a bit about this I want to be able to Kind of develop my permission model doesn't matter if I want role-based or attribute-based or I want to Maybe plug in another third part is that I want to get the information from and the data from so I want to be able To be agnostic to the model that I'm choosing I want to decouple the policy from the code, which is very important and I'm going to elaborate on this in a second Support the whole stock. So we talked about it. We have the front and we have the back end DB's We need one authorization layer. We don't want five authorization layers And also if we have three microservices in our back end, I don't want that every microservice will be Will need another authorization layer. I want all of these microservices to use the same performance and monitoring recovered and Let's move on. So I wanted to talk about decoupling the policy from the code and By this move a bit to policies code. So today the Kind of the top tools that we have today to manage policy Using code but not in our logic not in our back end code So we have open policy agent, which is fairly is very well-known, I think Kubernetes is using it and gatekeeper if you know AWS cedar So AWS released an open source called cedar. I think in January 2023 and became really mature by the time and Open FGA, which is also an open source that try to implement Google Zanzibar like we talked before So today in order to manage your policy in a good way We have few things that we need to take care of. So First of all, we have the data. So we talked about the data the data can come from many places Maybe third parties, maybe DB's APIs, but as soon as we have the data, we can continue to write the policy so now we have the policy and You can choose which one to to use if you choose open policy agent. You now can Develop and implement the policy using gringo or using cedar If you're using AWS cedar But as soon as you develop your policy Good, you're good to go. You have the data and you have the policy and basically that's what you need Right as soon as you have the policy and as soon as you have the data, you're good to go But think about it What will happen now that you change the data constantly and you change the policy constantly and now a new user logs in That means new data and maybe you develop a new feature that means new policy, right? So you need to understand how you version control it and deploy it in a good way So for this we have policies code policies code basically gives us Everything that I said now everything that githops will give you So it means version control On our policies think about it I'm pushing to get now new policy and that means that I need to get an approval and code review, right? And that covers the Tests that covers the deployments that I really I can really build in a good way and Authorization for authorization if you think about it as soon as I'm pushing my policy to get Now I need someone to review it I need someone to approve it and this is basically if you think about it. I need access control to my access control so Using git doesn't matter if it's github githlub you can basically implement all of these Concepts really really easily And I think the most important thing is really the deployment and rollback because once you developed a bad Access control like you like I showed you before Bad things can happen. Maybe insurance can be now exposed to everyone and maybe I don't know medical bills can now be Exposed so we need to be able to roll back really really fast in in case something happens, right? And again in one word is just github's so for this we developed in In permit opal Opal means open policy administration layer. It's it's really a mature project now Used by many companies. I won't name drop now, but you can see on the side and Opal gives you basically What I just mentioned gives you policies code out of the box. So we'll start from the Left side. So basically opal is built with the server and client architecture So we will split it into two subjects. One is the server We'll start with the server and just understand that the server basically holds a state of my repo So I just said I want to control my policy using a git So opal server just always watch always watch and see if there is any kind of change in my policy And once there is a change, it's automatically and lively updating the opal client using web sockets and We can have many opal clients if you think about it because maybe I have tons of users and Tons of authorization queries then I want a good scale Of my clients So opal client will do the specific stuff opal client will get the policy in the one hand from the opal server And on the other hand what opal client can do is basically get data from wherever We have something called data fetches, which is kind of plugins to opal. So opal can fetch Data from wherever you want it can be API's it can be DB's we already have many data fetches implemented by different kind of people Obviously from the community so you can also Pull data like I said from third parties so you can choose Salesforce stripe your cloud provider and In the end of the day opal client we now hold two things one updated policy and two updated data Using these two things. I can make sure that my users are getting access control That is not only will perform. It's also very updated so opal client You can choose either to use opa as the agent or AWS cedar as the agent so it's fully Scalable and flexible and once opal client is up your application can query opal with any kind of authorization query that you have in mind and That's it If you want we have a nice slack community and just all around authorization You are more than welcome to join. You're welcome to Grab me after and ask me whatever you want. I'm here to answer everything and that was it. Thank you everyone