Hey, Sorry for being late. Here comes the summary from Keystone team discussions during the PTG # python-keystoneclient deprecation Following what other services are doing python-keystoneclient is going to be deprecated as a standalone entity. Work in OSC is currently underway to complete the switch to using OpenStackSDK. We want to deprecate python-keystoneclient (another codebase being duplicated) but we also see many services relying on it. We will evaluate the possibilities we have here. # Switch to the DPL model We were discussing whether it makes sense for the Keystone team to switch to the DPL model, but decided to stick to the PTL model while still formally sharing responsibilities among the team members. # External OAuth2.0 Greg gave an update of the current state of the work. We discussed some corner cases as well as tried to figure out which cases (so to say deployment types) it is suitable for and which not. At the moment this approach is suitable mostly to only certain cases # Launchpad maintenance We discussed (and performed) cleanup of the launchpad teams and removed people that are not active anymore (thanks to them for doing that before) # Service accounts Certain future use cases were discussed where introduction of the "service account" concept may be useful (similarly to what they are in K8). I am continuing prototyping on that in my federation rework and will present results once something reasonable is achieved. Major use case for service accounts may be: - workload authentication (like GitHub action, GitLab CI, etc) where a certain workload should be able to authenticate with Keystone without hardcoding a regular "user" account with the password or application credentials - something similar to the AWS STS, or better to say possibility for OpenStack services (in this example Nova) to request a token for the "service account" that can be provisioned into the VM to allow workload inside the VM to auth into the cloud # Reimplementing Keystone in Rust (with Federation rework and advanced auth based on security keys/passkeys/yubikey) I provided an update of the state of reimplementation of Keystone in Rust with the numbers describing performance improvements (10x-100x depending on the use case). Demo for the yubikey auth was given some time ago separately. We discussed how is it possible to consider Keystone following a microservices approach and for the CSPs to deploy Rust reimpl in parallel to the python keystone to start using reworked federation as well as advanced auth flows (auth with the security key) # Ephemeral credentials This discussion was tightly coupled with the previous discussions on OAuth2, service accounts and federation rework. Sadly we are currently not able to implement something similar to the AWS STS with assigning limited scope tokens before we address other issues and introduce service accounts and further explore alternative policy enforcement approaches # OpenPolicyAgent (as an extension over the oslo.policy) Back in 2018 an idea of adding support for OpenPolicyAgent into the oslo.policy was presented. This time we are much further. There is an oslo.policy plugin, converter of policies from the code to the OpenPolicyAgent (rego) language together with automatic tests generation (as well as hacks for Neutron). There is now even the first CSP rolling it out in production. This step allows CSP better integration of OpenStack with other offerings (K8, Ceph, etc) while offering huge flexibility and fine-granular access control desperately desired by CSPs and full authz audit log. Thanks to all participants. Hope to see you during our regular meetings. Keep on doing your great work :-) Regards, Artem