Introducing Synadia Protect: a security gateway for NATS
A developer pings the platform channel: someone is publishing customer emails into a log stream that fans out to three downstream services. The data is already on the wire, and the clock has started on incident response.
You pull up the connections list. The offender’s credentials are valid — that’s not the surprise. The surprise is that a client doing exactly what auth permitted just leaked customer data into systems you can’t fully purge. The follow-up question writes itself: how do you stop the next variant?
There’s no firewall for NATS
The stack you have at the edge has three layers. None of them can answer the question.
Layer-four blindness
Your edge firewall sees TCP packets and TLS handshakes. It can stop traffic by port, by IP, by certificate fingerprint. It cannot see a subject, a header, or a payload. To it, every authenticated NATS connection is just bytes on port 4222.
Identity-only authorization
NATS accounts and credentials answer “who can connect, and what subjects can they touch.” That’s necessary, but it’s set at credential issuance and enforced per subject, not per message. The credential that legitimately publishes to logs.app is the same credential that just leaked PII. There’s no rule for “valid publisher, but this payload shouldn’t be on the wire.”
After-the-fact audit
When the incident happens, you reconstruct from server logs, NATS CLI captures, and downstream traces. Even with a clear cause, there’s no policy you could have written ahead of time at the network boundary to catch the next variant. The control point doesn’t exist.
The result: most large enterprises run NATS by exception. Security teams either grant carve-outs for app teams or block adoption entirely. The gaps don’t close; they just stay quiet until they don’t.
Synadia Protect
Today we’re introducing the firewall NATS has been missing.
Synadia Protect is a security gateway for NATS — a transparent proxy that inspects every connection and message, enforces NATS-aware policy at the network edge, and produces an audit trail your SIEM can consume. It’s built for security teams who need to ship NATS without relying on application-tier trust.
Policy that speaks NATS, not just TCP
Web application firewalls speak HTTP. Layer-four firewalls speak TCP. Protect speaks NATS. Every CONNECT, PUB, MSG, HPUB, HMSG, and LMSG is parsed and evaluated. Rules express themselves in the protocol’s own terms: subjects, headers, payloads, JWT claims, client identity, source IP, time of day. Each rule resolves to one of five actions (allow, deny, suspend, error, log), with suspend reserved for parking a misbehaving client without triggering its reconnect loop.
Hot-swap policy bundles, no restarts, no app changes
Rules are packaged into versioned bundles. Installing a bundle validates it without activating it. Activating it on a port starts evaluating rules mid-stream, no restart. Upgrading is a v2 drop-in with zero downtime. Rolling back is the same command with a lower version number. Bundles can be signed with NKeys so the gateway only accepts policy from identities you control.
The library ships with built-ins for the most common patterns: CIDR ranges, header and payload regex, JWT signers, time-of-day windows, JetStream consumer filtering, subject wildcard blocking, protocol-length caps. All of them are activated with a few lines of YAML. For anything the built-ins don’t cover, write rules in the Expr language with full access to the connection context and message contents.
Built by the team that wrote NATS
Protect uses the same parsing libraries the NATS server uses. Every protocol message, every header, every JetStream API request is interpreted the same way the server interprets it. Third-party WAFs don’t have this. They guess at the protocol and miss the details of large payloads, header semantics, and leaf-node specifics. That protocol fidelity powers everything in the product, especially trace profiles.
Forensic capture at the protocol level
Define a trace profile by source IP, connection name, JWT, NKey, port, or after-the-fact connection ID, bound by --max-duration or --max-bytes, and the gateway captures every byte exchanged with matching connections. Think tcpdump at the NATS protocol level. Replay a captured trace against any candidate bundle to prove that a new policy would have caught the incident: a regression test for your security posture. Forensic capture and policy testing on the same artifact.
How Protect works
Download a single binary. Run protect setup to scaffold a config and the keys it needs. Point it at your NATS cluster. That’s it.
Protect is a standalone product that works in front of any OSS NATS deployment. No Synadia Platform or Synadia Cloud required. It proxies both client and leaf-node connections today, with WebSocket on the roadmap. Each gateway exposes one or more named ports, each with its own backend, rule set, and connection limits, so a single gateway instance can host multiple policy domains side by side.
Standalone or fleet
Run one gateway in front of one cluster, or run a configuration server that centralizes bundle and trace-profile management across many gateways. Managed gateways mirror configuration over NATS itself, publish heartbeats, and continue enforcing their last-known policy if the configuration server is unreachable. A network partition doesn’t disable security.
CLI and web UI
Every operation is available via the protect admin CLI: bundle install / activate / upgrade / roll back, trace add and inspect, fleet status, connection disconnect and suspend. A web UI ships alongside for read-only browsing, audit search, and trace inspection. Authentication is NKey-based; revoke an admin by removing their public key from the config.
See it in action: stopping the PII leak before it happens
Same scenario from the top of the post, with Protect in the path.
Detection
A policy.action event lands in the SIEM with action deny, the offending connection ID, and a rule reference. A second event shows the connection was suspended: the client is still connected from its perspective, but no traffic is flowing. The audit event is in CEF, correlated by the same cuuid the gateway returned in the client’s error response.
Forensic capture
The operator opens the gateway UI, jumps to the suspended connection, and enables a 60-second trace profile on it. Suspend keeps the client believing it’s still connected, so it keeps publishing, and the trace captures every attempt while Protect silently drops them.
Rule authoring
To harden against the next variant, the operator drops a tighter payload rule into a new bundle:
1activations:2 com.synadia.protect.builtins.v1.deny.payload.message: true3configurations:4 com.synadia.protect.builtins.v1.deny.payload.message:5 "logs.>": "(?i)password|secret|email|api[_-]?key"No expression writing. The built-in payload rule maps subject patterns to regexes.
Test before deploy
The operator writes a test scenario — a stubbed connection plus the captured messages, each tagged with an expected verdict — and runs protect evaluate run against the new bundle. The evaluator returns pass/fail per message and a verdict for the bundle. Same workflow, no production traffic at risk.
Hot activation
protect admin bundle install, then bundle activate clients. Done. The new policy is enforcing within seconds, no gateway restart, no application change.
Continuous evidence
Every denial since the rule went live shows up in the SIEM tagged with the exact rule, bundle name, and bundle version. The auditor’s question, show me what your control caught and when, is answered by the same stream that powers the operator’s dashboard.
What used to be a postmortem question — could we have caught this? — is now a unit test.
Proactive: ship NATS without a security exception process
Most enterprises run NATS by exception. The reactive use case sells urgency; the proactive use case is bigger. With Protect in the path:
- Onboard new applications by adding a port, not by getting security approval per service. The security team owns the policy bundle; app teams own the rest.
- Enforce platform contracts at the boundary. Every publish must carry an
X-Tenantheader? Activate the header rule and the contract is enforced by the network, not by every service’s pre-commit hook. - Test policy in development, not in production. Write a scenario file with stubbed connections and assertion-tagged events;
protect evaluate runproves the bundle behaves before any port sees real traffic. - Lock leaf nodes to known networks. CIDR rules at the perimeter so a compromised edge node can’t pretend to be inside your cloud.
- Run change windows by cron. Cut a maintenance window with a time rule; admit traffic only inside business hours from office IPs with a custom Expr rule that combines both.
- Stream continuous compliance evidence. Every non-allow decision flows to your SIEM in text, JSON, or CEF, ready for the next audit without a manual log pull.
- Manage the whole estate from one place. A configuration server mirrors bundles and trace profiles across regions and environments, so the audit posture stays uniform whether the gateway runs in us-east-1 or on a leaf at a customer site.
What about my existing security stack?
Layer-four firewalls (F5, HAProxy, cloud load balancers)
Keep them. They handle TCP, TLS, network ACLs, and DDoS mitigation. Protect sits inside them and adds NATS-protocol awareness (subject, header, payload, JWT) that L4 devices cannot reach. The two complement each other.
General-purpose WAFs (Cloudflare, AWS WAF, F5 ASM)
Generic WAFs are built for HTTP. The ones that try to wedge NATS into a WAF rule engine are limited by message size, header semantics, and protocol verb coverage. They use rule libraries built for HTTP attacks that have no analog in NATS. For NATS workloads, Protect replaces them, with rules that are actually relevant to the protocol — and a scenario-based test harness that lets you assert policy behavior before activation. No WAF ships this.
NATS authentication and authorization
Keep them, of course. NATS accounts and credentials answer who can connect and which subjects they can touch. Protect runs alongside it and asks what auth can’t reason about: is this connection coming from the right IP at the right time, from a client version and JWT signer you trust? Is each message OK to forward, with the right header, the right payload shape, the right JetStream API call? The two layers stack. Protect doesn’t replace identity; it adds policy on top of it.
SIEM and audit platforms (Splunk, Datadog Security, Sumo Logic)
Keep them. Protect’s job is to emit audit events; correlating them with the rest of your security telemetry is your SIEM’s job. Protect supports text, JSON, and CEF, written to file, stdout, or published to a NATS stream that your SIEM collector subscribes to.
Get started
Install a single binary, run protect setup, and you’ll have a security gateway enforcing policy in front of your NATS cluster within minutes. The 14-day trial is open today. No application changes, no Synadia Platform required.
Related posts
All posts
