Network Requirements
This page collects the network prerequisites for an on-premise DuoKey deployment. They apply to both deployment models — the OpenShift reference architecture and the VM-only deployment — and cover connectivity, inter-site latency/bandwidth, time synchronization, name resolution, and the firewall flow matrix.
The stack: a frontend (UI), the Cockpit API (backend — DKE / KMS / KMIP endpoints), a PostgreSQL cluster, Redis, OpenBao for secrets, plus ArgoCD (GitOps) and VictoriaMetrics / VictoriaLogs for observability. Key custody defaults to the built-in Software Vault; where a deployment adds the optional DuoKey MPC KMS cluster (3+ nodes) or a Securosys HSM as its key-custody backend, the sections below cover their network requirements too. There is no third-party TSM and no message broker.
Inter-site latency — for the DuoKey MPC cluster (if you add it) and for PostgreSQL replication — and the firewall flow matrix are the items that most often block an on-premise go-live. Validate them before installation, not during it.
Connectivity zones
DuoKey is designed to run inside segmented networks. The recommended layout uses three zones; keep secrets traffic (OpenBao, any HSM) on a dedicated, hardened segment.
Traffic enters through the edge, reaches the application zone, which in turn talks to the segmented data zone, the hardened secure zone, and your identity provider.
Recommended segmentation: separate VLANs for application, secure (OpenBao / HSM) and data (PostgreSQL, Redis) traffic. See Network Security for hardening and TLS details.
Inter-datacenter latency & bandwidth
Two links are latency-sensitive if you add the optional DuoKey MPC KMS as your key-custody backend. The MPC cluster is the first: every key operation (DKE wrap/unwrap, sign) is computed jointly across its 3+ nodes, so node-to-node latency directly bounds key-operation time. The second — always relevant, whichever key-custody backend you use — is PostgreSQL replication between sites. Key wrap/unwrap runs in the Cockpit API against the local vault backend (Software Vault, MPC, or HSM) and database, so intra-site app↔data latency must also stay low.
The figures below are engineering guidance, not contractual guarantees. Final placement (single-site vs stretched vs active/passive) is confirmed with DuoKey against your availability and performance targets.
| Link | Metric | Recommended | Notes |
|---|---|---|---|
| DuoKey MPC node ↔ node (optional backend) | Round-trip latency | ≤ 2 ms (ideal), degrades past ~5 ms | Every key op is computed jointly across the nodes; low, stable RTT is critical |
| DuoKey MPC node ↔ node (optional backend) | Jitter / packet loss | jitter ≤ 1 ms · loss ~0% | Synchronous joint computation stalls on retransmits |
| Cockpit API ↔ DuoKey MPC cluster (optional backend) | Round-trip latency | < 2 ms (same site) | The backend calls the cluster on each key operation |
| PostgreSQL primary ↔ replica | Round-trip latency | ≤ 5 ms for synchronous replication | Beyond this, use asynchronous replication and accept a small RPO |
| PostgreSQL primary ↔ replica | Bandwidth | ≥ 1 Gbps (≥ 10 Gbps for large tiers) | Sized with the sizing tiers |
| Cockpit API ↔ PostgreSQL / Redis (same site) | Round-trip latency | < 1 ms | Same-site switched LAN |
| App zone ↔ secure zone (OpenBao) | Round-trip latency | < 5 ms | Secrets are fetched on service start, not per request |
| Site ↔ site (overall) | Bandwidth · jitter · loss | ≥ 1 Gbps · low jitter · ~0% loss | Replication and failover health depend on a clean link |
Placing MPC nodes across sites with > 10 ms RTT (or lossy/jittery links) slows every key operation and can trip operation timeouts. For two distant datacenters, prefer a per-site MPC cluster with active/passive failover rather than a single cluster stretched across the WAN — see VM-only deployment → Multi-site HA.
If you add a Securosys HSM for a hardware root of trust, the backend calls it on each key operation — put it on a low-latency, reliable link (ideally same-site). See Key custody.
Placement patterns
- Single site (recommended default): the whole stack — including the DuoKey MPC cluster, if you've added it — in one datacenter, with nodes across separate racks/failure domains.
- Active / passive (regional): an independent stack (with its own per-site MPC cluster, if used) per site, with PostgreSQL/OpenBao replication and a Geo load balancer steering traffic. Use this when the inter-site link is slow or long-distance.
- Stretched (metro): a single stack across two nearby datacenters on a low-latency metro link (≤ 2 ms for MPC, if used; ≤ 5 ms for synchronous DB replication). Only on a fast, reliable link.
Time synchronization (NTP)
Accurate, synchronized clocks are mandatory. Skewed clocks break TLS / certificate validity checks, 2FA (TOTP) logins, JWT/token expiry, and make audit-log correlation unreliable.
| Requirement | Recommendation |
|---|---|
| Protocol | NTP (or the platform's chrony) on every host and VM |
| Sources | ≥ 2 redundant, reachable NTP servers (internal appliance or pool) |
| Max clock skew | < 1 s across all nodes; aim for < 100 ms |
| Air-gapped sites | A local stratum-1/2 NTP source (e.g. GPS/PTP appliance) — never leave nodes free-running |
| Timezone | Run hosts in UTC; localize only in the UI |
Name resolution (DNS)
Full DNS record list — external, internal, and the critical split-horizon DKE endpoint — is documented on its own page: DNS Records.
Network-level requirements:
- Every host/VM points at ≥ 2 internal resolvers; resolvers must answer for both the internal zone and (via forwarders) public names.
- Split-horizon DNS for the DKE endpoint so the same hostname resolves to the internal LB VIP on-net and the public ingress off-net — with the same TLS certificate.
- Point records at health-checked load-balancer VIPs, never a single node.
Firewall flow matrix
Open the following flows. <...> are placeholders for your VIPs/subnets. Ports
marked per vendor are provided by the HSM/vault vendor for your version.
North–south (users → platform)
| Flow | Source | Destination | Port |
|---|---|---|---|
| Office / M365 → DKE key endpoint | Clients, *.protection.outlook.com | Public ingress / DKE VIP | 443/TCP |
| Users → Cockpit UI / API | Corporate clients | Ingress / LB VIP | 443/TCP |
| KMIP clients → Cockpit API (optional) | KMIP-enabled apps | Cockpit API KMIP endpoint | 5696/TCP |
| Admins → management (SSH) | Jump host / bastion | Node & VM management IPs | 22/TCP |
East–west (platform internals)
| Flow | Source | Destination | Port |
|---|---|---|---|
| Frontend → API | Cockpit UI | Cockpit API | 443/TCP (internal) |
| API → DuoKey MPC KMS (optional backend) | Cockpit API | DuoKey MPC cluster | 443/TCP (OAuth2) |
| DuoKey MPC node ↔ node (optional backend) | MPC nodes | MPC nodes | per DuoKey release (mTLS/TCP) |
| API → database | Cockpit API | PostgreSQL primary + replicas | 5432/TCP |
| PostgreSQL replication | Primary ↔ replicas | PostgreSQL nodes | 5432/TCP |
| API → cache | Cockpit API | Redis VIP / nodes | 6379/TCP |
| API → secrets | Cockpit API / ESO | OpenBao VIP | 8200/TCP |
| OpenBao Raft | OpenBao ↔ OpenBao | OpenBao nodes | 8201/TCP |
Platform services & egress
| Flow | Source | Destination | Port |
|---|---|---|---|
| All hosts → NTP | Every node / VM | NTP servers | 123/UDP |
| All hosts → DNS | Every node / VM | Internal resolvers | 53/UDP, 53/TCP |
| Cockpit → identity provider | Cockpit API | Azure AD / LDAP | 443/TCP · LDAP 389/636/TCP |
| API → Securosys HSM (optional) | Cockpit API | Securosys HSM | per vendor (PKCS#11 / KMIP 5696/TCP) |
| GitOps → source & registry | ArgoCD | Git source / image registry | 443/TCP, 22/TCP |
| Observability scrape / logs | VictoriaMetrics / vmagent · Vector | API & node metrics / log endpoints | per stack |
| Backup → object storage | Cluster / backup agent | S3-compatible endpoint | 443/TCP |
| Geo load balancer health checks | GSLB / LB | Per-site service VIPs | 443/TCP (or L4 probe) |
Which services sit behind an L4 vs L7 load balancer, health-check design, TLS pass-through vs termination and session affinity are covered in VM-only deployment → Load balancing.
MTU, proxy and other considerations
- MTU: keep a consistent MTU end-to-end. If any inter-site path uses VPN/overlay/jumbo frames, verify path MTU — silent fragmentation degrades database replication.
- Outbound proxy: in restricted networks, DKE/M365 flows and any external IdP/OCSP/CRL fetches may need an explicit proxy allowlist. Air-gapped sites must host a local CRL/OCSP responder and image mirror.
- No SSL-inspecting middlebox in front of the DKE endpoint — TLS interception breaks the client↔API trust the DKE flow relies on.
- Load-balancer idle timeouts must exceed the longest legitimate key operation; set generous keep-alives on the DKE/API path.
Validation
# Inter-site latency & loss to a DuoKey MPC node and a PostgreSQL replica
mtr -rwzbc100 <mpc-node-ip>
mtr -rwzbc100 <postgres-replica-ip>
# Time sync (chrony): offset should be well under 100 ms
chronyc tracking
chronyc sources -v
# Firewall reachability (returns "succeeded" when the flow is open)
nc -vz <mpc-cluster-vip> 443
nc -vz <postgres-vip> 5432
nc -vz <openbao-vip> 8200
nc -vz <ntp-server> 123 # UDP: use `nc -vzu`
# DNS split-horizon (compare internal vs external answers)
dig +short dke.example.com @<internal-resolver>
See also
- Prerequisites — hardware sizing and platform requirements
- VM-only Deployment — VM sizing and multi-site HA with Geo load balancing
- DNS Records — full record list and split-horizon
- Network Security — segmentation, TLS, hardening
- Reference Architecture — the OpenShift + VM hybrid design