Unpacking Next Generation Access Control (NGAC) and Tetrate Q

We recognize two types of operations, resource operations as well as administrative operations for configuring the access control data to realize policy state. There’s a set of functions for trapping and enforcing  policy over access requests for computing decisions to accommodate those are requests based on the current state of the, of the access control data and also a function for automatically altering access state in the face of certain events. So there’s very much a dynamic component. Oops. So the architecture includes things like a policy enforcement point, policy decision point, but essentially there’s a request comes through from a client and gets trapped by the PAP. The PAP takes that, that requests and submits it to a policy decision point for, for um, computing a decision. It, it reads that, that, um, access control data through a policy administration point. And if access is approved and it’s a resource object, it returns, the PDP actually returns the location where the objects, um, resides. Um, and submits that to the, to the PEP and the PEP issues, a command to a resource access point for, um, for execution or that operation on that, on that resource. So the point is that the, the, the, the, the location of the resource is completely transparent to the user because the user just sees objects which are logical, logical entities. And we’re going to look at what, how, um, objects fit into a policy configuration just a little bit. Um, but it’s also important to note that what we can do is, um, once a, an access event actually occurs, what we do is we send that, the context of that event access event to what’s referred to as an event processing point. And if that, if that, um, event matches an obligation and an event in an obligation, we automatically execute a series of administrative operations to dynamically change  the state of the system.

Again, I’m going to go through some examples, but the methods for, um, for um, for performing operations on resources are implemented in a RAP. The methods for manipulating and retrieving access control data is implemented in the PAP. So it can be deployed in a wide variety of environments. Um, we’re going to a later at the end of this talk, um, Ignasi is going to give you a demonstration of its implementation in a service mesh. This is just one example. So what one, a request comes to the PAP, we just issue.

So what is important is that cloud can view a RAP as just a user with liberal, with liberal permissions. So as far as the cloud is concerned, the, whatever the RAP says it wants, it can retrieve that, retrieve that data, but the user can actually see the resources that they have access to in advance of doing an access control check. So what he’s able to do, we’re able to see the resources that he has access to across a multitude of clouds. And that can be structured in any way want it to be. It can look like a a directory system. It could look like your inbox. It’s just a logical view, but the point is the users sees objects which are logical entities in advanced before issuing a request. And he could actually select those resources in this view and see information across multiple clouds without actually knowing where that data actually resides.

The EPP generates, remember I said it generates an event context for objects and objects are, are logical entities that may span clouds, on-premise.

But the point is that we can essentially use that information for essential audit across multiple clouds.

So, these are the data elements and relations that comprise the access control data.

These provide the basic ingredients for an expression of a wide breadth of access control policies. So they include things like users, access rights, resource operations.

So we have three types of containers, user attributes, object attributes and policy classes. And finally a, a set of relations which are just assignment for creating membership into containers or, or attributes, associations with, uh, with assignments can be used to derive privileges. Um, prohibitions which are just denies. And then again, these event response relations for dynamically change in a state. So again, these are the basic ingredients that can be used for expressing a surprisingly large number of access control policies. So, um, this is a, a depiction of, of assignments and, and, and associations. So we’re depicting assignments as a, as an Arrow, um, and so users can be assigned to your object attributes, user attributes. And a user attribute can be any characterization of the, of a user that can represent a role in organizational unit. But any characterization, whether you’re a Democrat or Republican, blue eyes, brown eyes, it doesn’t make, make any difference. On the object side, which you’re on the object side, we have object attributes and object attributes again characterize data in a variety of way. That can be sensitivities like PII or confidential, but it can also represent your inbox or a row or column.

Any characterization of an object can be represented through an object attribute, um, and object attributes and user attributes can contain other attributes. And finally at the bottom we have a, a policy class, which is just a mapping of users and user attributes, objects and object attributes into a policy of concern. So, um, the NGAC doesn’t store privileges, we derive privileges. So, uh, a privilege is really a derived relation. It’s made up a triple and that derive relation. A privilege may pertain to administrative privilege or resource privileged. So is very generic. And so you have a user, an access right and a policy, a policy element. And the policy element might represent an object, an object attributes or user attribute or  a policy class. So the algorithm for determining a privilege is based on combinations of policy classes.

