 Good morning. Let's try that again. Good morning. Good morning. Yeah, can you tell I used to be in the Army? Hi, I'm Adam Young. I work for Red Hat, as you can see on my branded slides here. But I am going to talk today about dynamic policy for access control. Now, how many people are here for anything about policy that has to do with networking or things that are not access control? This is your chance to leave. Because this is about authorization, nothing network based. This is not Congress. This is policy. We had the term first. I just want to point that out. I'm a senior software engineer. I work in identity management at Red Hat, although at this point I've worked longer on Keystone than I did on anything else anywhere, including the other identity management stuff there. Here's what I'm going to talk about today. I'm going to give you kind of an overview of how authorization works in OpenStack today. Specifically on the policy side of things. I'll give you the defaults. What you get if you take the stuff that we give you in the Git repos or the packages that come from that. Talk about custom policy and how to be able to customize that. Give you a quick sense of what's in development. Then the part which I'm going to subtitle, Adam lies. It's called the vision. This is how I see things progressing. And people have asked me if I'm worried about the presentation. And I said no. I was worried about the lynching I'm going to get from the other Keystone course after presentation, mainly based on the stuff I'm going to talk about here. And I'll give you a little bit of a conclusion. I'm going to try to fly through the slides so we have time for Q&A at the very end because I've got a lot of slides. I've got way too many slides for the time here. Who am I to talk about Keystone? I'll talk about that. I've been working on this since Diablo. Since before it was a full project. It was still incubated. I've been in Keystone course since June 2012. I had to go look that up, but it's been a long time. I was originally responsible for doing the LDAP support. I did PKI tokens. Sorry for that. I made sure that Kerberos worked because a couple people kind of cared about that. And the big thing is kind of specific to Keystone is user-to-user trusts that are almost designed with heat in mind and workflows along those ideas. Here's my other jacket. And I just wanted to show off Mo Duffy's artwork there with our lovely three-headed dog. You probably recognize from the closing scenes of Harry Potter. But I am on the Red Hat Identity Management Team. Keystone is my day job. Let's talk a little bit about authorization in OpenStack. How do you do things at CloudScale? How do you manage? And this is just, I say thousands. I've talked about the million node data center, multiple million node data centers. How do you do things when you have to do things at scale? Delegate. Delegate as much as possible. Get other people to do your work for you. And this is the great American ideal as embodied by Tom Sawyer. What does it mean to delegate? So I, like most people, went to Wikipedia. And then I looked at a couple other definitions too. And I've chose three different definitions to put up there because I think each one puts a slightly different emphasis. One is on assignment of responsibility to somebody else to carry out specific activities. I really like that definition. It's a practice of effectively getting somebody else to do your work for you. And as a Keystone core, because my job is to review code, I don't want to write the code because then I can't review it. So my job is to get good ideas out there or what I hope are good ideas. Get somebody else, and there's a lot of these somebody else's out here in the front line, but to take this and actually make it intelligible and get implemented and then come back to me so I can say this makes sense or not. And then, of course, the other cores will rip me apart for design and rip them apart for calling something happy where it should be glad. And trusting a task or responsibility to another person. It's all about trust in delegating things down to other people. If you're trying to work at scale, and I don't know if you guys recognize this map here, but we're talking about probably the largest thing I could think of that involve large scale operations, and this is Operation Overlord in World War II, and yes, I was a military guy, and that's the way I thank you. And in fact, I have the book that this picture came out of. If you're working at scale, you have delegations essentially getting the job done. What we have here is the people that the American public delegated to. And in the center, we have the Spreed halide commander of Europe, Dwight David Iverson-Hauer, and some of the people that he delegated, pieces of that too. Most notably, two is left is Omar Bradley, two to his right is George Patton. You have to give tasks to other people to do, and you say what you can do, and you don't want them doing things beyond that. Strict delegation, but you have to empower them to get the job done. So how does access control, now I've given you the high flu and stuff, how does access control work in OpenStack? And I try to translate it from the literature that's out there to what we actually do. We're not really doing our back if you look at like how NIST defines it. What we're doing is scoped our back. You get this role inside a scope, and the scope, a lot of people might remember the term tenants, we call them projects now, but the idea is that we have some box, and inside that box, you have a role. And we implement this via ABAC, and the academics out there have helped me get my terminology clear. You don't have to use just your roles to make authorization decisions. Any of the attributes are available to do it, but we primarily, our engineering effort is around the role-based access control. And a user is, or a group of users, are assigned a role on a project. And then access control is checked, it can actually be checked at multiple points, but if you look at how the source code is written and how everybody's implemented, it's really checked at the API access level. When you make a call into NOVA to create a new virtual machine, when NOVA calls into Glance to fetch the image, there is a role, there is a policy check. Here is the sequence, what happened? I jumped right into a UML sequence diagram, I know, I probably, probably crazier. Let's see if I can get the laser pointer. Any cats here? So I'm saying the NOVA call stop that you have there. I'm stopping a virtual machine, okay? And the first thing that's gonna happen is my client, my application, is gonna call into its client. I put both the NOVA client and the Keystone client together, I didn't have that much space on the slide, but what's gonna happen is the library code that is specific to OpenSack, is gonna do a request to get a token back from Keystone. And then it's gonna pass that along when it does the post to the NOVA API to actually stop. And it's slash action. I had to actually look this stuff up. I don't actually use NOVA except to prove that Keystone's working. So you guys probably know this stuff better than I do. So that's gonna do a call into AuthToken. And middleware is a series of stacks. AuthToken is designed to be callable from any of the APIs that come on in. I'll talk a little bit about that in a second. But the first thing that's gonna do is that's gonna validate the token. So if we're using UUID tokens, and you might hear about Furnet tokens later on, or any sort of token format that requires an online lookup, it's gonna go back to Keystone and look it up. So if we're using PKI tokens, it could actually do this internally. But the net is that you get back access info. And I'll expand out what that access info is in a bit. And then it makes a call into the controller to fetch the data out of the database. You can't enforce policy until you know who owns it. If all you have is the ID of the virtual machine, the thing that you need to get out of that server is what projects is it in. And then finally we get to our policy. And we're gonna say enforce. And we give the context, all the things that can be used that can feed in there. The action, in this case, it's that we're trying to do this stop call. And the target, we're stopping this virtual machine. And it's gonna say yes or no. And in this case we said it said yes, the response comes back, we get back our 204. And our application goes on and performs its operation. So in there you can see that there was this middleware piece I talked about. Keystone middleware, this was something that we split out into its own project. It used to be part of the Keystone client Python module. And we split it out into its own because it really is doing a very specific thing. And it's the middleware pieces, the pieces of Keystone, the project team's purview that have to run on the remote services. And this is by far the most important one. It's in the middleware stack four in the endpoint. So this is code that is running on Nova on Glance, whatever. And it, as I said, it validates a token. It will reject an invalid token, expands the access info as you saw there, whether it does it in process or by going to the Keystone server. It has the headers to the context. So you can actually use the data from that token in Nova and they do. And so we have to pass that on down. And there's a config option to let the request pass if there's no token in there. And that's actually kind of important. But it does not enforce policy itself. The application, Nova or whatever the endpoint is, actually enforces the policy. And that is because Nova knows how to fetch something from the back end. I'm not saying any of this is how it should work. I'm saying this is how it does work. Now, we have constraints and I'm trying to point out and give a reality check on what's going on there. So let's talk a little bit about Oslo policy. This was the step that you saw in there where it actually made the yes or no check. It's a rules engine. And it will give a yes or no answer to whether can I get access to this thing that I'm trying to get access to. It uses the token, uses access info and the endpoint decides when to call. It wasn't incubated. It was code that was copied. Does anybody here, I don't really want to go into incubate. Does anybody here not know what I mean when I say incubate and raise your hands? Yeah, you're lying. Okay, that's all right. It's been promoted to its own library but only Keystone is using it as a library which means that even if we make changes to Oslo's implementation library, the older code still needs to be ported forward to use it, so there is stuff that's in transition that's going on here. So as of Keylo, only Keystone uses it but we envision fixing this very shortly in the next development cycle. Let's talk a little bit about the rules the policy has. There are a bunch of different rules in there but these are the ones, these are the workhorses, okay? You can say I need to and a bunch of checks together. You can say I need to or a bunch of checks together so if any one of them passes, the whole thing passes and if any one of them fails, the whole thing fails. So if any one of them passes but the other two don't, it's still a failure and based on these two rules you can build up based on the most base level thing which is a generic check. There's actually something called a roles check and roles check is not significantly different from generic check. If you understand the generic works you'll understand the roles does but roles is responsible for basically saying does this equal this? Does something in the context that I'm working with? Does something in the token match some fixing? So here I had one where I wanted to check an endpoint ID and this one of the things that we're working on I'll talk about later is the ability to do endpoint binding of tokens. So say you wanted to implement an endpoint binding of token and here's an expansion of a subset of the token data and I'll go in more detail to this in a bit. So you can see here there's an endpoint D. So I need to be able to walk this path on down here. So this is not a really an and it's not really an or. I need to be able to match say if anything in this level here matches then this matches. So this is your general tool. If I only want to make one thing work you use generic check and then you build up more complex ones with the and or the or checks. Here's an expansion of the data that comes from the token and this has everything we have to work with. If you look here we have our user and all you have to work with is ID name and if you're doing policy based on password you're wrong and in fact the password should not be in the token itself. This is in the user model. So I reuse an old slide site token user domain roll or token project domain roll. Typically only Keystone is doing stuff on domains. This is your path here. What role do I have on this project? And you can see the service end points are in there as well. So let's talk about the defaults. This is what you get out of the Git repos upstream and most of the distributions package up for that. Let's talk with Nova by far the driver for how policy has been done for the core projects. It was the first one and everybody copied the Nova one and then adapted it to it. So there's a bunch of common roles that are at the top and then I have some examples of API calls that will call these different common roles. Context is admin and you can see role is admin. Now what's lacking from this right here is a project. It is an unscoped and you can see that that comes up time and time again. Then we have the idea of admin or owner and you can see that their definition of owner is just that the project ID matches. It doesn't actually check the role. So all that stuff I said earlier, remember atom lies. This whole idea of scoped role access, that's how we want it to work. That's how it's designed to work but we don't actually get it from the defaults. So how do we get there? Okay, and the default role is admin or owner. So if you look at an API and it doesn't specify what to enforce, it's gonna specify admin or owner. And this one right here, compute create, if I understand correctly what it's done is it's basically saying you have to have a valid token. It doesn't actually match any rule there. I'm not certain if that's the same as default and it's scary that I don't know how that does but it's one of the things you go through when you have your assumption and when you actually go to make a presentation you go to check your assumptions. You discover these little edge cases. So you'll see this pattern and in fact when we get to glance, whoop, when we get to glance you can see that that's all over the place. Almost all of them are just like that ad image and it's copied over, the context is admin. So this is really not, it's the simplification of what you saw from Nova. Neutron is a little bit more complex. It's got the same header information as the other ones but then it has some rules that are really specific to doing networking type stuff and you can see that they actually need to be able to do field networks shared true. So there are custom plugins and custom rules. You don't have to use only the rules that are shipped with auto policy and Neutron goes beyond that. And that's fine because everybody else can just ignore it but that does mean that it has to be there when you are executing the code on Neutron. But again, this is all the stuff that you get by default, this works, we know it works because otherwise we'd be fixing bugs. We're fixing bugs but not these particular bugs. Okay, Keystone's the fall policy file. Keystone's weird, okay? And I say that because I work on Keystone I know how weird it is from day to day. As I said, I've been doing this for a while. We have this idea as is admin is one and if you see that, you might not realize that that means that we have this whole way of bypassing all the checks. That we actually have this thing called the service token and it's designed to prime the pump. It's designed to set up a Keystone server before you have a user database or any rules assigned. And so is admin is in there. Now, what I discovered again, looking through the code preparing for this is this is actually checked outside the policy check. You don't need this in the policy files but it's there. We have idea that service roles and this is for Nova to go to Keystone to validate a token. So when you validate that a token is or is not valid you have to say who you are. Nova has to say, the Nova user has to say I'm the Nova user and it passes, it actually gets a token to validate a token. And so this is what's used in that call there. And most of the calls that a service user can do an admin user also needs to be able to do. We reuse the term owner but you can see we've just find it to mean something completely different. Okay, and then admin or owner which was the same thing that we had in Nova. Again, it means something different here. Token subject, this is weird and so forth so on. So you can see that the different projects do not have a common view of things. And that has led to bug 968696. And I don't know about you guys but to me that's like the fact that we've got that repeated six and it makes it almost like the telltale heart. 968696 and you can see Gabe Hurley reported this a long time ago by internet time. And I think it was almost immediately assigned to me. So this is my albatross to bear. How do I solve bug 968696? I don't know, I'm trying to get there. And that's what this whole presentation has been driven off of. This telltale heart of 968696. Roles were global when Keystone first came around or when Nova first came around. You did not have a role on a project you just had a role. And that is why admin is everywhere. And we have to maintain backwards compatibility because people are building workflows on the cloud. If we change the default policy file that Keystone and Nova or anybody ships out then we're going to break things. So we can't just fix it. And I know because if we start talking about custom policy, here's the first one we had. Henry Nash who unfortunately is not here. Did a fantastic job of saying what should a policy file look like now that we know better? What is, so in the Keystone repository you have the cloud sample one and it's the first iteration of a better approach. It sets an administrative domain. So you have to edit this file before you deploy it to say here's my admin domain because we now have multiple domains, right? And multiple boxes that we can get users out of. And we want all our administrators to come out of one admin domain. But you have to tell Keystone what that domain is. Horizon unfortunately does not support domain scope token. So already there, David Lyle has had reason to throw large heavy objects at me because we broke in, we told people to use this and then we broke Horizon. So we, like I said, it's the first iteration of a better approach but there's more work to be done there. And if you look at it, there's a lot of ugliness that comes down to domain ID has to match all these different things. Where do you find the domain ID? And that's a tricky thing. And it makes the rules really, really complicated. So this is a good starting point and this was where I started, but we wanted to go on. The cool thing about the internet is you can get like a response from the artist, like this, you know, even though it's within his deadline to say yes, you can actually use this and I wanted him to use this. We want to be able to delegate but we want to be able to give only what's necessary to get the job done. We want to delegate as little as possible so we can go further, right? If you give away too much trust then you're reluctant to actually give away that trust. If a token has too much power associated with it then you have to be careful who you give those tokens to, right? So what we want to do is minimize the effect of delegation. So what can we do today? I need to speed up. Merge the policy headers. So you can see we had those different things there. We want to get to a single consolidated policy header and unify at least the Nova Glance and Cinder things. Probably even Neutron can fit in there. I don't think we're doing anything in Neutron that will break the other one so we can probably modify all of those but certainly Nova Glance and Cinder don't conflict enough that we can't find a way to make one policy file that would work for those. And I know I've got to prove some concept. I haven't tried every last API there but you can use one policy file to talk to all these because the API is a scope. Every API has a namespace on it that says compute or identity or something like that so you could put these rules all in one file and share that file across the different ones so long as everything else works and it's that everything else works part that we have to get to. We want to break member up into smaller roles. Member is everything that a user can do and I don't always want to delegate everything I can do. For instance, if I'm telling Nova to boot a compute node Nova should be able to fetch an image from Glance. It should not be able to write a new image to Glance. If I have to do a backup, syndrome might need to be able to write to a specific Swift object store. And again, I'm making stuff up that I've heard from other people. I'm like a monkey repeating the actions that I've seen. I've heard that people need to do this and these are the places where delegation breaks down if we make things to draconian. I want it so that when you go to do that all you can do is post to that particular object store and not everywhere that the user can do. I want to delegate a subset of what I can do. We know that we can remove is admin from the line because that's checked by code outside there. So that's an easy cleanup to do. And what we can do today is we can say fetch policy via endpoint policy extension. You can actually on the Keystone side, and I didn't talk about the policy API at all, well again trying to cut this down to a manageable amount, but you can fetch policy out of Keystone. And to date that has not been really really usable because you just fetch based on a generic ID. Well what we have now is the ability to fetch based on your endpoint ID. And this is cool except for the fact that we have to figure out a way of telling Nova what its endpoint ID is. So there's a little bit at the setup stage of things that there's some work to be done there. We know that things can be better, but at least we have some tools in place now. And all this work through Juno. If I'm telling you to go and write your own policy files one thing you should understand is that a rule can be thought of as having a scope section. Where do I find the scope in the object that I'm doing? Or is it part of the request? Or is it, if I do a delete, I need to get the object. But if I'm creating a new object in a container that service, the project has to be in there. So where do I find the scope? And then what role do I wanna have on there? And once you start thinking of these things this way, it makes it easier to come up with your own policy roles. So example, compute-create. The project ID just has to match, because I say in the API and it gets it out of the URL, here's the project ID I'm in, and I'm creating a new virtual machine in that project. And I wanna make sure that the user has either the role admin or the role member. And I would actually write it at this way. I wouldn't try to collect these things up at the header because I wanna be able to tweak what's going on there. We'll talk a little bit more about how to make that a little bit more manageable. I wanna explicitly match the scope. And then the question is, and once you start working through, you say, well, how do I get a token for the right scope? Because we have this idea of admin anywhere is admin everywhere. So if I'm the guy responsible for fixing in the cloud, I need to be able to get permissions into this project. And how do I do that short of giving myself admin on that project for everywhere? And it's a tricky problem. So in this next slide, I should make at least somebody here happy. Hierarchic multi-tenancy. It's a cool, cool word. And it almost, it's got that same kind of rhythm. It's got a little bit more of a Latin rhythm. You know, we've got the Brazilian team here going, Oracle, I can't quite get it into a sample, but I don't have the hips for that anyway. Hierarchic multi-tenancy nested project. I say new and kilo. Again, this is one of those things that is a moving target. What is really new in kilo, and the important part here, is role assignment inheritance. This means that if I assign a role in a parent project, I actually get it as a, so say I assign the role member here, and I say that this is an inherited role, I get it here, here, and here. Now, one thing we need to fix, and I know you guys, I promise I'll finish the code review on this. Role is actually either on the parent or on all children, which is wrong. You should be able to say here and below, just below, just here, but we'll fix that. But there's ways you can work around that. You can see I actually had it as a three level. So if you assigned it here and say it's inherited, then you can get it on a parent project. If you need to have some resources shared between these, like maybe the networking stuff, and then you would also inherit it all the way on down here. And so that's the effective role. You have the role effective on all these things here, based on it being assigned to the parent. Really powerful tool, and it should allow you to be more flexible in how you do policy. What can I do? This, I think, grew out of a conversation with, I know it was the Horizon Ptl, I just don't remember which, because I don't remember which summit it was at. I've been a few of these. Horizon had the problem, it needed to be able to figure out what to show to a user based on the token it had. And it turned out with policy today, you can figure out if you have a token, and if you have the policy file, which APIs would pass or fail? And in fact, I wrote a simple CLI, I got my, this is the one patch review I did actually put up here, because I wanted to be able to find it myself as I'm going through this. But it's a tool that I would expect people to use for iterative policy development. I have the token, or I'm gonna fake up the token, and I wanna see, will I still get access to the delete API if I make this change to policy? So I would expect people to work offline. Don't do this stuff in production, please. But you should be able to test out everything that you wanna do in development before you deploy a new policy file. And you don't need tooling to do it. So this was the first identification of a tool that would support that. As I said here, it's assuming that the target project ID, matches the scope of the token, and that may not be sufficient, we'll learn as we go through on this. I expect this to be a growing effort. And as I said, Horizon today has a similar logic, but it's using a cached version of the policy file. So what we need to do between the Keystone team and the Horizon team is, as we get this stuff that I'm gonna talk about later, better developed, making sure that Horizon is one of the primary consumers of it, so that it's not just stuff that you get when you use a CLI operation, but that Horizon can make part of the normal workflow. Okay, so I'm gonna talk a little bit about the stuff that's in development. Why am I doing this? It really is a risk management thing, because if you can't trust your delegation mechanism, then you're either gonna delegate too much or you're not gonna delegate. We need to manage the risk of delegating, but still manage to maintain the chain of responsibility. If I do something on behalf of my boss, we need to know that he's the one who authorized me if it's a group resource. And in fact, it may be that we need to see that he was actually authorized by his boss's boss's boss all the way up. If you look at how roles are assigned right now, we don't have that, but we do have it in the trust stuff. So we at least have a model of how I think this stuff should work. And so that's one of the things we wanna get to. We wanna minimize the attack surface. We wanna say that when I have a token out there and that token, if it gets compromised, it can't do all that much. Right now it can do, well, way too much. I'm not gonna tell you what all that is because I don't wanna give you nightmares yet. I'll take them nightmares for now. Determine what roles you need to perform some action, as you saw in the last one. Delegate a subset. I don't wanna give out everything I need in this role. I wanna be able to take a role and break it apart and give out a subset of that. I wanna be able to determine the capabilities from the roles and customize the policy for an organization. And it all goes down to that. I want to be able to customize a policy for an organization in a managed risk sort of way and finally close bug 968696. Okay, so let's talk about distribution of policy. Because right now policy is a JSON file. We actually ship it in the RPMs that we have as part of the RDO and REL, and the, or excuse me, REL OSP. Keep changing the acronyms on me. But the package is a week's have. So if you think of us as a downstream from what goes there, Debian has the same thing. There's packages that are built out of the stuff that goes there. The policy files are in there. Don't treat those as code. Treat those like config files. Treat them as a starting point for configuring for your own thing. And then figure out how, as you modify these things, you're gonna distribute them on out. So that's what I mean by policy distribution. I'm probably way over time. I got 11, 44, I got 10 minutes here. I wanna get time for some questions. So you know that we can fetch the policy file from Keystone. We need to make that process part of how we do business. We need to make the policy fetch from Keystone built into the policy. So having Oslo Policy as a library gives a place to do that. It's gonna be a handshake between Keystone Middleware and Oslo Policy to manage the cache of that file. And we need to have a default because there needs to be something. You don't need to be able to, you don't wanna have to say, okay, Nova used a unified policy file and this new endpoint of Nova used that as well. You wanna be able to have custom policy for a specific endpoint, but we need to have a reasonable default that everybody gets by default. That's why it's a default. Okay, so what's gonna happen then, this is the same diagram as you saw before, but now I've kind of blown out this sec here. We've gone through, we've expanded the token and I'm enforcing. And if I don't have that JSON policy file, what I want is the controller, whether that's off token or something here or maybe something in between, we're still debating exactly who owns that, but whoever makes the call into policy, that's gonna trigger a call to actually fetch the policy and then we'll have a cache management discussion to have. How long do you hold on to that? How do you ensure that you get a new one if it gets overridden and so forth and so on? But we do know that we need to make, fetching the policy file from Keystone here dynamic or we can't do some of the other stuff that we wanna do. Is Yoram here? I saw Dr. Chadwick walk in and hey guys. So this is your ERD, I kind of put it on over. We'll discuss the details, but I wanted to point out these guys are working on making it so that instead of you uploading a flat policy file, we're gonna manage it from a database and that will allow us to do rules level management and be able to make this stuff more granular. The guy who just took the picture, I assure you it's not gonna look like that when we're done implementing because this thing is gonna get raked over the coals and this is the first point where I say we need to look at this really, really closely to make sure it's meeting everybody's requirements. But the idea of putting this stuff in a database is essential so that we can manage it and then generate the policy.json from that and that's not really different from how we do anything else and it opens that, but it is an iterative process so we need to get there. We wanna be able to compose the roles hierarchical from these finer grain ones as I talked about before. And we wanna be able to break member up into smaller roles and this will be able to consume that. I probably should have put stuff more about that earlier in the presentation. I have a good diagram for us coming up. We wanna come up with better guidance so this presentation here is the start of it. Getting better documentation out there about the policy stuff, making it a part of the community, understanding how policy management, so we can have these discussions. Getting the default roles more fine grained so we can specify you only need this role if you're an auditor. You can only read things. Being able to enforce only on the Keystone V3 API because the V2 API thinks are all over the place and we wanna make sure that we have a consistent view on that context of how we're doing it. So even if we keep V2 tokens around we need to make sure that the enforcement is done on the V3 format and getting that to come on over. And better matches of the roles of the API. So, let's see, what did I do with that? I don't know, I must have cut out that. I had another diagram where I showed before I get into the vision. I wanna talk a little bit about the idea of composing roles. If you are member, assume a member of project, that was actually something we retrofitted in there because it used to be that projects owned users. And so you had two different ways to say that this was a user, was a member of this project because the project had created or they had a role assigned on the project. And we said, well, aren't we really just saying that a project owns a user is really saying they have the member role on that project? So that's why that's one of those funky ones you see there's a little underscore and all that. It was to make sure that we didn't break anybody. He had already said that member was an explicit role. Again, keep them breaking horizon. But that's too broad. That's everything that anybody could possibly wanna do within the scope of that project. What we wanna be able to do is say, you can do, the admin assumes everything that a member can do and more. A member is composed of people who write things. And writer kind of assumes that you can read things. So you might wanna call this role inheritance and NIST does call that. Unfortunately, somebody already used the word inheritance and you saw it in the early thing when we talked about role assignment inheritance. So it's a really confusing term. I might stray from the NIST and use a different term role composition. It's really a set. And we wanna say does this set that you have here have this particular capability? Does the set of APIs that are associated with this role match the API that you're trying to do there? But the general idea is that you should be able to build things from lower on up higher. And I had a really cool slime that I seem to have deleted, bummer. So I wanna get to a unified, so we're getting to the vision. Or as I said, the part where Adam lies. I wanna get to a unified delegation mechanism. So I want role assignments, trusts, OAuth, all these things that do it to all use the same mechanism. I wanna track who is able to do what based on who assigned them that delegation. I want to deal with the fact that the person who assigned you that may no longer be authorized to do it. But you still should, because you get it from higher up or whatever the, to reuse the word policy, whatever the policy is in your organization, you should still maintain that authority delegated through somebody who no longer has that authority themselves. And I wanna be able to break down a role so you can assign a subset of that role so we can minimize the tax numbers. We're gonna need some sort of pre-canned delegation agreements. We're gonna need to be able to make this really lightweight so you don't have to go through and say, I'm gonna build this whole, you can do this, you can do this, you can do this every single time. It's gonna have to be something that's lightweight. But we're talking about beyond the liberty thing. And I really wanna get it so that we use a pre-canned thing like this so that when you go to Nova and say boot in Nova it goes over to Glantz. It's gonna get a token there that's appropriate to that. We're figuring out how to get a token for a token in a safe and secure manner based on the workflow. That's one of the things that we really need to talk about at the developments of it today and we will be talking about over in the Keystone rules afterwards. Okay, so we'll give you a little conclusion, open up for a minute or two of questions. Customize policy. This is the imperative form of the word. Go and customize it. Do not just accept the defaults as being appropriate to your organization because they're not. We can't afford to break the defaults to keep a break of people, so you go and break them yourselves. And you do that and make sure that you test, test, test these before you deploy in production, but we'll try to get you better tools for that. And come back to me and say, this is what we need, tools-wise. But work for better support is underway, okay? And with that, I hopefully have given you something to think about and given you a reason to hope, but maybe also disappointing a person or two who's hoping for more from this. So this will be a chance where I'm gonna open up for some questions. Shlok will not shoot you. I won't shoot you. But let's, please use the microphone up there if you have a question for me. And I have 11.52, which means I have three minutes for questions. Hi, thanks. Does this work? It does. I can hear you. Oh, great, okay. Army as well, and I posted to that bug, so thanks. Cool. So a couple things. For application developers who are trying to leverage the API to use OpenStack, there are several pain points, some of which you touched on. For example, the whole project scoped authentication token, which by the way, I've had to use V2 in the past because V3 does not work the way I expected to. I haven't seen a project scope token and V3 work consistently, actually. The problem with that is, when you break it down into auth calls, if you're doing app development, the number of authentication calls you have to make to each container you're trying to manipulate, ad nauseam just gets very un-pragmatic very, very quickly. And the idea of inheritance is intriguing to me because really as a developer who's building an application so someone can leverage OpenStack technology, I want a token that says, okay, I authenticate, this is my scope token, be that even at the domain level or the project level or what have you. And then this token is good to manipulate. For this workflow? Yeah, all the objects for whatever that token has access to. I don't want to authenticate to each project. In fact, if I'm a member of project A and I want to do an action on project B that I'm also a member of, that same token should allow me to do that. You talked about member breakdown. What about admin breakdown? Out of the box, admin is, there are cases. God. Yeah, you're God or you're a surf. And those are the only two out of the box rules. Five, nine, six, eight, six, nine, six. Exactly, so for example, I might want a member to be able to do everything possible, see other people's VMs, that sort of thing within a project and nothing else. In the same way, I might want to look at admin in the context of the user admin, for example. I'm a user admin, I'm specifically assigned to certain projects, which is different from the context of me as an administrator looking at everything. Horizon kind of illustrates this because they have a project tab and an admin tab. And there's no easy way to do that with the API for the user and admin context, so to say. That's what I'm trying to drive towards. Right. This is not the first time I've heard this pain iterated. So to address your first point though, to have a token that responds across all of those, I don't know if I can give you one token, but I can at least give you one authorization mechanism that spans that, which is what the hierarchical stuff is supposed to do. And I think I will go and say that an operation that's supposed to go across two different control things really should be two different tokens. You're saying, I'm going here and doing an operation, I'm doing one here. And I understand that you just want to have to authenticate once. Maybe it is that we provide a way to be able to get multiple tokens on one call, which would probably get you what you want. I wouldn't put it all in one token. But I think what you were looking for is the efficiency of I need to know what's the right token to use here. Let me fetch them all in bulk. And then go hand the one I need to know of and the one I need to glance or whatever it is. Let's say I wanted to create a dashboard. I'm an administrator for it. I think we're being kicked out of here. This is the, this is, get off the stage, you're boring. You know, this is the end of the Oscars win. My speech has gone on too long.