Kubernetes Secrets and EU Sovereignty: ESO Meets OVHcloud Secret Manager

Kubernetes Secrets are base64-encoded. Not encrypted. Base64. The encoding your browser uses for inline images. Anyone with kubectl get secret -o yaml and a terminal can decode every credential in your cluster in about two seconds.

This is fine for development. For a regulated EU financial services workload, it’s the kind of architectural decision that makes compliance officers reach for their blood pressure medication.

The standard fix is an external secrets manager: store credentials outside the cluster, sync them in at runtime, rotate them on a schedule. AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, HashiCorp Vault. All mature. All well-documented. All subject to US jurisdiction via the CLOUD Act, which gives US law enforcement the legal authority to compel American companies to hand over data stored anywhere, including your eu-west-1 secrets.

For teams operating under DORA (the Digital Operational Resilience Act, the EU’s operational resilience framework for financial entities), that jurisdictional exposure isn’t a theoretical risk. The DORA regulatory technical standards (Commission Delegated Regulation 2024/1774, Articles 6 and 7) require financial entities to manage cryptographic keys through their entire lifecycle, and third-party ICT risk must be baked into the risk management framework. Your secrets manager isn’t just tooling. It’s a compliance surface.

OVHcloud, a French cloud provider headquartered in Roubaix and incorporated under French law (OVH Groupe SA, RCS de Lille), launched its Secret Manager in beta in November 2025 and moved it to General Availability on January 15, 2026. It’s built on OVHcloud’s own KMS (Key Management Service), stores secrets in French datacenters, and exposes a Vault KV2-compatible API. That last detail matters: it means the External Secrets Operator (ESO), the CNCF Sandbox project that has become the de facto standard for syncing external secrets into Kubernetes, works with OVHcloud out of the box. No custom provider needed.

OVHcloud isn’t the first EU-sovereign option here. Scaleway has shipped its own Secret Manager with a native ESO provider since 2023. What OVHcloud adds is the Vault KV2 compatibility, which means teams already standardised on ESO’s Vault provider can swap the backend without rewriting their ClusterSecretStore plumbing. Useful, not revolutionary. And it comes with caveats worth understanding before you commit.

How the Architecture Works

The pattern has three layers.

OVHcloud Secret Manager is the source of truth. You create secrets through the OVHcloud control panel or API, stored in a region you choose (currently eu-west-par for Paris). Every secret is encrypted at rest using a key managed by OVHcloud KMS. The KMS supports KMIP (Key Management Interoperability Protocol), which means your encryption keys aren’t locked to OVHcloud. If you need to migrate, KMIP gives you a standards-based exit path.

ESO’s ClusterSecretStore connects to Secret Manager using the HashiCorp Vault provider. The configuration points to your OKMS endpoint (e.g., eu-west-par.okms.ovh.net), authenticates with an IAM Personal Access Token stored as a Kubernetes Secret, and exposes Secret Manager as a backend for the entire cluster. The Vault KV2 compatibility means ESO treats OVHcloud exactly like it would treat a Vault instance. No patches, no forks, no custom code.

ExternalSecret resources define what gets synced and where. Each ExternalSecret references the ClusterSecretStore, specifies the remote secret path (e.g., prod/va1/dockerconfigjson), and maps it to a Kubernetes Secret in the target namespace. Sync interval is configurable (30 minutes in OVHcloud’s example). If the secret changes in Secret Manager, ESO reconciles automatically.

The entire data path stays within French/EU infrastructure. Compute on OVHcloud MKS (their CNCF-certified managed Kubernetes). Secrets in OVHcloud Secret Manager. Keys in OVHcloud KMS. No component touches US jurisdiction.

The SEAL Assessment

Mapping this stack against the SEAL framework:

The gap between SEAL-2 and SEAL-3 is where jurisdiction lives. Running AWS Secrets Manager in eu-west-1 checks the data residency box but leaves legal jurisdiction and operational control in US hands. That’s SEAL-2 at best, and under DORA’s third-party risk requirements, it’s the kind of gap an auditor will flag.

OVHcloud’s stack lands at SEAL-3 today, with a path to SEAL-4 once the KMS certifications (ISO 27001, FIPS 140-2 Level 2, CSPN) are finalized and MKS achieves SecNumCloud qualification. OVHcloud filed its Public Cloud SecNumCloud application (D0) in May 2025. The roadmap puts IaaS building blocks (VMs, storage) on the SecNumCloud stack in early 2026, with managed Kubernetes targeted for end of 2026.

The Dependency You Need to Assess

Here’s where the story gets complicated.

