Skip to main content

Network Security Policy

This policy describes how Bunker protects its networks, exposes its services and segregates customer workloads. On the network dimension, it implements the principles of our information security policy and covers controls A.8.20, A.8.21, A.8.22 and A.8.23 of the Statement of Applicability.

Status regarding the ISO/IEC 27001 standard

Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.

Purpose and scope

This policy applies to the networks we operate in our three datacenters located in France: inter-site links, cluster networks, tenant networks, public entry points and the team's operational access. It covers employees, contractors and automated systems that reach those networks.

It does not cover the network configuration inside a customer's instances. Within their own virtual machine, the customer remains responsible for their services and how they expose them.

Principles

  • Default deny: a flow that is not explicitly allowed is blocked; opening one is a decision, never a side effect.
  • Per-tenant segregation: what runs for one customer must not be able to reach the infrastructure carrying it, nor other customers.
  • Minimal exposure: control planes and internal tooling are not reachable from the internet; operational access goes through an encrypted VPN.
  • Encrypted flows: node-to-node and site-to-site links are encrypted, including over networks we operate ourselves.
  • Declarative configuration: network rules live in Git, are reviewed in merge requests and validated in continuous integration; no rule applied by hand on a cluster.
  • Filtering at the entrance: critical entry points are filtered ahead of the application.

Measures

AreaMeasure
Flow policyDefault-deny NetworkPolicy on every namespace, then explicit allow rules, flow by flow (A.8.20).
Service exposureServices published only through controlled ingress, TLS terminated with automatically renewed certificates (A.8.21).
Internal linksEncrypted WireGuard mesh between nodes; inter-site traffic never travels in cleartext (A.8.21).
Tenant segregationA tenant's workloads cannot reach the host network, the cluster's internal network or metadata: lateral movement is blocked at the network level (A.8.22).
Operational accessCluster administration through a WireGuard VPN (Headscale), never by exposing control planes directly (A.8.21).
Web filteringCrowdSec WAF (virtual patching) fronting the critical edge, complemented by denial-of-service protection and intrusion detection (A.8.23, partial).
MonitoringAlerting on availability and network infrastructure, routed to an on-call rotation; structured, centralised access logs (A.8.20).

Responsibilities

  • The CISO (François-Guillaume Ribreau) owns this policy and decides on any flow opening that widens the exposed surface.
  • The engineering team declares network rules in the infrastructure repositories; every change goes through merge-request review.
  • The SRE on-call rotation handles network alerts and events raised by the WAF.
  • Any abnormal exposure or unexpected access is reported without delay to [email protected].

Status and roadmap

Network security, security of network services and segregation of networks are in place and operational (A.8.20, A.8.21, A.8.22).

Web filtering remains partial (A.8.23). The WAF protects the critical edge, and its coverage is to be generalised to the other entry points. Two adjacent measures are also incomplete: the remote-working policy governing operational access from outside remains to be formalised (A.6.7, partial), and the user-endpoint policy for the devices used for that access is planned, not written (A.8.1). We do not present these gaps as covered: they appear as such in our Statement of Applicability.

Review

This policy is reviewed at least once a year and whenever our network topology, entry points or segregation mechanisms change significantly.

Last reviewed: 31 August 2026.

See also