So a policy element, maybe in one or more policy policy classes. And for each policy class there needs to be a privilege in each one of those– in each of those policy classes for the user. So in order for the user to have that access right on the policy element that, that, um, privilege needs to be in each of the policy class for which the, um, for which the policy element, um, belongs. Yeah. So this is, uh, um, so I kind of glossed over association. So association is a triple from a user attribute to access, an access right set to an object attribute. And the meaning is that the users in that user attribute can perform those access, have those access rights on the objects in a object, in the object set. So what we can do is we can derive a, um, so through the user hierarchy access capabilities are inherited up. So everybody, um, the loan officer and teller and auditor, all have read access to products.

So the access capabilities are inherited up to user hierarchy and access entries are inherited up the, uh, the, the object hierarchies. So the, in this case the policy and, and is, uh, tellers can read and write accounts and um, and um, and read loans. Loan officers can read and write loans and uh, read accounts and auditors can read, um, all bank, all bank products. But what we can do is combine policy.

So, what that does is it provides you a greater granularity of control.

So in this particular case, tellers can read and write accounts in all branches and tellers can create and delete accounts only in the branches for which there, for, for, for which they’re assigned. We can try and do this through role based access control, but you would have to have a teller for branch one teller for branch too. Um, and it would basically be the number of roles time the number of branches are the number of roles you would need. But through combinations is additive versus multi ,multiplicative. I’m finally there’s, there’s, well not finally, but there’s prohibitions and we, there’s two types that, that are particularly relevant. Um, user denies. So was basically a user is denied the ability to perform certain or um, operations on, on objects that are in an object set. And we can specify that as a user deny or it can be based on an attribute. The example here would be that presumably user one is the account. Um two one is user one’s account and they’re a teller. So even though a teller has general access to read and write accounts, the teller’s prohibited from being able to write to their own, to their own, to their own account. Um, here’s on the obligations, our final relation, and it’s a, the format is when an event happens, an event pattern occurs, there’s a response. And the event is, this could be a successful execution of a, of an operation such as reading and writing or it can be an environmental event like the, like the time of time of day. Um, when the, um, when the, um, when the, um, when the event is matched, we execute their response and it dynamically changes the state of the system. It can be used for a variety of circumstances like if a user reads certain information. We deny that user in the future the ability to read other other information. It can be used for workflow obligations, can create obligations. They could be nested as a very powerful construct for specifying history based a history based policies.

The example is at one is five o’clock. We have could create a deny where tellers are prohibited from reading accounts and then at nine in the morning we can, we can allow that tellers from having access to accounts. Un, delegation is the means of administrator creating associations. So one administrator can delegate to another administrator. And by doing that, the user, or where, privileges are distributed. So really the only way privileges are created is through, through, through, uh, creating associations. Um, so what we, we can do is we can, um, the, the, the graph on the left, we can create an administrator who has access, access rights to be able to manage the division, division, which includes being able to create groups and delete groups, assign users to to groups. He can delegate it, say to a group manager. Um, what you can also do is you can specify privileges through an administrative routine or parameterized administrative routine, routine. And what it does is it executes a series of administrative actions for creating complex, um, um, relations. So in this particular example, Create File Management user might create, um, uh, an association where I’m using Bob as the name attribute with read and write permissions to objects and Bob’s home, but also give them administrative privileges. And based on those privileges, those delegated privileges Bob, or user 2 would be able to create containers in his home home directory. Um, he would be able to create objects and put them in the containers just like you would do on a regular file management system. But he has those privileges through NGAC permissions. What he would also be able to do is grant somebody else privileges to the objects that are, that are in his home. In this particular case, um, Alice has given read and write access to a proposal. So, um, it’s impossible to go through every possible, um, policy that we’re capable of configuring.

But we’ve demonstrated the ability to do discretionary access control where users can give away privileges to other users, where, for the objects that they control. We can do role based access control. We can do combinations and discretionary and role based access control. We can address communities of interest. Um, separation of duty, history based separation of duty, access based on time and location. We can do workflow. We could do read once where if you, you, once you read it, it disappears and you can’t read it again. You could read at one, at one person at a time, can read an object, just like you can give away a book. Um, once you give away to book you don’t have access to that book. You can do the same thing using NGAC where only one person at a time has access to a particular resource. We can do non repudiation. When you say, I, I approve that workflow, you’re the only person on the planet at that time who was able to approve that, that order. We can do tracking of access. So I can say at this particular time I know who has access to my data. Even if they cut it and copy it, paste it in different things, send it through email. At the end of the day I can determine who has access to my resource at any particular time.

