 OK, welcome all. For those of you who've come for music, sorry, that'll happen later. Apologize for that. I'm Henry Nash. I'm Adam Young. We're both cores on the Keystone project, the identity service in OpenStack. And a lot has changed over the last few releases about roles and how you assign them, how you consume them, how you pass your tokens around, and so forth. So I want to give you an update on that from Ataka to find some of the problems, as well as some of the solutions. We're not all the way at Ataka. I'm not sure whether it will be all the way there. But there's a lot of good stuff at Ataka that you might want to be aware of. And I would like to point out that this presentation is 100% unprepared, 100% unrehearsed, and we're making this up as we go along. I would like to also make explicit what I tell anybody when they ask me for advice online, which is that I lie. I make things up, so take what I do and verify. And that's my way of actually getting bug reports in. I should say our way. Henry is more reliable than I am, but assume that he's lying, too, and verify everything that we're saying here. OK. So the clouds are evolving. And the key of a lot of this stuff is the fact that when OpenStack First was designed, it was really trying to do AWS but in an open source way and be more flexible. And the model we had for how you encapsulate your resources and missions you put on that encapsulation and how you get authenticated for those resources reflected that. But that isn't what we want for public cloud. It isn't what we want for complex private enterprises. We need something much more scalable. And some of the things here have been added recently. Well, probably grizzly was really the start of this stuff. And then every release, we've had things that have taken us further down that path that mean it much more appropriate for an enterprise model for authentication, authorization, and access control. I'm getting this clicker here. You've got the clicker. So this is what we're going to talk about today. I'm going to give you the intro stuff. Adam's great contributions to the project has been he's been one of the people who's been niggling and thinking as they say, think about these problems that enterprises are going to have. Think about how they're going to do the security. He's been great at bringing those things from Red Hat customers into the open stack community. So when we get to the what's wrong bit, this man can whack lyrical. I'm going to let him. I thought you were going to say that I was what was wrong. So just a quick recap. I don't quite know where the audience is in the room on this. Got just three slides on just going to bring you up to the concepts of the way this works in open stack. Role-based access control, I suspect most people are familiar with that. In an open stack world, it has a slight nuance in the fact that you always assign a role for a user on a target. You can't say Henry has the role T-boy full stop. You can't say that in open stack. I can say I've got I'm role T-boy on project afternoon or something like that. But I can't just say Henry has the role T-boy. You can't say that. And resources, of course, are owned by the products. So that's how you assign roles to resources. You assign them to a project that encapsulates those resources. Or to the domain that encapsulates those projects. And that's kind of really the concept that you have. And once you've done that, you want to use that to actually go access those resources. And so in order to prove that you have permission, what you're going to do is get a token from Keystone, which means authenticating using a password is how it started. These days, federation is an up-and-coming way in terms of open stack. It's been around the community for a long time, SAML and OpenID and so forth. But that's really now fully supported in Keystone so you can use federation. But however you authenticate, you get back a token, an OpenStack formative token, not a SAML or anything else. And that's the thing you need to hand into every API request you make to whatever service you're talking to OpenStack. It's the only way you get to execute OpenStack APIs. And that token is going to include for which container, i.e. a project, typically, the container rules, did I actually authenticate to? Did I authenticate and did I say I want roles for this particular container? What roles are they? Who am I? And for some cases, how I authenticate is sometimes you need to know, what's useful to know, how you authenticate it. And optionally a catalog, that's kind of by the by as far as this discussion is concerned. Okay, no attention in the mirror behind the curtain. And once you've got that token, then obviously you're going to hand it off to an API call and hopefully magic will happen. Well, so how is it that that service, no over glance, what does it actually do? How does it actually take those roles and say, okay, yeah, I agree, you can execute that API or you can't. And this is what it does. So actually the other piece, it's really not part of Keystone per se, it's not today, is that each of those services have a policy file that basically says, for these, not quite written this way, but essentially says, for these API calls that happen to be part of my service, no, but what it has to be, these are the roles you'd have to have. Well, this is the role or roles you must have to execute that API. And that policy file is controlled by the service. It's distributed by the service onto their nodes, actually outside of Keystone's control. So it's like a, it's part of the distribution of the logic out to the service points rather than have it all inside a single service and hence not very scalable. And so that's fundamentally how the process of getting your permission out and validated by a service. We're gonna introduce polyfiles a little bit. If any of you have tried to modify the policy file, hands up who's tried to modify policy file in Keystone or in any service for that matter, you have my deepest heartfelt sympathy. And so policy files, they're not the most human readable, although in theory they're meant to be, format, but they basically give you, this is a very simple example here, of how you define some rules, in this case saying, what is the rule for compute delete in Nova? And you can have rules within there to give you some logic and so forth. And each of the service have these. Keystone ones is a, this is an example of the default one that was Keystone, where you can decide, in Keystone v2, basically admin meant you could really do anything. Adam, why don't you talk a bit about admin and policy files? There's a few examples on here for policy files. Why don't you talk us through some of those and then we'll get into the bit about what's wrong. So you want me to talk about admin without talking about what's wrong with admin? We'll introduce the policy files and it'll lead right into the problem. I don't wanna talk about what's wrong. Okay, so the admin role, if we can dig back through the mists of time to when Keystone was an internal project or rack space and not even part of, not even incubated, roles were global. And you see a lot of vestiges of this in the approach towards thing to the policy files and the enforcement, as Henry alluded to before, or said before. If you're admin and that's a global role then what does it mean to scope it in to a given project? How can I talk about this without talking about what's wrong, Henry? Okay, here's what's wrong with it. I'm gonna jump to it. Okay, the problem is, and if you wanna look it up in Launchpad, it is bug 968696. The one that says adminness is improperly scoped or if you're admin somewhere, you're admin everywhere. And this is okay when you're all one organization and admin is one person and you're supporting a small number of people but this doesn't scale. If the problem is that how do you deploy 10,000 node data center with a million virtual machines on there and in all the different pieces there you have to be able to do things more granular and so you don't want to give away the keys to the kingdom to every last person who has to be able to go in there and still solve problems for the people that are making use of the cloud deployment. The idea that it's all admin means that it all gets through one bottleneck and that bottleneck can be pretty tight. So what we've tried to do is identify, first of all, looking at the policy files, how these things work and if you look at the examples because as Keystone guys we tend to get myopic and look at the Keystone policy file but really what do we care about? It's open sec, we care about Nova as our primary consumer because if we can't get what we wanna do through Nova nobody else is gonna adopt it and then Neutron just takes it and they in spinal tap terms turned it up to 11. So here are a fragment out of each of those files. The top and the noble one you see context is admin, admin or owner, default. Those are rules that you'll see at the top of the file that are designed to be reused and the default is what happens if you don't have anything specified. You can see most of these things say that admin or owner. So is admin means the admin role, these things feel thrown down and that the project or that the project matches. It's not even really doing a role check. And then the last two bullet points on the Nova one are examples of how these applied, either a straight is admin true or admin or owner. Neutron you can see they're doing something similar but their concept and their user of the term owner is a little bit different. It's that the tenant ID matches because they're still talking about tenants, which is probably the single most confusing thing in OpenStack and I'm gonna apply the first rule of troubleshooting, it's all Adam's fault. We had this division in the terms we use and we inherited this. This came back to the day where Rackspace and NASA had different views. So sometimes you saw tenants, sometimes you saw projects and we wanted to get to choose one so we chose project and everybody still calls them tenants, so. Admin or owner, you see it's similar, it's really close but then they have this stuff down here like roll AD, VSVC, I think that's the advertising service or something like that. But they have this idea of starting to actually put in roll R back into place. Now I'm gonna hand this over to Henry because the V3 cloud sample was Henry's, I won't call you a magnemopus but it certainly was a slow work to get Keystone's policy file under control and one of the problems that we have is because people are deploying the existing policy files, we can't just change them without breaking everybody who's expecting the existing rules. So V3 cloud sample, while we've been telling people for a long time this is the way we wanna go, we can't make a bit of a fault. Thanks. How about that, Steve? Yeah, yeah, yeah. So as Adam said, the first thing we did when we said, okay, okay, clearly admin everywhere, it's not right, so of all the services which definitely need something more, it's Keystone. If you're in a public cloud, you wanna have cloud admin, domain admin, project admin and probably a few others that may be suitable to your own particular setup, how is it you're gonna provide that kind of level of differentiation? So shipping that ships with Keystone as well as the standard policy.json file is this other file called v3cloudsample.json which is meant to be an example of this. Here's how you would stratify your administration such that you can have cloud admins which look after obviously the whole cloud. For each of the say companies, typically a domain is used to capitalize a company or division in a company that wants to look after their own users and groups and projects so that you can then delegate the responsibility to looking after those users and groups and projects to admin of that domain, but they can only do that domain. And then within that domain, they want to create project admins that can only look after that project or a set of projects. So this is a fairly complex subject and we're happy to go through this stuff offline but if you look at this for example, you can see at the bottom here when it says, you know, what project can I list? Well, you know, so if I'm the owner, that's okay of the project, but you know, we will start to say, well, the role of your admin and you're a matching domain ID and basically what this tech said is, well, yeah, you can do it if you're admin, but only if you're admin in the domain of which the project is in. So we start including the logic to say, okay, well, you can't list all the projects if you're admin. You can only list the ones that match the domain ID. So what we're doing is matching is you got a token, perhaps with a domain scope token and then we can think, is the project you're looking at in that domain? And so the checks for admin matching domain ID says, you have been required and that kind of, you know, weirdo logic there, but he says, and the domain ID is the thing, you know, matches the one that has been passed in. So if you look at the VC cloud sample, it'll give you a starting point how you might stratify your administration, starting from a Keystone perspective, because what Keystone supports are back like everything else, to stratify those kinds of roles. The one thing we've, one new thing we've done in Metaka is improved and we talk about it in the presentation. If you're the second line here, if you think about, if I'm a cloud admin, the thing I definitely don't want is someone who's like a domain admin or a project admin to somehow make themselves cloud admin. Otherwise that kind of defeats the logic of this. So in this, We'll get there, Henry. We'll get there. Good example, we had to, basically you would actually, when you took the sample, you'd paste in the domain ID of the admin, of an admin domain, and that would say, if you're an admin of that, then only you can be cloud admin and nobody else can add roles to that domain either. But that makes a problem is that, you know, some have to paste the bloody ID in each of every time you stand up a cloud, not very scalable. So in Metaka, we addressed that as well and we'll talk about that later on. I'm going backwards, Henry. Okay. Back one. Enter Metaka. So enter Metaka. These are the things we've done in Metaka release that ease some of these problems. And as I said, not all the way there by any means, but we're taking an incremental approach to knocking down the barriers that help us have proper admin delegation and proper support for admin and preferential capabilities across OpenStack. So, Adam, do you want to talk about implied roles? That was your baby? Okay, let's see. Okay, I talked a little bit about Bugnide 686.9.6. And that was the first thing that we had to knock out is this is really tying us to a simple place. But beyond that, we want more fine-grained roles. We want to be able to say, well, we want to be able to say that somebody can be an auditor or an observer. They can only read. And that's probably the single largest request we've had for changes in the role stuff. But a lot of people, anybody from Dreamhost here? Anybody work with Dreamhost? So in addition to being an engineer here, I have been a customer with Dreamhost for a long time. And I've noticed one thing on their cloud that they did was they said, we're just going to set up the networking for you. You sign up with us, we'll create a project for you, we'll build the network for you. And then we're not going to let you touch that. Now, maybe there's some higher level of service that you can do that, but they don't let me touch it. They know better, I break things. So I think this is a pretty common pattern where you say there's something that is kind of an end user operation, but there's certain people we want to let them crawl before they trip and die. And so these people we want to remove some subset of that. But we still need to be able to give it back, give it to somebody else. So these idea of storage or networking, causing it trouble tickets, we want to be able to choose who gets this additional ability. Rebooting a VM. You might have some sort of monitoring system that has to reboot a VM, but it shouldn't be creating a new one. That doesn't mean that it should be able to create a new one. So we want to have a role that you could say this has only amount of permissions to reboot a VM. As a public cloud, this is all about delegation, not just delegation, but the ability to delegate delegation. How does it tell somebody that they have the power to do their job without giving them the power to do more than their job? And as we start talking at scale, this is going to become the major, major pain point. How can the enterprise map roles that are meaningful to them onto whatever the provider has created because they're not necessarily managed by the same people? Okay, so. And just to pick up one point to introduce that. Part of the vision is that we're seeing here is that today there are typically most clouds have few roles, partly, you know. Because we don't ship them. We don't ship them. If you play forward your mind to when cloud providers, you know, as the public cloud providers particularly, and private ones as well, if they want to attract the maximum number of customers on a given cloud, they're going to want to create, you know, you know, probably the most fine set of roles they can, such that they can give everyone the freedom they want. But it doesn't mean everyone wants the same freedom. So how is it that they can have many roles, but they might just super complicated for everyone? That's the dichotomy. As we think we'll go to many more fine grained roles in your cloud, we need ways of packaging them up sort of thing or aliasing them so you can actually give them out in reasonable chunks to particular customers or particular sub-customers without complicating it for everyone. Okay, so I think I went the wrong way before. This I think is the next one that we're supposed to be talking about. So to get to the internals of how things happen in Keystone, often I'll have an idea and I'll put it out there and some people will tell me I'm crazy. Well, everybody will tell me I'm crazy, crazy about this specific idea and every now and then I'll take something and Henry will take that to the next level and that's what happened here. So this was my first idea and this went through a few iterations just here. If we make it so that you can have role chaining where if I assign admin to you, you're automatically a member. Now I don't need to go through and create a specific assignment for all my admins to be member in order to enforce policy on somebody that they have to have the member role. If they're an admin, they're automatically a member and if I want to take something like member, this big one and break it down to two parts, say I want to take the network stuff and break it off. So I create a network member role but I don't want to break everybody already. I could say that member implies network member and then if I want to take that away in the future I can have power member and newbie member and only the power member will get everything but to start off with I need a way to move forward and that's where this whole thing started from. How can I take what I have now, make it so we can change things and yet not break everybody. So prior and implied, the prior role and the reason why it's not called existing or explicit is because this is chaining. So A can imply B, B can imply C and by getting A I get all the way through to C. So if admin implies member and member implies observer, if I assign admin I get observer. It always has to start with an explicit assignment. Keystone is gonna look for what you have explicitly assigned when you do something with a token API and then expand out all these implicit in a chained manner. They can be defined via the web API or Python only for now, we didn't get this all the way through to the CLI but this does work, this can be used now. So this right here is the first I think the most powerful tool for getting us to be able to move forward. I'm gonna figure this out by the thing. So here's an example of creating it using the Python API. If you have the member role created, the reader role created and we list, you can see what you have there. I guess I cut out some of the really cool stuff which is actually setting up the implication thing. Do I have that in there? Oh create implied, yeah there it is, the last line there. So that's the API that you do. This says member as the prior role implies the reader role. And then when I go and request a token for somebody who already has a member assigned in the token response. I don't know why I'm pointing at this, I don't know where the actual clicker is. You can see that both roles will be expanded out there just as they would be if they were explicitly assigned. It is the same thing in more detail this is what people are looking for. Admin implies member, member implies reader, admin can imply read admin, audit reader. You can have it as a, it's what's called a DAG, a directed acyclic graph. So you might have two different ways that you get to the same implied role. And if you assign both three so you don't have to worry about cycles and all that kind of stuff, it will resolve. It resolves to a set. So the rules are designed to say don't follow the same path a couple of times and you blow it on out. But you can come up with these kind of things that have multiple ways of ending up getting these really fine grained roles. So if you wanted to change owner to member in the policy files, then you can do role colon member. That's I think clear. You're saying if you are a member you can do this and you don't have to have admin or owner roles because admin implies member here and it'll keep the policy files smaller. Now you're starting to build tighter coupling between the custom roles and the custom policy files. So there is a little bit of overhead that we are putting on your shoulders which we're trying to make this stuff better in future releases, but we didn't even have the tool before this is the first step there. And one of the points about that is that you could do this today by just modifying your policy files and making them very, very complex. I think that's a bad idea partly because the more complex a policy file is just either harder to understand the harder it is to convince yourself that you're not creating loop holes and abilities of people like APIs you don't want to. And so by separating this to say let's make the policy files as simple as we can and then put the, if you like, the chaining of those roles basically into the database and accessible by the API then you can actually set that up, modify it, convince it and analyze it more closely and tune it to what you want without having to go change policy files which would distribute out to all the nodes. So you need to make sure all the nodes get updated with your changes. So that was one of the reasons to go this direction rather than just let you kind of build an ever more increasingly complex policy file. How many people are local to Austin here? Anybody, okay, so I was thrilled when I found out that we were having this that there's actually a shopping mall here called The Domain. And so that's the picture of what we have here for Henry's domain specific roles. I wonder where you got that from. Yeah, this is actually here in Austin. So this is the case where Henry came up with the idea of domain specific roles. I think first or in parallel to becoming with the applied roles and it was one of these when we started talking we realized that they were complementary. So we implemented implied roles and then we got to this. And so this is taking it a stage further. Think back to when I said earlier imagine when you have clouds with many fine-gain roles potentially with change as well with implied roles. A given customer comes along and you host them on your cloud. They have a domain and they get to create all their users and their products and so forth. And if you're a cloud provider you're essentially gonna give them the sheet and say well here are the roles that we've created for you because they can't change the policy file only you can change the policy file. So this is it guy, Mr. Customer. This is my 20, 30, 40, 100 whatever roles I've created. They may mean nothing to me as a customer and to my users, my admins, you know, VM crates. I don't know what that is but I may want to map that onto a set of logical roles, alias roles that mean something to my users, maybe to my, you know, names of my entity, you know, teacher administrator or whatever it happened to be. So we want to provide a way where, you know, given that you may have a large set of fine-gain roles you can basically use that same implied mechanism by creating an alias role which is private to your domain only you get to see it, only you can assign it. And it doesn't show up in the token. And most importantly, and it doesn't actually show up in the token because actually what we're doing is at token creation time, we're gonna expand that out into the actual fine-gain roles the cloud providers has created, which means I can give the power to my domain or industry to go do that modeling themselves and it's not my job as a cloud provider to do it. I don't even understand their industry, probably. I can go do that, but I don't have to change any policy files when the tokens get created, basically the actual roles that those alias is imply are the things that get put in the token. Yeah. The specific token's pretty big. No. The main specific roles, definitely not. The implied roles can, but it's not a huge amount that goes in. If you compare this to like one entry of the service catalog, it's nothing. There's not a lot that's in there. If you did really, really fine-gain roles and you had them all expanded out, then they could get huge. And if we get there, we'll won. I can't wait to have that problem and we'll find ways to optimize there, but we're not there yet. But the other point about it is that if you use one of the things that's come into Keystone, certainly in the last release, and been hardened in Mataka, is FNA tokens. FNA. FNA. FNA. It is not FNA? It is not FNA, and you know what, it's based on a really vile, vile tasting alcohol. So FNA tokens were a new token format, came in in the last release. And they're really a, it's a slight off-topic, but relevant in terms of the fact that Keystone's been on, part of Keystone's journey has been on, well, what is the balance between having a token which basically tells me everything I need to know, for instance, perhaps, that I don't have to go to Keystone to validate it or have nothing in the token, so I've always got to go to Keystone to validate it, or have it stored, prepared in a table in Keystone so I can read it out. We've kind of been down that journey and they've all got their pros and cons. The most modern version is the FNA token. Yes. Which says, I'm gonna put as much as I can a token without blowing it up too big and then actually the set of rolls don't go in the token. So if you have a complex set of rolls, they don't actually go in the token, that when you validate the token, they'll get filled in for you, but it doesn't actually cause the token size to be blown up. Right, tokens are a big size. The other thing, just as we're talking about, rolls is that, Do you wanna go for it? Thank you. This thing's jumping on me, it's actually me advancing on you. I believe you. As we're on this topic is inherited roll assignments. Something that... I chose the picture. You did choose the picture, thank you. I appreciate you honoring our great roll family. That's very kind of you. Well they have inherited rolls, right? These two gentlemen here in front of you have inherited the rolls. I couldn't think of a better way to illustrate it. I got it. And we pay em a lot. I know, I know, I know, I got it, I got it. Don't say, don't say, don't say, don't say, don't say, don't say. And these have to be the instance of Anna. And they're really designed thinking about, okay, so if I'm gonna create domains, you know, maybe inside a large enterprise, you know, various divisions, or even a public cloud, if I'm, you know, there may be still some relationship between the cloud provider, the cloud admin, and the products within that domain. Maybe I've been given, maybe I need to have a role on each project to, I don't know, back it up or be able to get in there in an emergency, whatever it happens to be. And whilst there are other forms you can do in terms of trust and so forth, one of the ideas was, let's provide a facility where if you define or put a role on domain and mark it inherited, at runtime it'll get inherited to any project in that domain that exists now or created in the future. It was a kind of relatively specific case. Now of course we have, since the last couple of reasons, project hierarchies within domains in Keystone. So it's not a flat tenant as it was called model within domain, you can actually have a hierarchy of projects within each domain. And so of course you can actually use inherited role assignments, you know, assigned to any point in the tree and you know, if you like, you know, the tree below that will get those inherited role assignments. So it works exactly the same way as it did before. Using effectively the same API. And you can actually also use that now to better model your role requirements within your container real estate, your resource container real estate. And just one word of caution here, slightly because it's heritage, if you assign an inherited role at this point, it applies to all the roles below you, not that particular node. You can also assign a non-inherited role to that node if you actually wanted to be on the node itself, just a word of warning when you try this. It might not do what you expect, but it comes from that original idea of you're gonna put it on the domain, it's gonna go to the projects. And we did actually consider changing those semantics with what actually the complexity of changing it and having some one way and some the other will be more complicated than leaving as it is. So we left all of that. And as you're aware in computer science, one of the hard problems is naming, stop jumping ahead on me. That's not me. The term inherited role assignment, if you're used to NIST RBAC, is what I talked about before with implied roles. And one of the reasons why it was called implied roles is because we had already sat on the name inherited roles. I like inherited here better because it's inherited down a tree down a hierarchy. So I think this is the clear use of it, but it does mean that we had to diverge from how things are discussed in literature elsewhere because we're different, you know? And we like to think that, I was gonna say I like to think that we're better, but we know that we're not, but we are different. Five minutes. Five minutes, okay. By the way, did you take out the slides on how we enforce Is Edmund Project? Yes, the last one. Okay, it's live, okay. So if you're going through and you're trying to modify policy, as a lot of people have done here, I gave you a tool, well, we gave you a tool that I think you're gonna really like, which allows you to check what a policy would return without actually having to deploy in an anger, okay? So in this is part of Oslo policy, the library, you run it against a specific policy file. The access dash s access is like a JSON snapshot of what you would get from a token validation. The big thing we're looking for in there is the roles, but if you look, there's examples of token validations or just do a token validation and catch that from the API, you can see what it will give you. And you run it against a file and say, A, I wanna try this one specific rule and the example I have down there is I'm looking against identity list user, or it can run it against all the rules in the file and say pass, fail, pass, fail, pass, fail. And you can do a delta, keep a log up. This is what I had before I changed my policy file. This is what I had afterwards. I'm getting the same results. I haven't broken anything. This should help you to move forward. And also you can have different token bodies, a token validation request or off data, whatever you wanna call them. So you can say, okay, now that I'm doing this more fine grained role, do I get a true here and a false here? So this should be a tool that helps you develop new policy to make use of the other tools that we did with the implied roles and domain specific roles. And here's an example of what you would get. I didn't do the whole thing. I did a head five of, if you did against all the ones in the cloud sample that Henry talked about before. Okay. I don't know why I chose to put a picture of Major General West, except that I'm kinda proud of the first female army surgeon general. But there's some tie-in here that I'm sure I'll remember tomorrow. Tokens, okay, this gets back to that original problem. I originally had the slide at the beginning. Henry put it at the end. It's completely tricked me up, but it's good that we're landing on this one because this is that pain point. This is a case of one of those things that we can't change by default, but you can change in your deployments and make yourselves happier. Although we did find a way to figure out how to change it by default in the last one. I'll talk through that with you later. If you add these two configuration options, admin project domain name and admin project name, and by the way, that project better exists in that admin domain, you've now created this magic thing which is an admin project. And any tokens that you request that are scoped to that admin project will have an additional field on there which is you can see token.isadminproject true. This means you can write new policy rules that separate out, say, I'm doing something for adding a new hypervisor and differentiate that from I am doing project level administration. It also gives you a way to say, okay, either you have to have admin scope to this project or admin scope to the isadmin project because you wanna only get one token to do all your work everywhere because we've actually listened to you for once and said we're not gonna make you re-scoped each project. Okay, this is gonna take time to change upstream. We can't change the defaults without breaking everyone. As much as I really enjoy breaking everyone, they just don't let me do it anymore. The Keystone Cloud sample does have this change in there. This is one of the places where we could do it. We put it right next to that thing that you would have initially cut and paste. And so you'd have to cut and paste anymore. You change your config file and now Keystone will behave according to this. We tried doing it with the Keystone default policy file and you can see the tests that are failing. It'll give you a sense of the problems that we're getting there. And we'll need to identify on the existing policy files the difference between a cloud admin operation and a project level admin. So there's been a lot of talk, the UX effort here with personas and all that that's going on elsewhere. We're not doing this all. We're not the only people playing on this. There's a lot of future work to be done here. We need input. We need data. We wanna know how employers wanna manage the policy files. One of the things that we were told in the past when we tried to do policy as managed by Keystone was we have content management systems. We wanna use those. We're not gonna change that. We're not gonna buck the system there. But we still wanna say, do we wanna strive for a more collective view? What policy looks like across the board? Make sure that we are consistent as we pointed out those differences between how Neutron and Nova view ownership and all that. And make sure we have a consistent way of talking about roles, at least through the things that used to be the core. And as the tent gets bigger and bigger to be able to talk about these things in a reasonable way for the as a services like Trove and all that working on top of Nova and Neutron. And can they actually figure it out? Will cloud administrators and to some extent, the managed administrators be able to work out what a given user can do? This request came to me from the Horizon PTL about three years ago. They wanted to be able to figure out from a user's token, what should they show in the UI? Can we figure out for this user, what can they do? That's something we're still working towards. There were so many stages we had to go through to be able to start addressing that question. So with that, I don't know if we talk right through our answers or our question answers period. I'm assuming we have, and bye. Get out of it. Any questions? This looks a lot simpler than what was there before in some ways, but as a private cloud owner, operator, admin, it's really not that useful still. What do you want? Problem I have is those are all managed on the individual control planes or nodes and all of that. To see what's happening, it's very easy to, oh, on the Keystone policy, I made this one and I forgot to change it on the Nova or on the Neutron. All of a sudden, you're managing all these files and they have to be deployed out, like I said, to dozens or hundreds of nodes in order to be applied. So I ask this question every six months or so and please forgive me, but when are we gonna have something more like AWS IM roles? Where we can say, here's a user group, not a role, but this user is part of this group that can do these things in this project or this tenant instead of having to make system level changes or create a bajillion different roles so then those domain specific admins can then create ones that are inherited based on that instead of just like the domain admin says, this is what I want these users to be able to do. And then as a step two, an instance, being able to say, hey, find out more information or make these calls to other services. So obviously, yes, we're not gonna do it, it ain't gonna happen, nope, wouldn't be prudent. So we obviously do have group assignments on, but it isn't actually a question, but just to make sure I understood, yeah, you can have groups that you can assign roles, you can assign those a role to a group on a project or a domain, but I think the point you're getting to is this idea of the fact that, and Adam just alluded to it, the fact that right now the model is, Keystone is not the, well, OpenStack doesn't provide the system for distributing those policy files around and management, it's just outside of the scope of any of the OpenStack tools, you might use that or what do you need to choose? And we have debated at length where the Keystone should take on a role there and be able to provide a collective view and so forth. We actually got- They didn't have my security enhanced OpenStack. We've got one of the- It's also the same sort of thing. You mentioned, look at a token to see what that user can do. I as an admin want to look at a user, not that user's token. I say, what can they do? And see what they can do. So I don't even have their token to know what their permissions are. And so right now in Keystone, as I understand it, it's supposed to somewhat manage access but not- The steps that you have to go to get to, okay, we don't even have an agreement from the services that we're gonna collectively use the policy API in Keystone to manage the policy files. The policy API probably predates most people in this room's involvement with OpenStack and it's still not used. We're trying to get there. If we could get that far, then at least I could give you the steps to do that. Until I know what policy file is going- Well, we're having a lot of discussions. I actually came from, and I'm going to policy discussions across the street in the developer side of things where we're knocking down the pins one at a time or knocking whatever the wall's the better. There's a lot of steps to get there. And remember, we have a lot of people that are using it now. I'm not allowed to break things as much as I'd like to do it. I really do. Raise the RAZE, the existing, but we can't. So the advice I'd say is keep saying what you're saying because I do understand where you're coming from. Keep telling, repeat this to the Nova guys and the Cinder guys and the guys. Because in order to do that, we need a collective cross-project agreement of how those policy files either distributed or could be accessed and so forth so that we can give those answers. So something can give you that answer, which, because if it knows the policy files and keeps in rules, then we could give you the answer. That's what we have here on this slide, right? The question's- That's exactly what we're trying to get to. And yeah, I know that there's people who want things on individual resources. Sorry. Yeah, so basically- Oh, you again, man. Yeah. I asked this question before in another session and you told me, you know, this is the- Yeah, come to the session. Yeah, so basically, so the question is, we do have this role-based API allows us to dynamically create a role. But the role, if you want to give the permission, you'll have to go to another place, which is the policy file, to give them the permission. And after that, you'll have to restart the server. Basically means you don't have the capability to dynamically assign you there. No, well, it's not true. I try to restart the server, actually. You have to restart the server. You have to restart the server, but yes, you're right. Go review my talk from last, a year ago, the summer there, and you'll see dynamic policy. That's everything I wanted. It's- I mean, okay, and I agree. We don't have the ability to change it dynamically and to have it effectively because those policy files, again, are distributed outside of the scope of Keystone and Keystone doesn't know where they are and we need a, you know, again, I say to all of you, if this is what you really want as deployers, I'm gonna, you know, keep telling not just Keystone, but some of the other projects, we can help carry your message, and we will, it just comes, we'll wait if you say it and if I say it. I'm also being a little flippant here, but if you see that note, that second one there, we got feedback from the operators that they did not want us rewriting the content management system. They wanted to, they had, whether it's Puppet or something else, Ansible, in place, they did not want us replacing that with a custom operation, or operator for this. So there's a lot of people with a lot of different views on this and we have to keep the different viewpoints in mind there. Being able to put policy into Keystone that is then used to control access to Keystone is also problematic for other reasons. So. Is someone waiting to set up for the next session? Yeah, I mean, how am I gonna stand on this? People are gonna come and chat to us directly and then we'll answer questions. You're gonna have to sprint across the street. Okay, I'm gonna go to that corner and you can come and answer me questions directly. You'll get better answers anyway. Thank you.