 Hello everyone, I'm a staff from permita. Yo, and I'm going to talk about opal the open policy administration layer And now it can help build Cloud native permissions more easily Sorry about that So you just got your project to build in-house permissions But you need to understand permissions are hard okay, so There's a lot of modern challenges like micro services Infrastructure was not what it used to be 10 years ago And now I cannot just embed permission logic into my application because I need to enforce access across many services Some of them are third-party services as well Modeling permissions is really difficult while all developers almost know what role-based access control is Eventually you'd want to move to more complex systems. Let's say you want to get access based on the user location You cannot do that with or based access control You probably want to move to actually with based access control or if you want to get access based on ownership More fine-grained permissions. You probably need relationship based access control. So this kind of challenges are Are difficult because these systems are difficult to grasp and are difficult to implement and Finally, there are mounting security and compliance standards that we need to adhere to we all like our privacy But it comes with a price and implementation. We need built-in auditing. We need checks and balances for example I want to be able to say who can even change the policy Inside my application. So of C for of C. This is also important And all of these challenges are the reason that broken access control is the top Top issue in OS top 10. So 94% percent of applications were tested for broken access control And we want to avoid these pitfalls in our implementation. So the first one that we see Most I'm sorry most commonly in coupling application logic and authorization logic You may want to start with just like admin and not admin for permissions and that's okay But if you encode this logic in an if branch in your code, eventually you'll get this code block And while this is a like completely fine for monolith applications when you get to micro services it completely breaks because You'd need to duplicate that logic across all your services and duplication leads to drift and drift leads to Security incidents. So we don't want that. We want to put everything in one micro service in one place The second kind of thing that we see is mixing up authentication and authorization. So We see implementations where people just take Claims from octa and just put them in json web tokens and just check that in code And that is fine, but it has a few downsides So organization roles are not the same as application roles if I'm the head of IT I shouldn't have admin access to the financing app. So some translation from organization roles to application roles needs to be made and Another thing is that Jots tokens are not storage. They are limited by the Http header size. So eventually when you'll have more fine-grained access you will exceed this limit and lastly This is not flexible if you want to change the permissions for a user mid-session because the user has a job It logs in everything's fine next time you re-logs in this will be applied, but this is not flexible enough and Finally Not planning ahead. So this is completely fine like starting with something simple But let's hope you do better and the app will grow and more demands will come. So demands from customers You'll have This really great deal that could be great for the company with an enterprise customer And they need finer-grained permissions and now you need to build that into your application really fast or You want to expose API keys through your application. You need API key management All of these demands Will come and you want to build a system flexible enough so that it can grow over time without being so Painful to rewrite from scratch every time So Let's talk about the best practices really briefly you want to decouple policy from code You want to be able to respond to events real-time? Okay, you want to have the github's workflow for policy You want back office for stakeholders and you want interfaces for customers and I will go I will go over them one by one. So First Decoupling policy from code. We already agreed. This is a great idea And really cool project that most people know right now is OPA this is the most adopted policy agent currently in the market and OPA lets you express policy as rego code and Data is JSON and this is great. You can just create all the policy in the organization in rego and just manage that OPA does have one downside. It was Originally made for Kubernetes admission control and it cannot actually respond To events in real-time. So for applications, this is breaking and that is why we made OPA So OPA is an administration layer for OPA that gives you two main things First github send second real-time updates. So I will go over them with OPA Each OPA client manages a single OPA agent and then it can be managed by an OPA server That can run in a cluster. So the OPA server's job is to track a githrepo and Serve that policy from there It also can push real-time updates like JSON patches to the OPA client and from that to the policy agent and Finally OPA client can actually access data that the OPA server cannot you can send any Instruction to OPA client even if they're in a separate network to bring data from let's say an in-house database That shouldn't be exposed to an outside network OPA is extensible it has a plug-in mechanism called fetchers. So we already have fetches for LDAP MongoDB Stripe etc and you can use them if you want everything is open source So OPA gives you the ability to manage policy in gith. Why is this so good? Yes, so With githops for policy your policy is auditable You can see who made the changes where the authors you can see all the you can use signed commits and entire history is available to you It's immutable rolling back is easy. It's super easy and also it gives you the power of CICD you can have tests you can have approvals with PRs for something sensitive you can have multiple approvals and You can have quality signals So with OPA you can have policies that are not as performant as other policies There is a meaning how you write your policy So you can just have a code signal in your CICD that says if the policy is too slow It will affect my app SLA and please let me know So all that power is available to you if you manage all your policy agents with OPA So if you want to talk more about off Z Please come find us at boosts you 25. We're also available for slack and Opal is available at opal.ac. It's Apache 2 So, thank you very much