Hi, I want to thank all the contributors to this discussion. As a reminder, what Artem currently brings with keystone-ng extensions is: * OIDC with self-service and CLI integration * Workload federation (Zuul, GitHub, Gitlab do not need to have secrets to access OpenStack anymore) * Service accounts (many use cases, one of the prominent ones: OpenStack on Kubernetes, GitHub workflow) * Passkeys (webauthn) * SCIM * Tight Open Policy Agent integration. The OpenInfra sessions were full of people interested to hear about these features. The question is how to get these features in the hands of openstack operators. We have three options: * Either embrace the codebase Artem developed (with all the rust learning, new codebase understanding, CI dependencies…) * Consider re-developing those features in python * Do nothing Keystone maintainers are few, if we go with option “python”, will anyone step forward to help with the new feature development? Because we know who’s working in keystone, and it has not been growing in the last few years. If we go the “rust” route, we get a working PoC but incomplete codebase, which might attract new contributors. If the current approach is not working, maybe the approach has to change. There is a demand for the modern features Artem developed. Either we can provide them in OpenStack, or maybe the solution will happen outside of OpenStack (e.g., k8s+kubevirt). The main risk is to achieve very little modernization in keystone due to lack of capacity. We can argue about language, CI, splitting the community (all good arguments). At the end of the day, what is the path of least resistance to modernize keystone & get new contributors to this modernization effort? I find the keystone-ng experiment interesting, I hope it gets considered & interested maintainers will show up in the next 2-3 months mentioned in the initial email. Artem, I salute your determination in challenging the status-quo. Best regards, JP (Speaking in my own name and on my own behalf) On 7 Nov 2025, at 12:17, René Ribaud wrote:
Hi,
Thank you very much for sharing this detailed update. That was a very interesting and inspiring read.
I’m probably a bit biased since I’m a big fan of Rust myself, but I truly appreciate how much it can help us build safer and more performant software. The direction you’re taking feels ambitious and forward-looking.
Unfortunately, I couldn’t attend your session at the OpenInfra Summit in October, but I’ll make sure to watch the replay soon. From what I read here, the work and vision behind this initiative are really impressive, and I’d like to express my full support for the effort.
I also realize that introducing a new language like Rust into the OpenStack ecosystem won’t be easy and will likely take time, both from a technical and a governance perspective. But it’s a fascinating step forward, and I think it’s also an interesting opportunity to see whether this approach can attract new contributors or a broader group of people willing to help sustain the project.
I don’t know what the Foundation or the Technical Committee’s current position is on Rust within OpenStack, but personally, I believe this kind of project should be encouraged under an *experimental* or *incubation* status. It’s exactly the kind of innovation that can keep the ecosystem vibrant and evolving.
Congrats again for pushing such an ambitious and technically exciting direction.
Best regards, René
Le jeu. 6 nov. 2025 à 16:27, Artem Goncharov <artem.goncharov@gmail.com> a écrit :
Hey guys
Let us give you an update of the OpenStack Keystone future following the great PTG week we just had.
Some news has already spread across the community, causing excitement and anxiety. It is not uncommon that changes cause fear. Some time ago, in the age of the Inquisition, people were even burned because of fear, misunderstanding, or questioning the rules. Let us clarify things.
Nearly 13 years ago, the Identity v3 API was introduced. Since then, the world has changed dramatically. Libraries we use got abandoned, standards went legacy and replaced with new ones, ecosystem components, certain functionality is based upon are being sunsetted by OS vendors (mod_auth_mellon is archived upstream and gone in CentOS and RHEL [6]), new security vulnerabilities (classes of vulnerabilities) appear like mushrooms without us being able to address them.
Cloud providers today face new challenges that were not present 10-15 years ago. Nowadays, a public cloud requires proper federation support with complete self-service. Users request passkey support, and security departments require additional hardening. These things cannot be covered in today's Keystone architecture and API version. As a result, work on an optional extension to Keystone [1] began some time ago, allowing CSPs to deploy it in parallel with the Python Keystone (of any v3 version) and access the new features.
To simplify parallel deployment, it has been decided to start introducing v4 with the new features (since those ARE for cloud end-users). The work was done in Rust due to multiple factors: lack of necessary python libraries with trustable maintenance and/or licensing, necessity for enforcing security standards and practices using memory safe programming language, demand to address python ecosystem madness of past years (I guess majority would agree, that in the past few years we were mostly only chasing the python ecosystem breaking us on setuptools, eventlet, passlib, …).
During the work, it became clear that implementing the mentioned features requires support of a given percentage of the existing functionality: users, groups, projects, roles, and tokens. And so it was implemented. A side effect of it became immediately visible: performance. Token check is THE most frequently called API in the OpenStack cloud. Right now, caching is used to reduce system stress. But in Rust, token decryption, without caching, is much faster than in python with caching (we expect a 2-3x faster order of magnitude).
As mentioned above, new vulnerability classes and attack vectors require us to disable caching, making such an improvement highly valuable. The new stack is fully async, uses parallel DB queries, and runs background tasks for periodic cleanups, synchronization, and similar. This allows us to achieve significant performance and maintainability improvements, eliminate the old ballast, and significantly reduce transitive dependency version conflicts.
Current measurements also indicate that we would likely be able to eliminate the need for caching in Keystone. For python, on the other hand, we do not have much to start with and would need to find and migrate to the new web framework, find maintained libraries with suitable licenses, and implement new features. We also need to rework the DB access patterns due to the number of bugs and the performance penalty caused by suboptimal DB access (many rows are selected multiple times during processing of a single request). With new authentication flows, we would need to do a wide security assessment of Keystone from scratch anyway.
With that work in mind and facing the prospect of having a major rework in python Keystone anyway (due to the abandoned complex dependencies), we, as the Keystone team, decided to try to focus the work on the Rust implementation, making it a proper evolution of the python Keystone and building a necessary community around it. This adoption is conditional on adding new contributors to support the project.
We believe this approach allows the best of both worlds: the trusted maturity of Keystone’s Python code-base, combined with the modern, high-safety, high-performance capabilities of Rust where they matter most.
Logically, this raises questions, so let's try to answer some of them:
1. Rust is not officially allowed in OpenStack. How are you dealing with that - The development is now going on on GitHub outside of OpenStack governance. - We would apply for OpenStack universe inclusion. - Once the TC policy allows Rust or the overall project inclusion requirement is reworked, the project will work toward becoming the official OpenStack project. - No one in the team is willing to separate from OpenStack, but with the current policies, we have no other way. Everybody and everything in the OpenStack ecosystem would benefit from that project being official to have first-class native support of the new functionality. - Multiple CSPs expressed support for such a move, desiring to see Rust in the ecosystem for better performance, maintainability, and resource utilization - A nice coincidence is a freshly sent announcement from Debian that introduces a strong rust dependency in the packaging tooling, stating something similar to: either you work to comply with this requirement in the next 6 months or sunset the port [5]. - Rust allows cross-integration with python with a high number of cryptography and typing libraries for python written directly in Rust. We are going to be able to reuse certain pieces of python in Rust during porting and Rust in python later in the future. - Keystone is a very sensitive component and in our eyes that fully justifies use of rust to provide a much stronger security on the language level.
2. Do you deprecate python Keystone. - No - v3 is there, and we continue maintaining it - We would unlikely accept major changes - Keystonemiddleware, keystoneauth, etc, are still there. They would likely be adopted for v4 support at some point in the future (in OpenStack services, we already communicate with “external” software, so there should be no problem). Those libraries are crucial for other services and thus are there to stay while necessary. - At some point, we will no longer be able to keep it alive when abandoned dependencies are physically gone. We are not going to invest our time in maintaining the abandoned software; we do not have enough time to do so.
3. What is the community around it? - As of now, there are provisional commitments from a few vendors and CSPs to collaborate on it. - Existing software is being transferred under the openstack-experimental organization to help build the community [3]. -The initial author (gtema) personally commits to continue working on that independently of others.
4. What are the /v3 features that would go away? - OIDC federation in its current form. v4 reimplements it from scratch natively without depending on external software (mod_auth_oidc, etc) since those make self-service impossible. - Saml2, this is a legacy protocol that is very unlikely to even get fixes for security vulnerabilities, and looks to be PQC unsafe. - Oauth1.
5. What new features are there in v4? - OIDC with self-service and CLI integration - Workload federation (Zuul, GitHub, Gitlab do not need to have secrets to access OpenStack anymore) - Service accounts (many use cases, one of the prominent ones: OpenStack on Kubernetes, GitHub workflow) - Passkeys (webauthn) - SCIM - Tight Open Policy Agent integration. We plan to consider the reintroduction of central policy storage in Keystone (not enforcing, but for central storage)[4]
We will use the next 2-3 months to gather interest in contributing to this approach and the new Rust-based code. There was a lot of interest in the new features listed right above during gtema’s sessions in OpenInfra Summit in October 2025. Still, it has to translate into active contributors for this effort to take off. If you have an interest in those new features, join us!
We hope this clarifies the situation. Feel free to reach out with other questions.
Thanks to everybody who participated in the discussions.
Regards, Keystone team
[1] https://github.com/gtema/keystone [2] https://www.youtube.com/watch?v=XOHYqE2HRw4&list=PLKqaoAnDyfgr91wN_12nwY321504Ctw1s&index=30 [3] https://github.com/openstack-experimental/keystone [4] https://www.youtube.com/watch?v=_B4Zsd8RG88&list=PLKqaoAnDyfgr91wN_12nwY321504Ctw1s&index=33 [5] https://lists.debian.org/debian-devel/2025/10/msg00285.html [6] https://access.redhat.com/solutions/2743391