Sovereignty isn't just about where your data lives — it's about who and what you actually trust to access it, and why. Classical Keystone architecture leans heavily on network topology for that trust: services inside the perimeter are assumed safe, and a single compromised node can quietly inherit more authority than it should. For infrastructure you claim to fully control, that's a gap worth closing.

Rebuilding Keystone from scratch in Rust (keystone-rs) forced us to confront this directly. This talk covers what "zero-trust" means in practice for a sovereign OpenStack deployment: how service-to-service authentication has to change once the network perimeter stops being a trust boundary, what a management API and CLI need to enforce rather than assume, and where a distributed, Raft-based identity backend makes zero-trust properties easier — or harder — to deliver.

This isn't a cryptography deep-dive. It's a talk about the architectural decisions a sovereignty-focused rewrite demands: which assumptions had to go, what replaced them, and what it costs in complexity to actually own your trust boundaries instead of relying on your network perimeter. Expect honest, concrete lessons from an active rewrite — including where "proper" zero-trust ran into real operational constraints.

Key takeaways:

Why "sovereign infrastructure" implies more than data residency — it implies owning your trust model
Concrete architectural changes a zero-trust identity rewrite forces (service auth, management-plane access control)
Where zero-trust principles met practical limits, and what we traded off