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.
Architecture
Connectivity zones
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