Skip to main content

Security model

This page describes how Bunker protects its platform and the data entrusted to it, covering the layers of defence, the resilience principle behind them, and what follows from our choice to operate our own infrastructure in France. The control-by-control status is detailed in our Statement of Applicability; governance, in our security policy.

One principle: horizontal resilience​

Most hosting providers treat each datacenter as a point that must keep running at all costs, and stack local redundancies (dual power, generator, N+1 cooling) to lower its probability of failure.

We took the opposite stance. Bunker is designed to be highly resilient at the system level. Losing an entire datacenter is an event that is expected and non-critical by design. Data is replicated across our sites, and failover is tested. Concretely:

  • our managed databases replicate with cross-zone anti-affinity (replicas do not share the same site);
  • backups are copied to geographically separate storage, and a restore is tested regularly (not just the backup);
  • the continuity plan relies on this multi-datacenter failover, not on the infallibility of any single site.

The consequence is direct for how we assess our physical controls: partial hardening at a given site (for instance a UPS without a generator) is treated as a compensated control. The availability objective is met by the architecture, not by the perfection of a site. This is a deliberate engineering choice, and not a hidden weakness.

Defence in depth​

No single layer is meant to be perfect on its own; it is their overlap that protects.

Physical security​

Bunker owns and operates its three datacenters in France (Essarts-en-Bocage, Saint-Gilles-Croix-de-Vie, Nantes). Physical security (premises access, environmental protection, media disposal) is part of our scope and is not delegated to a third-party host. Storage media are encrypted at rest. A removed disk is unusable.

Network​

  • Default deny. Each namespace applies a default-deny NetworkPolicy, then allows only the necessary flows.
  • Per-tenant isolation. A tenant's workloads cannot reach the host network, the cluster's internal network or metadata: lateral movement is blocked at the network level.
  • Encrypted mesh. Traffic between nodes goes through an encrypted WireGuard mesh.
  • WAF. An application firewall (CrowdSec, virtual patching) filters the critical edge.

Identity and access​

  • Centralised SSO via Keycloak, migrating to the sovereign FerrisKey IAM. Multi-factor authentication (MFA) is handled at the identity-provider level.
  • Confidential client (BFF). Token exchange happens server-side; the session is encrypted and httpOnly; no token is exposed to the browser. Anti-CSRF and anti-replay in place, fail-closed behaviour.
  • Least privilege. The default role is read-only; administrative rights are authoritative in the database, never from a token.
  • Fine-grained authorisation. A relationship-based model (organization → folder → project → instance) decides every access, with assertions tested in CI.

Data and cryptography​

  • In transit: TLS everywhere, HTTP redirected to HTTPS.
  • At rest: secrets are protected by authenticated envelope encryption (XChaCha20-Poly1305, a per-record data-encryption key wrapped by a master key that never touches the database) and by Sealed Secrets (secrets encrypted all the way into Git). Storage applies encryption at the media level.
  • Backup and restore: daily backups that are monitored, retried automatically on failure, restore-tested regularly to prove they are usable, with an off-site copy.

Application and development​

  • Memory-safe language (Rust) at the core of the platform, eliminating entire classes of vulnerabilities.
  • Coding guardrails: blocking lint, secret redaction in logs, memory zeroization of keys, a compile-time guard preventing any mock component in production.
  • Multi-stage CI pipeline: secret scanning, lint, unit, authorization, integration and manifest-security tests, as merge gates.
  • Environment separation: distinct clusters and namespaces between qualification and production, with production promotion restricted to the main branch.

Observability and response​

Metrics, logs and traces are centralised (Grafana, Mimir, Loki, Tempo). Alerting rules cover availability, saturation, backup freshness and network infrastructure, and are routed to an on-call rotation. Every incident leads to a post-mortem.

Software supply chain​

Our critical components are open source and self-hosted. Dependencies and images are tracked and updated automatically (version bumps subject to human review), images are pulled from an internal registry with pinned tags for deterministic redeployments.

Sovereignty​

Bunker's security is inseparable from its sovereignty:

  • Hosting exclusively in France, in our own datacenters, with no dependency on a hyperscaler.
  • Personnel under French or European control: French or European citizenship is verified on hiring, consistent with the SecNumCloud requirement.
  • Re-internalisable. Because our components are open source, a customer can audit and, if they wish, take the infrastructure back in-house (the opposite of proprietary lock-in).

See also​