ESO, the open-source project that makes this entire pattern work, paused all official releases on August 13, 2025. The maintainer team was unsustainably small relative to the project’s adoption. They stopped publishing new features, patches, and container images. Community PRs still get merged, but official releases froze.

Version 1.3 shipped on January 23, 2026, and v2.x releases followed through early 2026 (v2.3.0 is current as of April 2026), suggesting some recovery. Red Hat also introduced an enterprise-backed ESO distribution for OpenShift in November 2025, which adds commercial support to the ecosystem. The project isn’t dead. But “CNCF Sandbox project with a recent release pause” is not the same as “stable, well-funded infrastructure.”

For a secrets management component in a regulated financial services stack, that matters. DORA requires you to assess ICT third-party concentration risk. An open-source operator with a fragile maintainer base is an ICT dependency, and your risk assessment should treat it as one.

Three mitigation paths are worth knowing about:

OVHcloud’s native ESO provider was announced in the November 2025 blog post as “coming in the coming months” and shipped in ESO v2.3.0 in April 2026. It supports both token and mTLS authentication against the OKMS endpoint, which removes the dependency on the Vault provider compatibility layer and gives OVHcloud direct control over the integration. For new deployments, this is now the path of least resistance.

OpenBao (the Linux Foundation fork of HashiCorp Vault, created after the BSL license switch) hit v2.5.0 in February 2026. It’s API-compatible with Vault, so ESO’s Vault provider works with OpenBao as a backend. If you need a self-hosted secrets backend with a truly open-source license (MPL 2.0), this is the current best option. IBM engineers are among its key contributors.

Infisical offers its own Kubernetes Operator (MIT-licensed) that bypasses ESO entirely. The operator syncs secrets from Infisical’s platform to Kubernetes. The caveat: Infisical is a US-incorporated company. They offer EU-hosted regions, but the corporate jurisdiction question remains for SEAL-3+ scenarios.

What This Looks Like for a Regulated Team

Consider a Dutch lending platform running payment processing on Kubernetes. They’re using AWS Secrets Manager today with ESO, storing API keys and database credentials in eu-west-1. Under DORA’s ICT third-party risk requirements, their compliance team flags the CLOUD Act exposure in a quarterly review.

The migration path: deploy OVHcloud MKS in eu-west-par, set up Secret Manager, create a ClusterSecretStore pointing to the OVHcloud OKMS endpoint, and migrate ExternalSecret definitions. Because ESO’s abstraction layer is provider-agnostic, the ExternalSecret resources barely change. The ClusterSecretStore config swaps out the server URL and auth mechanism. The application pods don’t know the difference.

The hard part isn’t the technical migration. It’s the dependency assessment. The team needs to decide: do we accept ESO’s project health risk, pin to the Red Hat OpenShift distribution for enterprise support, or standardise on OVHcloud’s native provider (now available in ESO v2.3.0) to remove the Vault compatibility layer from the stack?

That decision depends on the team’s risk appetite and timeline. For most regulated teams, I’d lean toward deploying ESO now with the native OVHcloud provider where possible, pinning your version, not chasing bleeding-edge releases, and keeping an eye on the GitHub repository’s pulse.

Practical Next Steps

If you’re running Kubernetes workloads under EU financial services regulation and your secrets are still in a US-jurisdiction manager:

Audit your current secrets pipeline. Map every external secret to its storage location, the corporate jurisdiction of the provider, and the legal framework governing access. DORA requires this mapping anyway.

Evaluate OVHcloud Secret Manager as a replacement backend. The Vault KV2 API compatibility means the integration cost is a ClusterSecretStore config change, not an application rewrite. Start with non-critical secrets to validate the sync behavior.

Assess ESO as a dependency. Check the project’s release cadence, the Red Hat distribution’s support terms, and OVHcloud’s native provider timeline. Document this assessment in your ICT risk register. Compliance teams will ask.

Don’t skip the key management layer. OVHcloud KMS with KMIP gives you portability. If you ever need to move secrets to a different EU provider, the keys aren’t trapped. That portability is what separates a real sovereignty strategy from “we picked the least bad option and hoped for the best.”

The tooling for sovereign secrets management on Kubernetes exists today. It works. The OVHcloud + ESO pattern is technically sound and hits SEAL-3. The open question isn’t whether you can run EU-sovereign secrets. It’s whether the open-source layer underneath is mature enough for your risk tolerance, and what your fallback looks like if it isn’t.

For most teams, the answer is: deploy it, pin your versions, and keep your options open. Sovereignty is a direction, not a destination. The infrastructure is catching up. Your job is to make sure your secrets aren’t still sitting in a jurisdiction that doesn’t require a warrant to read them.