So, from an implementation scale perspective, we… have centralized policy specification over distributed resources with local enforcement. The policy configuration resides in PDP memory as a graph. And that graph can be huge. It can contain billions of objects. Which is what we also have, linear time algorithms for computing. Not only computing decisions but computing, reviewing the resources that you have access to. And when, when you do a review, it’s important to note that even though there could be billions of nodes, the only nodes that are relevant pertain to a particular user and they represent a relatively small part of the, of the actual graph in memory. So it’s very efficient. Um, policy review. What we’re able to do is we’re able to review and, um, discover resources. So, um, we’re able to answer the questions, what are the objects that particular user has access to who can access a particular object.

Why can’t a user access an object of you want him to? You might be able to, you will be able to determine he’s missing this attribute and that might be on purpose, that is missing that attribute or it could be a mistake. Um, and as I mentioned, what we can do is we can display all the user, all the resources that are particular user has across the enterprise and organize those objects into these object attributes.

And they can look like folders or any, anything you would like them to look like.

So in summary, what we’re able to do is we’re able to create a virtual multicloud enterprise. We’re able to specify and enforce combinations of dynamic and static policies, things like discretionary and role based access control across the, the, the virtual environment. We’re able to do policy analytics across all that, all that data. Who has access to what objects across the virtual enterprise. And when I say a virtual enterprise, so I’m from NIST and NIST does physics and chemistry. I never interact with those people from, for pretty much my entire career. But I do share information and have a, a pretty much a virtual relationship with DHS and NSA, the people in my group. So what I would be able to do is create a virtual enterprise, a collaboration amongst those people that I, that I share information, share information with. So that’s what I’m referring to as a, as, as a virtual enterprise. We can set up administrators and delegate administration across, down to a very fine granularity. We can do central audit across that virtual enterprise and we can support a variety of different applications. Um, we have, existing applications, but there’s also this thing called, uh, NGAC enabled applications, um, where we can do things like workflow. We can create a calendar application where the users are able to, um, not only read and write information, but they’re able to distribute the ability to read and write data. And we are able to capture much of the logic that’s typically implemented in an application through access control, um, through access control logic. So that was my, uh summary slide. Um, we’re gonna move on the, to the demonstration. Yup. Hello. Okay. So we have prepared a small demo. We are a bit short in time, so I’ll try to be fast, uh, showing kind of the things you can do with NGAC that are difficult to do with the existing systems we have today. And we have applied that demo to the service mesh.

Okay. Service Mesh Day. So we are looking how you can apply, NGAC to secure service-to-service communications. So I’m pretty sure most of you have, uh, seen, uh, let me see if I can it make the browser visible here, uh, [unclear] Okay. Okay. So I’m pretty sure everyone here is familiar with Bookinfo or, so we uh, we’ll be showing how you can implement some use cases that are important today that are difficult to implement with existing solutions. One of them is location. So today, most of the applications we consume, we consume them from our mobile phones, from our tablets, from our laptops. And as we travel around the world, we consume the data provided by those applications from their very different locations. So, especially since the [unclear] of GDPR and all that stuff is more important than ever to make sure that the data is accessed by the right people, but also under the right conditions. So probably you want to establish policy to say, Hey, data from the US cannot get outside the US, or data that you can write, you can write only if you are accessing that data from the US but not from Europe. And to effectively be able to apply those kinds of policies you need to model location as a first class citizen in your policy system.

Another interesting type of policy is time, there are many ways to model that, but an interesting use case is, for example, say, Hey, I don’t want my data to be accessed, the data from my company outside working hours. I don’t want the data to be accessed outside at all. That’s for example, a use case. Also enabling temporal access to the book, to debug some stuff in an environment where you probably usually don’t have access to, you can just grant temp, temporal access to that system. So those are kind of policies that should be modeled as first class citizens in a policy system if you want to be able to manage that. But it’s difficult today because if you think about augmenting your existing RBAC or ABAC stuff with location, augmenting it for every single location you may have for every single role or principles, it is easily explodes. NGAC provides a nice way of addressing these by composing policies. And this is what we’ll be trying to show with with Bookinfo. So this is a British standard deployment of Bookinfo, but we have deployed it, um, uh, so this is a, can you see, okay, so this is a small UI we have built, as, it’s just the UI on top of the NGAC graphs that David has shown us before. Okay. It just shows that their reviews and point here, the review service for Bookinfo for has been deployed in three different, em, has three deployments. Each version has been deployed to a different region. This is deployed in a GKE cluster in a regional cluster and every single node has gone to a different zone. Okay. So let me do the typical thing, the typical loop just to start, which doing calls here and let me expose Kiali.

