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.
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
| Area | Measure |
|---|---|
| Flow policy | Default-deny NetworkPolicy per namespace, then explicit allow rules, flow by flow; rollout to every managed service namespace in progress (A.8.20). |
| Service exposure | Services published only through controlled ingress, TLS terminated with automatically renewed certificates (A.8.21). |
| Internal links | Encrypted WireGuard mesh between nodes; inter-site traffic never travels in cleartext (A.8.21). |
| Tenant segregation | A 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 access | Cluster administration through a WireGuard VPN (Headscale), never by exposing control planes directly (A.8.21). |
| Web filtering | CrowdSec in front of the public edge, banning the IP addresses flagged by our own detections (scans, exploitation attempts) for 15 minutes, up to 4 hours for repeat offenders. Its AppSec module also inspects request content and blocks the exploitation of known vulnerabilities. If it fails, requests are let through. Complemented by denial-of-service protection (A.8.23, partial). |
| Monitoring | Alerting 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 CrowdSec alerts, including likely wrongful blocks of legitimate clients.
- Any abnormal exposure or unexpected access is reported without delay to security@france-nuage.fr.
Status and roadmap
Security of network services is in place and operational (A.8.21). Network security and segregation are partial (A.8.20, A.8.22): default deny and filtering of inbound flows between tenants do not yet cover every managed service.
Web filtering remains partial (A.8.23). CrowdSec blocking covers the public edge, its coverage is to be generalised to the other entry points, and its web application firewall only recognises signatures of known vulnerabilities. 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
- Statement of Applicability (the status of controls A.8.20 to A.8.23)
- Cryptography Policy (the encryption of flows and secrets)
- Access Control Policy (the identities and authorisations that build on this segregation)
- Infrastructure (the datacenters, storage and network behind our services)
- Information Security Policy (the ISMS framework this policy derives from)