 Good afternoon in Europe. Good morning in U.S. Hey to the rest of the world Thanks for coming to my talk about the fine grained policies are back with NGAC and As you can tell I am not a native so when I submitted this talk and the title was Fine grained policies are back with NGAC, right? So pun intended in this talk we will talk about access policies and How deep we can go in terms of granularity and Spoiler alert Why we cannot achieve that with our back Before I continue, let me introduce myself. I'm Jose Carlos Chavez. I am a software engineer at the trade and I participate in some open-source projects with lots of enthusiasm. I am a Wasp-Korazaco leader and Also a second member. I am Peruvian. I am father of two So let's start with this talk Let's first define or let's have a notion about what access control is According to security 101 from Microsoft access control is an essential element of security that it reminds Who is allowed or not to access certain data apps, but in general resources and Under what circumstances, right? What the context is Basically when we talk about Access control we talk about a couple of cases first of all make an access decision and You get a principle, you get an operation that the principle is trying to perform and then you get a resource over Which this operation is going to happen and then there is a response which is Allow or deny, right? That's the typical use case about access control In the other hand in the in the administration or the managing in part we have the type of access policies that we have The policy API and what the language is, right? Great regal policies with a Cedar or Any other policy language But more and more we are talking about more use cases, right that they're more related to Audit User comprehension of the policies and forensics So there are three more use cases that are desirable in access control systems nowadays in the cloud native landscape one is Explain which is basically I get this principle Trying to perform this operation over this resource. What are the reasons for allow or deny this? request Also, what access does this principle holds life to what resources can this principle access, right? That's that's another one and then we have who can who has access to certain resource. That's also an important one right Based on that you will say like okay if we talk about audits or forensics like okay decent decent these principles or subjects have access to this resource These are these are the desirable use cases on top of the existing classical use cases of access control But what are the models we have for access control? Well, we have some some some models but the most common are four and actually They the ones that are more most used nowadays are a couple right first. We have discretionary access control, which is That every owner has an object and then the of the owners grant access and Access to the to other users at their discretion, right? They basically a dog beside K, but guess what case by case Who can access to what resources are not right and Since this is case by case and it's an adult and a scenario is doesn't seem to be too scalable, right because Then you will have lots of owners versus lot of resources versus lot of potential holders of access And but this is for example, what you have in google docs When you give access to certain people, right? Then you have mandatory access control where users are granted access in the form of a clearance, right? There is a central authority that regulates access rights and and then organize them in fires and It's this is very common in government and military context like for for for for confidential information for secrets, right? Where structures are very static and rigid Then there is probably the most common one, which is our back role-based access control. This is if you ever use Kubernetes for example, but there are other tools that have been using our back for a while and This is access rights based on business functions, right? Or you can also think of them as roles Right rather than an individual identity. This is easy to understand and output policies in the right way Because roles are kind of so descriptive, right? They have the semantics to explain what is this entitled to so Defining the policies is kind of natural, right? But then you can have some challenges when it comes to scaling this, right? You could have some role explosion. For example, when you need to give more granularity to access then basically people can get a Or or actually the setup can get messy because we'll have lots of roles The more granularity you're you're looking for the more roles You have to create, right? and then we have aback, which is attribute based access control just A natural evolution of our back, right? Where the access is granted Flexibly based on a combination of attributes and environmental conditions, right? Such as time or location and a good Real-life example could be a passport, right? Where you have a passport which has a set of attributes that describe you You could have nationality age Then you could have date of birth name of the parents When is this document? What is the the the valid date for this document and so on? And then access decision can happen on these attributes whether you are from one country or the other Whether you need a visa or not Whether you are under a certain age So you need the permission from your parents to travel whether The passport is valid or not and you can get into the country And but also some environmental conditions come into play, right? For example, if we are in covid You could only travel back to your country Of residence or maybe under Humanitary circumstances you can go to another country like these are environmental conditions not related to the attributes It's hard to understand Basically because you don't know the attributes on beforehand as opposite to to our back, for example Where you know the roles and roles have the semantics to describe themselves It's hard to um Let's say altering the policies rightly is a Basically difficult because you need all this information Some permissions overlap so you don't have a concept of presidents or or maybe you don't need even presidents And but this is the scale and model, right? And Basically you can have unlimited number of attributes theoretically and then Basically putting attributes to the entities is easier, right if you know the attributes So to overcome all these issues and to think about how could we implement different? Um, I'd say models in the organization Because you don't necessarily Can say this is better than the other in certain circumstances. You need these uncertain circumstances. You need attribute basic role-based discretionary access control basic like you're gonna say I It depends on circumstances depends on your Uh, what is the state of the world in your organization? It depends on many many things. So Ideally you should be able to provide all of them or or be able to implement all of What is needed for you most of them under certain conditions And there is when ngac comes to the rescue, right? ngac stands for next generation access control Basically in the cloud native Application landscape nowadays, it has fun different domains and it requires different granularity levels And precision in a specifying policy Considering a large set of variables, right that you have in in a deployment And the policies that are based on attributes Then I'm not creating type relationship to a specific Identities, right? But instead of a class of identities and And those values could change over time. So you need a certain degree of flexibility And and this is what we aim to with ngac basically ngac was created by nist and it takes the approach of modeling access decision Data as a directed acyclic graph, right? You have users or subjects because users is kind of a Close concept, but you can have more than that as we can see in the next slides You have objects or resources and you have User attributes and object attributes and then you have policy classes, right? You can think of it as an opinionated implementation of a back Right, but we will see that it's much more than that Um First of all, as you can see in this graph We we have been able to to provide a model based on what is actually happening in my organization, right? But we have Alice working for engineering and Bob working for HR They all belong to the company And then we have different resources classified in under different groups, right? We have And we have the resume and the contract which are documents, but all with the certain Let's say Certain attribute of confidentiality We but they are also files that belong to certain folder and that folder has certain groups You can think of it as When it comes to for example domain driven design that you have the same entity under different domains having different attributes different Interests from from the user perspective, right? So here is the same you modulate Different documents us Documents because of the content they have but also as actual physical files That belong to different directories and then having people Being able to access under different permissions to those documents, right? Good thing about ngac is that as you can see you Basically don't impose a model in your organization for writing permissions Instead you get your organization and put into the graph to for to write the access policies And then you can have different policies classes, right? Where you will describe which subject has access to what object? And Let's go through the ngac architecture And basically you have a subject trying to perform an operation against an object And then you will have a policy enforcement point which is Basically the entry point to the resource or to the object And the the policy enforcement point it will be in charge of asking the policy Decision point whether this Operation can be performed or not at the same time The policy decision point will ask the policy administration point for what are the policies And what information do we have about this? And user and about this policy And then the policy Administration point will ask the policy information point for the information as I said And then it will come back with with the certain information So the policy Administration point will go back to the policy decision point with all the information on the policy for it to make the decision And it will Send back the decision to the policy enforcement point saying allow or deny, right? And then Based on whether it's an allow or denied if it's an allow it will the policy enforcement point will forward this to the resource access point which will basically return In a allow position will return this resource or object to this object, right? Then there is an isolated concept of an event processing point where different events are are Basically like an event loop are happening, right? And it could be that the when there is an access decision you communicate the the event processing point to To to make a signal that something happened For example, if you have a policy that is one-time policy, then you could notify the event processing and point That this this access already happened. So It can make some operations in the graph to maybe remove A policy or it can be a policy related to the time So then based on the event loop it will say like, okay this time passed So the policy is no longer valid and will make a change in the graph It's basically an event looped That according to certain conditions it will do changes in the overall policy As you can see There is a natural fit if we talk about Istio or service mesh There is a natural feel on this architecture into Istio deployment, right? Where you have we'll have a policy enforcement point inside The Istio sidecar, which is a non-boy The PDP the policy the the policy decision point can be anything it could be an ex out Set the server it could be a wasm plugin it could be anything basically as long as it makes the decision Remember the the policy enforcement point is only for enforcing that there's going to be some scrutiny in this request Then the decision is made of the PDP And then the PAP the PAP they could be part of the same component Or a different component that's up to the implementer to decide, right? Maybe you have the let's say all the policies in memory in the PDP, so and So they don't need to be physically separated Nor logic. Well, logically maybe but not necessarily different components Then the the resource access point I like to put it inside on boy as well because In the end after the enforcement point related to ngac happens There are some other things that will that need to happen to get access to the to the actual resource So, yeah, the the resource access point is is going to be part of the of the sidecar as well But the title of this talk was how fine grained Was This policies or these policies access policies see model, right? To that let me show an example like Let's say we start with a classical our bug setup where we have peoter and lance working for an sre Role, let's say That belongs to the airbag policy And then we have a backend service which has two instances as you can see there is this um Bridge, let's say between sre and backend this this edge that tells the permissions that The sre let's say subjects will have over these backend resource which is a service in the end And then This is one policy, but let's say we we need another policy, right? That's not necessarily our our bug related So we could have a location policy where Lance belongs to the us team and it's actually in the us To the european team and it's based on the u and for for the sake of compliance or when we talk about compliance policies and regulations that we have in in the software world Um We could say that this is relevant And because where do you put your date and which services in which region, right? There might be some compliance requirement that Let's say a health company from the us only wants to use um us cloud providers Where the servers are physical in the us, right? Um, so yeah, we we put in place this policy and we we see that one instance is in One instance of the backend services in the us another instance of the backend services in the european union, right? And then they all belong to the location policy And but yet not enough we could have another policy class Which we call topology where we say like, okay The the front end service can query the backend service and we don't have another policy meaning that basically No other service could query the backend service and we can see that We have This edge from front end to back end that leads all permissions and so That is in one hand If we think about permissions in this we could if we're talking about your pc we could talk about methods but It could be least the methods could be listed here if we if we want to Modulate them inside the the ngac policy or it can be delegated to Another layer of security where the backend allows different methods depending on different conditions. That's entirely up to the user and We basically modulate what we have in the graph and what we can put in the graph, right? So yeah to summarize we have three different policies completely the couple one from each other, but we have different nodes And that in in in the real life they they are arranged in this in this way, right? So so as you can see we we basically model what is happening in the real world into this graph So how do we do we make the access decisions? What is the whole point about the ngac? Well, let's say we want to see whether lands can access the instance one or not, right? And for that we first need to to traverse the graphic to see whether lands can access it if there is any breach between lands or any attribute of lands And and the instance one right or any attribute of the instance one for example that it belongs to the backend, right? And we will see that yeah indeed There is a breach between the u.s The u.s engineer zone and the u.s region where the instances are hosted There are read read permissions for that and then we see that lands belongs to the u.s u.n belongs Or fills the the location policy And in the same at the same time the instance two belongs to the u.s Let's say the u.s Zone and then that zone belongs to or plays also in the location policy So from from that point of view we need we see that lands can access the instance two But we also have some some other policies in place right that also need to be Um Fulfilled right we we see that lands is part of the sre team and the sre team under the our back policy Um can access the backend and hence it can access the instance two so in some uh and and and for that we have read on bright permissions from sre team to the backend service So in some what we will have is that according to the location policy Yes, lands can access the instance two the instance one And according to the our back policy. Yes, lands can access the The instance instance one with read on bright Permissions and the conclusion is that yes lands can access instance one And with the with the least privilege right which in this case will be read um But we can do even all the kind of decisions right that don't involve necessarily users But uh, whatever that we can identify in this graph right Notice that one of the the In the model of ag and ng ac we also split the graph into two parts the object Doug and the subject Doug right and You can see that we have Repeated notes in one side and the other depending whether I am the subject or the object right um in this case we have that Well You know already the decision But let's let's see what is the analysis behind that an instance for rich instance one well, um According to the topology policy, we have that the front end can query in the backend service Uh, there is a bridge here from from them to back end with all permissions And it goes through the topology policy class because the instance one belongs to the back end Service and then the back end service according to the topology class is connected to the front end service But then according location, there is there is no, um, let's say edge Uh between instance four and one right because the instant one when it comes to location It goes down to EU and then In from from the instance four standpoint, it's only connected to the us Note In the graph In the in the us let's say in the us zone So and the EU and the us don't have any any Edge right If you see the us with the us are connected the EU with the EU are connected, but EU with us are not connected. So Uh instance four cannot reach instance one And then the decision is to deny this request as you can see you can modulate what is in place already in your world Like you can think of it a kubernetes deployment With policies for name spaces access cluster access even multi cloud access right can this cloud reach this cloud Can this name space reach the external services? Or or the cloud provider can this user access this resource? Whatever you can modulate in a graph You can write policies for in in ng ac, right? So overall the benefits of of ng ac are first you can overlay access policies on top of an existing representation of the world provided by the user You don't so it's As I said You put your policies You get your the state of the world You put that in the graph and then you write the policies on top of that, which is natural instead of You modulate your reality based on the policy, which doesn't scale Second is scales linearly Roughly depending on the user attributes, but the of your attributes plus the associations Or the size of the sub graph after a trim For the user and objecting questions, right? This is especially important because other let's say models of access permissions or access policies are When it comes to scaling it becomes exponential computations Even an early version of ng ac Scaled in a cubic way in a polynomic way, but now It has been proved that it scales linearly Another benefit is that it can be configured to allow or this allow access basis Not only an object attributes, but also in other conditions. For example time remember the epp that we saw And which is count or basically been our time location, which we just shown And etc, right whatever attributes that you can whatever condition that you can modulate in the epp And then you can put the objects around that or the subjects in a graph. You can write policies about, right? Um, it can evaluate and combine multiple policies And while keeping its linear time complexity. Yes, you can see we evaluated different policies And and basically the algorithms for for resolving the graphs like the connectedness of the graph is remain the same So so yeah, basically you do all evaluation at once. You don't need to do different evaluations and reconcile the results Um, then the audit to see what objects are affected by a policy is also possible traversing the graph. So basically Whenever you're going to put a policy in place, you can see on beforehand What are the the objects that are affected by it? And then explain why a particular axis was allowed, which is a key point about this It's also very important because you will you will see that In in other Access or in other access control models It's really hard to explain why a particular axis was allowed, right? Because you have to resolve at that time and All the conditions and then you need to reconcile the conditions So if we compare with other ngac models, it's also And again, I'm not saying that ngac is with the our back or an a back or Or something like that what I'm saying is that it with the ngac you can achieve our back, which is needed And a back which is also needed, right? And a back as a pro it provides flexibility of course because you can Basically the model can scale Unlimitedly right because you can create as much attributes as you want The cons are the performance and our disability can be problematic because of the number of attributes and also those attributes are not carrying information about The capabilities are not necessarily easily related to the capabilities, right? And also you have to combine them and Which can be problematic in computationally talking And as I mentioned as opo said that's in the roles where you with a role is more or less identified with With the capability that's much more Natural, right? Our back is simple but you have And it's easy to digest understand and it's easy to write policies on But then you have the role explosion because the more granularity you need the more roles you want you need And also someone was saying in the in the chat that For for our back you need roles for everything which doesn't happen in the real life, right? You about things cannot be done and in real life what you have is adult Policies you have role explosion because the more granularity you need the more roles you create and that's not scalable You have fixes fix the doc's rights because you need to know the the roles on beforehand And and then there are challenges meeting regulatory requirements due to Ability because as I said in zero trust Model what you have is that you will need to give A lot of granularity to your permissions because you have the the minimum permission or the minimum access granting to the to the objects and then It's hard to come up with a general policy that that is That was for everyone right You see high level of granularity. We are running out of time Auditability as we saw flexibility you can combine access policies, which is very important and on early stage It means more high level apis to help users to maintain the graph because it's not trivial You need to reconcile the reality with your graph. So you need tooling for that Finally conclusions aback is a natural fit for the class of cloud native applications because In a in a microservice world you need teams to give Independence and then they they need to be able to create their own attributes. They don't need to They cannot just work with what is created by the By the security team they need flexibility and for that attributes work great also Empowers them to create their own policies and it's flexible enough And being able to understand an access decision in a human readable way is crucial to understand access leaks and secure points and forensic research And performance is a is a key in access decision as making decisions in the critical path Which happens in this point because every request goes through the policy enforcement point could have a huge impact in latency These are the reference for the talk. Thank you everyone for coming and Enjoy the conference. If you have any question, I will be around in the slack or also in the chat for the session Thank you so much