 Okay, awesome. So this is the quickest presentation. My apologies for being lots of words on it. I did put a diagram. I feel bad that there are not two diagrams. But hopefully this conveys the important details and gets everyone kind of on the same page. So this is a quickish overview, but it has a lot of detail. So I guess the first slide whenever you talk about the RBAC, you kind of have to explain what it is. In essence, you're taking activities of humans, mapping them into roles that relate to the job responsibilities, and then in order to grant access to these tasks or items or things they need to do, you group these humans back into the roles. So in essence, these tasks might be like administering machines, or generating reports from, say, ironic. So I think it's kind of important to note that we did have early support in ironic from the beginning. We had something called bare metal admin. And we also had bare metal which kind of served the same purpose, except these were based on the use of a bare metal project and the default rule structure in the policies, which by default, ironic honors a legacy admin project in OpenStack, which is kind of bad. It's hard to write rules for. Most people just write is admin. If the rules match properly or not, it's bad, depending on how you approach the problem. And the conundrum of is admin specifically is if you have an admin of any tenant, they match is admin. So you have to be very particular about your rules and how you approach them. And yes, that was the core key. I'm going to call. So anyway, you can kind of get where why the legacy support was kind of a bad way of approaching things, or at least in OpenStack in general. But really for us, it hasn't that mattered that much. We've encouraged people to use a bare metal project. Ironic has taken an admin-only approach, except we've kind of been drifting away from admin-only. We've been drifting towards providing the ability for more settings to be enabled, more user flexibility. And when you kind of look at the entire picture, it's good to start understanding why it was necessarily community to kind of go, oh, we should probably retool a lot of this, which is the secure back solution. And as I just mentioned, this was a larger community effort. I believe some like 13 projects ended up merging code to support secure outbreak model. And this comes from the solution Keystone came up that solves this problem, which is where you end up with a scope and you scope these activities. And three scopes exist in this model, a system scope, a domain scope, and a project scope. Project scope is basically what we've always had in OpenStack. System scope is relatively new. It's intended for the system itself or those administering the system. In other words, it's like your global admin or your legacy admin tenant. You have elevated rights in theory, and you should be able to see or do anything or view everything and do reporting or whatever is necessary. And so the Wallaby Release of Ironic has support for system project scopes. This has been a lot of work. And I want to thank everyone who has reviewed the code. It's been a huge effort. But in order to kind of talk about our support, it's also necessary to kind of talk about our roles. And the Keystone model roles is a little different than what we had, where we had bare middle admin, bare middle observer, and you explicitly grant access. In the secure back model, you have an admin, member, and a reader. And if you think about it, it's kind of like your creator, deleter, or the admin. They can create items. They can delete items, globally at least. Members have certain other abilities to change, update, but they also have other rights enabled as they're able to read. Everyone can read because admin cascades to member, member cascades to reader. So this discussion always tends to get into what if I wanted to see the secrets. And there has been discussion of an auditor role. There's not consensus behind the auditor role. If the community comes with, comes to consensus, I'll gladly implement the auditor role in ironic. And it's still possible to do with legacy policy roles. It's just it's until there is consensus on how it's approached, then it can, is a mistake for us to implement it. So ultimately, the kind of the practical result of our back in ironic, what was bare middle admin become system scoped admin? Was bare middle observer become system scoped reader? We now have a shiny, brand new member role, which allows operators to build to basically do maintenance tasks. You don't want someone to necessarily be able to lead a machine, but now like second level support to be able to do break fix or possible redeployment. That's what the member role is specifically for. But it's also kind of important to note that we're in a migration period as a result of all this work. Operators ultimately do need to move away from bare middle admin, bare middle observer. The policy evaluation for all this policy logic gets applied to both the deprecator roles and the new roles. And in this case, luckily, custom policy still wins. So if you have a custom policy overrides it. At this time, warning messages and logs are extremely problematic. I've got a commitment from Oslo policy to get a fix in for that. Because right now it's very noisy. Extremely noisy. It's not operator friendly, unfortunately, that should be fixed soon. Oh, also there are also policy settings to skip legacy and enforce scope validation of the users. Basically setting these two settings forces everything over into the new logic. It disables the legacy deprecate role logic, which allows for much more secure installation and use of ironic. So, yeah. But there's always more. Ironic started heading a little bit of a different direction in the rest of the community with owners and lesssays. And the whole idea is bare middle physical asset. You have to be able to have some sort of ownership of it. And you have to be able to somehow go, I want to provide it or lend it over to these people over here. So the net effect of all of this work is that some API endpoints are strictly enforced to system only. Some can be used by policy or by projects or project scoped users. Policy permitting. The default policy does allow random cat. The default policy does allow for some endpoints to be usable. Some endpoints are not useful. Like things that would be purely admin only like conductor listings or chassis. Those are all admin only system scoped. You basically need to be an admin to do anything on them. Again, as I said before, the custom policy still wins. It overrides the policy and code logic. And ultimately, project scoped user can perform a subset of the activities in the API. So it's important to kind of talk about how the logic gets validated. The policy flows essentially is the request system scoped. If, yes, the access is validated based upon role, there's no additional database lookups. It's clean. It's efficient. It's easy. If it's not system scoped, the project ID is matched. It basically goes to a is less say or owner matched, which means additional database lookups in certain cases or database joins. And if that doesn't match, then the logic falls back all the way to the deprecated role until they're disabled. If they do match, then user is able to access the resources based upon the node relationship with the granted rights of either owner or less say. And they're not the same. I can't think of a good example off the top of my head, but essentially, less say is far more restricted than what they can do. They're not the administrative machine. They're a user, whereas the owner is intended to be more of an administrative level of access to the machine, namely because in this model, they own the machine. They probably control the machine. It's in their racks, their cables, everything. So that's kind of the model for this built round. And access is ungranted based upon that. So I kind of noted some some downsides. The additional database access is based upon the ability, the need to understand if there's a less say or owner associate with something. We've done most of this with joins, which is as efficient as we can make it until we have those columns indexed. We'll be doing some database optimization work in the upcoming cycle to improve the fact that these database interactions make it more efficient and faster. And I highly encourage larger operators not to immediately upgrade, namely because we don't have a solid understanding of exactly how some of these joins are going to interact until we have these indexes in place. One other thing to note is allocations are available. Anyone at the user of a system can request an allocation, but their project ID still has to match. It still goes into database join. If they don't match, they're not able to get they're not able to match a machine or machine doesn't exist. That's assigned to their project. Then it's basically useless. The allocation will fail. Basically the same rules apply, machine has to exist. Important thing is where can you learn more? We've got a documentation or documentation that's been posted. It includes links to the specification. It also includes links to supporting keystone documentation, trying to provide more clarity. I'm here to answer questions if there are any. So are there any questions? Thank you very much, Julia. Are there any questions for Julia? Hopefully people aren't like going, oh no, and running away, but it's a really positive change. I'm really happy that we got it through and we're able to do it. It really opens the horizon for, oh, there's a project name horizon. It will further enable us as we go down the path of additional integrations and additional logic. While this is all built around Keystone, I could see someone building a plugin to basically go here at the associations and here's membership and go from there. That's not something we have today because someone wants to put a work in. Right. I start with questions then if no one else wants. You already preempted one of my questions. I'm very worried about scale and what happens if you have hundreds or even thousands of nodes as we have. So when you say you recommend to Wade with the upgrade, you're talking about the upgrade to Wallaby. If there's optimizations that's being backpotted, you expect these optimizations to be in the code only and not affecting the database in any way? I expect them to be database impacting in terms of adding columns. I don't expect them to be required. I expect what we'll do is we'll look at the various aspects and we'll probably go ahead and merge schema changes on back ports that are optional that are just add column indexes basically. That's how I'm foreseeing it. That way the database will still work. The operator can make the decision of when they want to build an index. Luckily, there's not that much data to index, but it will still help once those columns are there and they should be more responsive. For a larger operator like yourself, you'll want to probably go ahead and set Nova to run system scope out of the gate. That's probably the biggest change and if you do that, you won't see any of the performance impacts, but if you have any other project scope users that are trying to use the API, whether legitimately or not legitimately, that's going to start incurring additional database lookups and logic. So it's really important to try and move to system scope because we only fall back to trying to retrieve that if it's not system scope. What about Keystone? What about the additional impact on Keystone? So it's interesting to bring that up because the way that it works is when you authenticate to Keystone. It tells your browser, here are your roles, here's your data, except that's not what is actually used to populate the data that gets passed into the context in the API. Essentially, your request goes to Ironic. Ironic then issues a request to Keystone Middleware. Keystone Middleware validates against Keystone itself independently to populate what the roles and memberships and scope as an override. So basically, in some cases, yes, you can say here's my level of access. That's only if Keystone Middleware is not running. Keystone Middleware will reset those values from what's in Keystone and that's a memcached lookup or an API lookup and then memcached the access. Right. But the load on Keystone will nonetheless increase, right? It should be the same. Okay. Because every request that gets issued will either, will hit Keystone Middleware, it was hitting Keystone Middleware. Okay, fair enough. So yeah, same exact path. It just, we have some additional logic in Ironic now to support those cases. Okay. I have more questions. No one else. Okay. So as an operator, you know, you said like, operators should move to the new, or migrate to the new model, right? They should deprecate their old Ben Metal Observer, Ben Metal Admin. If they don't, what is going to happen? Because I guess that like most operators won't, sorry, most operators won't follow it that closely and they would just like upgrade and then what is going to happen if operators are not aware and just continue to upgrade? I mean, like not necessarily large operators that will see like database declaration, but also smaller operators. Will the access change somehow or will that break or you mute it? Yeah. So the queries should still end up being joined at that point. If they're not using the fields, then I suspect the queries should return about the same amount of time. But naturally we'll eventually want indexes on those queries, especially the much larger deployments that are out there. Now I was just wondering if operators will learn at the halfway the moment they upgrade that, I mean, they should test of course and see this in their QA environment. I was just wondering if then at some point it just stops until like your request cannot be satisfied because you're using something that has been duplicated doesn't work anymore, so you're not authorized to get next to it. We didn't remove the legacy rule, legacy policy and code rules. We'll probably remove them. Well, it might be this cycle, might be next. There's a push within the community to go ahead and get the legacy rule structure ripped out completely out of Oslo policy. So it would be hoove operators to go ahead make those transitions and upgrades, but if they're also using custom policy file, they don't have to change the way they're doing things today. It's just we'll end up having some join queries on database. Right. The auditor discussion that you mentioned, that's a community-wide discussion? We had an ironic. It came back up in the larger community I guess about four months ago. Basically, there's disagreements over the level of access that should be had by an auditor. My view is basically it should just be a read-only user that has the ability or has the appropriate setting set so that secrets are unmasked. Although there's also other people that say it should just be a read-only user and there should not be beyond masking secrets. I can see it from both points of view. The real conundrum is what people want auditor for is actually security compliance, reporting and auditing, not necessarily accounting. Right. Yeah, that's different. So there's like requests from the community for this auditor role? There are requests in the community. There is some discussion that happens every few months. I know there's been discussion in keystone-centric keystone-side community for some time, but largely it's kind of the same conundrum that we have. How are people really using this? And they could still define it with a custom policy file today if they wanted to. Yeah. Okay. Thanks. Thank you everyone.