Networking

HD runs on a network you provide and operate. The installer places HD's containers on your hosts or in your Kubernetes cluster, but it does not authenticate your users, connect your nodes to each other or encrypt the traffic between them. Plan those three things before you install, and test them before you load data.

The front doors and user authorization

HD acts on the identity headers that reach it. Establishing who a caller is, and whether they should get in at all, is the job of your systems in front of it. You are responsible for:

• Both front doors. The DMS front door is the reverse proxy through which administrators reach the WebUX. The query front door is the one through which people, applications and the query services reach the Proxy, the SQL server, the GraphQL services, the MCP server and Data Explore. Any ingress you already run will do, with or without a forward-authentication step.
• Authentication and authorization. The identity provider your front doors authenticate against, and the policy that decides which users and groups are let through, are yours. The front doors set the X-Forwarded-* identity headers and must strip any a client sends.
• Keeping HD off open networks until they exist. Neither the Ansible layer nor the Kubernetes chart deploys a front door. Until yours are in place, keep the WebUX and the Proxy on a loopback or management network, where the installer publishes them by default.

The Traefik instances in the sandbox are stand-ins and are not a production configuration: its authenticator lets everyone in. The identity contract, service by service, is on the front doors page, and Two front doors covers what to settle before installing.

Connecting the nodes

Every HD node must be able to reach the others on the ports in the port table: DMS-Core at the address in its certificate's SAN, the SCC and Storage Nodes on the control and data planes, and the filter node from the SCC. Query clients also need the Storage Nodes themselves, on the data plane, because query results stream to the client directly from the SNs rather than through the Proxy. A network that lets clients reach only the Proxy returns empty results without an error.

How you provide that connectivity depends on where HD runs:

• Bare metal and Docker hosts. Nodes use host networking, and a plane is a port rather than a separate network. Your routing, VLANs and firewalls must let each host reach the others' plane addresses on those ports. The DMS keeps its own bridge networks on its host.
• Kubernetes, including Talos Linux. You provide the virtual networking: a CNI that gives Pods reachability across nodes, NetworkPolicy that allows the HD ports, and a way for query clients outside the cluster to reach the Storage Node Pods on the data plane. Check your CNI's MTU and encapsulation against the FHDWP network guide. A DPDK data path in Kubernetes also needs SR-IOV or host-network Pods, which the chart does not render (what differs on Kubernetes).
• Across sites or clouds. Links between locations, VPN or interconnect included, are yours to provision and size. Jumbo frames often do not survive them.

Encryption on the wire

HD's control plane uses mutual TLS. Node registration, configuration and the connections that dispatch and verify work carry certificates issued by the deployment's DMS-CA, as described in Identity, trust and licensing.

The data plane is not encrypted. FHDWP, the FermiHDI HD Wire Protocol on port 6987, carries records unencrypted between the Ingester, the SCC and the Storage Nodes, and from the Storage Nodes to SDK clients receiving query results. Anyone who can capture that traffic can read the records in it. The hash chain that verifies each ingested batch detects records that are lost or altered in transit, but it does not keep them confidential. The health and metrics endpoints on port 8080 are plain HTTP as well.

If your records must be encrypted in transit, add that encryption in the network:

• Isolate the data plane. A physically separate or dedicated VLAN data network, reachable only by HD nodes and approved clients, is the simplest control and works with every data path.
• Encrypt between hosts. WireGuard or IPsec tunnels between hosts, or MACsec on the links, protect FHDWP without changing HD.
• Encrypt in the CNI. On Kubernetes, use your CNI's transparent encryption (for example WireGuard or IPsec in Cilium, or WireGuard in Calico).
• Mind DPDK. A DPDK data path sends packets from the NIC without passing through the host kernel, so WireGuard, IPsec or CNI encryption on the host does not see that traffic. With DPDK, encrypt beneath the host (MACsec on the switches or NICs, or encrypting links between sites) or keep the data plane physically isolated.
• Leave room in the MTU. Encryption adds overhead: about 60 to 80 bytes for WireGuard and 60 to 70 for IPsec ESP. FHDWP's default 1200-byte packets leave room for either. Jumbo-frame mode sends 8500-byte packets, so the encrypted path must carry 8500 bytes plus that overhead without fragmenting; see the FHDWP network guide before enabling it.

Before you install

• Both front doors are chosen, and your identity provider and authorization policy are ready for them, or the WebUX and the Proxy will stay on a management network until they are.
• Every host or Pod can reach DMS-Core at the name in its certificate, and the others on the ports in the port table.
• Query clients can reach the Storage Nodes on port 6987.
• On Kubernetes, the CNI, its MTU and NetworkPolicy are in place.
• You have decided how the data plane is protected, whether by isolation, encryption or both, and whether that decision holds for a DPDK data path.