Connectivity & network topologies

A host becomes scannable by running a sidecar that proves your organization controls it. How RingZero reaches that host — to verify registration and to run scans — depends on where it lives. There are two connectivity modes, and most fleets use both.

The two modes

	Direct	Gateway
For	Public, internet-reachable hosts	Private / internal hosts
Registration challenge	RingZero dials the host’s public address	Runs over the sidecar’s outbound connection to an in-network gateway
Scan traffic	RingZero probes the host directly	A Scan Gateway probes from inside your network
Inbound from internet	Port 7301 (allowlistable)	None
What you deploy	Sidecar per host	Sidecar per host + a Scan Gateway per network

Direct mode is the model described throughout these docs: the sidecar attests, RingZero connects back to the attested address to satisfy the challenge, and scans reach the host over the internet. It’s the simplest path when the host is publicly reachable.

Gateway mode exists because most infrastructure isn’t publicly reachable — and exposing it to the internet just to run a security scan would be self-defeating. You deploy a Scan Gateway inside the network; sidecars talk only to the gateway; the gateway holds a single outbound tunnel to RingZero and runs scan probes from inside. No internal host is ever exposed.

Which mode for which network

Tip

You don’t choose globally — each host’s sidecar runs in direct or gateway mode. A single org routinely has public hosts in direct mode and private hosts behind one or more gateways.

Scenario	Mode	Why
Public cloud VM with a public IP	Direct	Internet-reachable, so the strongest challenge (RingZero dials the address itself) works and needs no extra component.
Private VPC / subnet, no ingress	Gateway	Nothing can dial in; an in-VPC gateway registers and scans over one outbound 443. (Hosts addressed only by globally-routable IPv6 aren’t “private” — those use direct mode on that address.)
On-prem / corporate LAN behind NAT	Gateway	Outbound 443 only — no port-forwarding, no exposing internal hosts.
Kubernetes ClusterIP-only services	Gateway	Sidecars dial the gateway outbound — no Service ingress, and it sidesteps the challenge round-robin problem entirely.
Multiple isolated networks / segments	One gateway per segment	Each gateway has its own approved network scope; hosts register through the gateway in their segment. Run several per segment for HA.
Fully air-gapped (no outbound at all)	Not supported in v1	The model needs an outbound tunnel. Fully air-gapped environments are on the enterprise self-hosted roadmap — contact us.

How ownership stays enforced — and the public internet stays safe

RingZero’s core promise doesn’t change: scans only ever target registered hosts, and RingZero must never become a scanner someone can point at the open internet. Each mode upholds that differently, and it’s worth being precise about how.

Direct mode. RingZero dials the attested public address for the challenge itself, off your network path. A third party won’t answer with a valid host-credential signature, so this proves control of that specific address — strong enough to protect even a single public host that isn’t yours.

Gateway mode. Three mechanisms, each protecting a different thing:

• RingZero-side routing is the authoritative guarantee for the public internet. RingZero only ever routes a scan to a gateway for a target that is an active registered host and whose address is within that gateway’s approved, non-publicly-routable network_scope — RFC1918 (10/8, 172.16/12, 192.168/16), CGNAT (100.64/10), IPv6 ULA (fc00::/7). It never routes a probe to a public IP. A public host can’t be a gateway host at all; it uses direct mode.
• mTLS org-pinning is the guarantee against other tenants: the gateway’s tunnel credential is bound to one organization, so RingZero never routes one org’s scans to another org’s gateway.
• Gateway-side re-checking is defense-in-depth for honest bugs: an uncompromised gateway independently refuses any egress whose target isn’t an active in-scope host. (Against a compromised gateway this check isn’t independent — the attacker controls it — which is why the RingZero-side routing above is what actually holds the line.)

An honest note on the gateway trust model

In gateway mode the registration challenge still runs (the sidecar signs a nonce that RingZero verifies), but because the gateway sits on the path it is defense-in-depth, not the third-party guarantee — a compromised gateway could forge it. Public-internet and cross-tenant safety don’t rest on the gateway behaving: they rest on RingZero never routing a scan outside an approved private scope, and on the mTLS identity that pins each gateway to one org. A compromised gateway box is just a machine on your own network — it can already reach whatever your network reaches, with or without RingZero.

The residual risk this leaves is narrow and worth stating plainly: because RingZero will route a scan to any active registered host in the approved scope, someone who compromises a gateway (or steals its credential plus a registration token) could get RingZero to probe a private host you don’t own but can already route to inside that scope — a shared-subnet co-tenant, a peered partner. That’s confined to your own private network, never the public internet, never another tenant, and never more than that gateway box could already reach itself. Mitigate it by declaring the tightest network_scope that covers your real hosts, and by treating the gateway enrollment credential as admin-tier — it’s revocable instantly.

Per-host ownership proof is unchanged in both modes: every scanned host still ran a sidecar you deployed. The gateway provides the network path, never a shortcut around registration.

Next steps

Deploy a Scan Gateway Enroll, configure network scope, and run the gateway in Compose or Kubernetes.

How registration works The sidecar attestation and challenge flow both modes build on.