The challenge
Secrets — credentials, keys, tokens — are the most sensitive configuration in any system. Two things have made the incumbent approach a sovereignty problem:
- Relicensing. HashiCorp moved Vault to the Business Source Licence, turning a de-facto-standard open tool into a source-available product under a single vendor’s control (and prompting the OpenBao fork).
- Foreign-controlled vaults. A managed or foreign-jurisdiction secret store means the most sensitive material in your estate sits under someone else’s control plane.
For regulated and defense environments, “our secrets live in a vault we don’t control” is not an acceptable answer.
How we help
The platform provides self-hosted, Kubernetes-native secrets management built on open source:
- OpenBao as the open-source, self-hostable secrets engine (no BSL, no vendor lock).
- External Secrets Operator to deliver and rotate secrets into workloads through native Kubernetes mechanisms — without rewriting applications.
Because it is open and self-hosted, there is no foreign vault dependency and nothing you are renting from a jurisdiction you do not control.
Zero-trust, not perimeter trust
Secrets management is the foundation of a zero-trust posture: short-lived credentials, least privilege, and automated rotation so a leaked secret has a short useful life. The patterns are designed to map onto BSI IT-Grundschutz controls.
Alignment, stated honestly. "Designed to map onto Grundschutz controls" is an architectural property, not a certification. We describe alignment where it holds and never imply an audited status we do not have.
Outcomes
- The most sensitive material in your estate lives in a store you control.
- Rotation is automated, without an application-rewrite project.
- A zero-trust foundation aligned to the controls your auditors expect.
- No foreign vault dependency — sovereign by definition.