Okay. So let’s have a look. Okay. Okay. Let’s see. [unclear]. Okay.  We can see here the Bookinfo publication? Let me just turn on the refresh. And for the sake of the demo, let me just, there’s one access policy to reviews saying that the product page can access it. Let me just remove it for the sake of the demo and I want to be fast. So, um, we’re going to show an example of saying we will see now that access to the reviews will be dropped. We will start to seeing red arrows in there and let’s imagine that there is something wrong in there. And I want to enable temporal access for the developer to debug that environment. But I don’t grant, want to grant him full access to all the locations that are served by the service, for, to all the locations that this service is load balancing to. I just want to enable access to a very particular location of that service. And just for a certain period of time, say one hour or so, that developer can just debug that thing, okay. This kind of policy combinations are difficult to represent today, but NGAC has all the primitives to be able to build that. Okay. And here in Tetrate we have built a system we call Tertrate Q that just provides a set of views on top of NGAC that makes it, eh, easier to consume and easier to work with. So let’s create, for example, a binding saying that the reviews page now can be accessed by the product page. This is debug, the debugging guy. We’ll have just one clients for the reviews. But you could create policies with different access information for different principles. You could say, Hey, these guys from Europe can only access the Europe endpoints, or these guys from the US can only access the US endpoints, we’re going to granting read access. That’s the, only needs talks at the blog page and will say that it will be only allowed to access the endpoints in this specific zone. Okay. And only for a small amount of time. Let’s see. Okay, Just a couple of minutes just to show this. Okay. Okay. So now the review service has a policy that allows access but just to the product page but just to a very concrete location. Okay. So just in a while we will see the requests will start flowing. We will see that the, the arrow [unclear] turning green for, for some of those endpoints.

Okay. It make take some time because Kiali shows these based on the percentage of the success. So we’d probably take some time to show, let me show you while this is happening. Okay. So this is kind of crazy. Okay. But while these updates, it’s okay. Oh look, it has updated already. This is the location that has been white listed. Okay. So requests flow to that location. But request that go to endoints that are surfing a different zone are still not, not available. And just this policy will expire in a while because apart from location constraints it has also time constraints. And as soon as the policy expires, we will see that arrows are turning back to red. Because that principal has no longer access. It has only temporal access for a very specific location. While that happens, let me show you how like of course it okay. How you can reason about this thing. Okay. We can see here some requests to reviews and this is one of the features that NGAC provides, it’s regarding audit, is that you can explain why access was granted or not. So access to this review service requires three policy classes to be satisfied. We can see that this request does not satisfy the location policy class. It does satisfy the RBAC policy class because there exists a path in the graph that we have seen before. There exists a path from the user side to the service side that connects the two, the two objects through the RBAC policy class. It also satisfies time. So this is one of the red arrows we see because the time, the policy has not yet expired. Uh, but uh, it was one of the red arrows for, because location was not satisfied, okay. The policy has expired, a couple of minutes have passed and we see this is back to red again. Another of the cool things is that modeling location is not just modeling location based just on specific end points. The system must understand location as a first class element and must understand location hierarchy as a logical entity. So you could do things such as, if you read properly, instead of, let me clear this time, no time bounds. And we could do things like allowing access to the full region for example. This is not just the zone, this is not a particular endpoint. This is allowing access to the full region.

So say now all the three endpoints belong to this region. So we should see everything going back to green. But you could do with things like this grant access just to Europe, grant access just to the US and with different interfaces. This is the first implementation we have of these. You could do things like that, only people from the US can access the US and things like that. So we should see now that access is being granted again, that access decisions are starting to say, okay, okay, okay, crazy. But yeah, so access decisions are already allowing that. This not the ones. But now all the policy classes are satisfied again, and access decisions are are allowed again, and the system is back to green. So that’s pretty much it. This is possible just because with NGAC, you can compose policies in a very nice way while keeping the semantics of your system, which is a really, really nice feature. And we have just started implementing this in, in what we call Tetrate Q. You want to know more about that? Just go to website. Tetrate Q, you’ll find it there, and that’s it.