 All right. Hi, everyone. Thanks for attending this session. My name is Colleen. I'm the Keystone PTL, and this talk is going to be about a new feature we introduced in Keystone this cycle that's going to help give users a new way of delegating access control for application credentials in Keystone. So to explain why we needed this feature in Keystone, I first want to discuss a little bit about the traditional way we have of doing access control in Keystone. We use a kind of role-based access control where users assigned a role, but they're also assigned a target where that role applies. So we say, for example, the user has assigned the member role on Project Foo. And we call this scoped RBAC. It's kind of a unique way of doing authorization in Keystone. And the only way for a user to get a role assignment is for them to go and ask their cloud administrator to make that role assignment for them. And the meaning of a role isn't an inherent property of the role itself. Actually, we have to define the meaning of the role in config files and policy files that are distributed for every service in OpenStack. So just for example, if you created a role named Reader or if you have a role named Reader that's available in a Bootstrap Keystone, it doesn't automatically mean that a user can only do read operations in the deployment. Actually, the operator needs to go and make that configuration in all of their policy files. And so that's a little bit difficult to do. And it doesn't really fulfill our goal of being self-service, because if the user needs that permission, they need to go and ask the cloud administrator to give them a new role. And if there isn't an existing role that does what they need without giving too much access, then the operator needs to go and edit a whole bunch of config files in order to achieve that sufficiently least privileged role definition. And so application credentials are a feature we introduced in the Queen's Cycle that brought users a little bit closer to that self-service user experience, at least for authorization delegation. So before application credentials, if you were creating an application, creating some kind of automation that was going to run on top of OpenStack, you would have to give your users' own credentials to the application, either embed it in a config file or hard code it in the application somehow. And that means that the application has full access to do whatever your user can do in OpenStack. And in the worst case scenario, maybe that's even like an LDAP password. So a rogue application could have access to do anything in your organization if it had that password. So application credentials were created in order to allow users to delegate just a subset of their access to an application. And the biggest one with that is, of course, you don't have to any longer embed your own password in the application. You only share the application credential secret. And that can be revoked at any time. That can be rotated out. So you don't have to change the user's password in order to deal with a security issue. The second win is that application credentials, they only have access to a single project at a time. So you're already limiting the breadth of this application's privilege. If a user has access to a whole bunch of projects, the application credential can only access one project. And finally, at least in the first iteration of this application credentials feature, the user can delegate a subset of their role assignments to this application credentials. So for example, if the user has a member role and a reader role on a particular project, maybe this application is just a monitoring type of application. It only needs the reader role. So the user could delegate just that role to their application. But so that interface is kind of clunky because that still doesn't allow users to have that kind of fine-green control over their applications and allow them to do specific, just explicit, whitelist actions of what they wanted to do. And the user still needs to also go to their cloud administrator and ask for a new role assignment if they don't already have a role that meets the needs of what they want their application to do. So this is why we introduced access rules to application credentials. This is supposed to help with this problem by creating this as a new attribute of application credentials. So these only apply to application credentials. They don't apply to trusts. And they don't apply to regular user permissions. Those still just use regular policy rules. And it's a completely separate layer from policy. So all policy rules still apply. And they're still enforced by the service. But access rules are enforced by Keystone Middleware. And so since users are creating these application credentials themselves, they have full control over these access rules. And they don't need to know anything about policy rules. They don't need to change any policy rules. But they are not able to create an application credential that could do more than what their own role assignments allow that user to do because we're still backed by policy rules too. So an example of how you might use this new feature is here. So opposing, the user has a regular role on a regular project. But they're creating an application that's maybe like an auto-scaler application. And this thing only needs to create servers and only needs to delete servers. So the user, instead of going to their cloud administrator and creating a new role that only does these two operations, they can create an application credential that has these two access rules. And so when the application goes and tries to use this application credential on the compute service, the Keystone Middleware will check that the request matches what the rules allow them to do. And then the request is then passed on to the Nova Service. And the policy engine also enforces the role assignments that the application credential has. You can notice the syntax here. We use this bracketing wildcard syntax. And that kind of matches what the path will look like in the API reference. So this will mean that you don't have to know the server ID ahead of time in order to create this rule. You can have this sort of wildcard instance here. And another way of writing that is with a wildcard glob expression that also means the same thing. That means we don't have to know the server ID ahead of time. This application credential could delete any server with any ID. We also have this recursive wildcard glob syntax, which is even more permissive. So instead of just this application credential, for instance, could do pretty much any post or any delete operation on the compute service. And then something worth noting is that once an application or once an access rule is created, the access rule becomes independent from the application credential. So you can reuse old rules if you want by using their IDs instead of going and looking up the API reference every time you want to create or every time you want to rotate your application credentials. You can create, you can use this ID and re-assign old access rules to them. There's a couple of caveats with this feature. So access rules are only enforced on the external entry point. And this is something we went back and forth on a little bit while we were designing this. But the idea is that the user only has to know the external entry point. So for example, if they're creating an application that needs to interact with Nova, they only need to write in the Nova access rules. They don't need to know specifically that Nova on the back end needs to call it to Neutron, to Glance, to Cinder. That all happens implicitly. The end user doesn't have to know about that. Those are all still enforced by regular policy rules. And then the other thing is that there's no kind of pre-validation of these path strings. Once the user creates it in Keystone, it's freeform created in Keystone. And it's not until the application actually tries to use it against a service that it actually touches that service. So we're expecting users to look at the API endpoints in their services API reference. They're allowed to use permissive things like the double star syntax to create really permissive rules. So it's possible that a user can create an application credential that has access rules beyond what they intended to do. But again, since these are still backed by policy rules and by regular RBAC, they can't create an application credential that does more than what their own user is allowed to do. So where we'd like to take this next is, first of all, client support is on its way. We have reviews up for OpenStack Client and for Horizon. The examples that I showed for the OpenStack Client, those are still under review. So it's possible the syntax might change slightly between now and when we actually get that merged. But it's coming. Another thing we're thinking about is microversion support. For example, perhaps the behavior of an API changes between microversions. Maybe you want to pin to a particular microversion. That's something that we want to consider. We're not really sure how that would work. And we want to talk to other services that actually use microversions to talk about whether that's really a good idea. And then the other thing is that when we originally conceived of this idea, we had some ideas about making this a little bit more automated. Instead of asking people to go look things up in the API reference, maybe we could validate this against the actual services somehow or pre-generated against the actual service somehow. But there's not really any kind of mechanism in OpenStack to do that kind of API discovery yet. So that was a little bit too far out of reach for us to implement it for this feature. And similarly, we also had this idea of maybe we could couple this a little bit more with role definitions and maybe move policy more in this direction, more in the middleware direction, rather than the way we have been enforcing policy at the service layer. Again, that was a little bit too big of a hump to cross while we were implementing this feature. So we wanted to get this done and make it useful as soon as possible. But that's something that's on our minds for the future. I don't have any time for questions, but you can reach us on IRC or on the OpenStack Discuss mailing list. You can also contact me directly. And I'll be here for a couple more minutes if anyone wants to come ask me questions after this talk. Thank you so much for your attention.