The road to zero-trust: rethinking identity for a rewritten OpenStack Keystone

Keystone has always been the trust anchor of an OpenStack deployment — but „trust“ in the classical Keystone architecture often leans heavily on network topology: services inside the perimeter are assumed safe, tokens are validated locally, and a compromised node quietly inherits more authority than it should.

Rebuilding Keystone from scratch in Rust (keystone-rs) forced us to confront that assumption directly. This talk walks through what „zero-trust“ actually means once you stop treating the network as a trust boundary: how service-to-service authentication has to change, what a management API and CLI need to enforce instead of assume, and where a distributed, Raft-based identity backend makes some zero-trust properties easier — and others harder — to achieve.

Rather than a cryptography deep-dive, this is a talk about architectural decisions: which assumptions had to go, what replaced them, what it cost us in complexity, and what we’d tell another project attempting the same rebuild. Expect concrete lessons from an active rewrite, not a whitepaper — including a few places where „proper“ zero-trust ran into the practical limits of an internal-only, sub-100-node cluster.

Target audience: Operators and engineers working on OpenStack or open infrastructure generally — no security specialization assumed.

Key takeaways:

• Why network-perimeter trust quietly leaks into identity architecture, and how to spot it
• Concrete design changes a zero-trust rewrite demands (service auth, management-plane access control)
• Honest tradeoffs: where zero-trust principles met real constraints