Perimeter Security

Microbus assumes the bus is a closed network. The NATS broker listens only on a private port (typically :4222 on a VPC or internal subnet) with no external exposure. The HTTP ingress proxy is the single bridge between external HTTP traffic and the bus. Everything in the rest of the security model assumes the attacker has already gotten past this perimeter or is a compromised peer on the bus — perimeter security is the first layer, not the only one.

This page is the operator’s perimeter checklist.

What Other Microservices Do Not Do

A Microbus microservice does not open inbound HTTP listeners. Web handler endpoints are reached through the ingress, which forwards them onto the bus. There is no second entry point and no out-of-band path that bypasses the ingress.

This means the perimeter has exactly one external face per zone:

One ingress per zone, behind the operator’s load balancer of choice.
The NATS broker on a private port not reachable from outside the zone.
All other microservices on private subnets, talking only to NATS.

If you find yourself opening a public port on a microservice that is not the ingress, stop. Either route the traffic through the ingress or write a dedicated ingress endpoint to handle it.

Operator Checklist

TLS Termination

Terminate TLS at the load balancer or directly at the ingress.

The connection between the load balancer and the ingress should also be TLS — the framework does not assume the LB-to-ingress hop is trusted.
The connection between the ingress and the NATS broker is always TLS, with the broker presenting a certificate the ingress’s NATS client validates.
Inter-microservice traffic over the bus is TLS-encrypted by NATS.

There is no plaintext segment in a properly configured deployment.

When TLS is terminated at the ingress, mark the port with tls in the Ports config (e.g. "80, 443 tls, 8080"). The HTTP ingress proxy selects a certificate per handshake by matching the SNI hostname against the SAN names on each loaded certificate, reloads on directory changes so Kubernetes secret remounts and certbot renewals take effect without a restart, and fails the handshake closed when no SAN matches rather than falling back to an arbitrary default.

Reverse Proxies and Client Identity

Whatever sits in front of the ingress — CDN, load balancer, or both — has to be declared, because the ingress cannot infer it. Set the ingress’s TrustedProxyHops to the number of proxy tiers between the internet and the ingress.

The default of 0 is the safe posture: the ingress treats itself as internet-facing and rewrites every X-Forwarded-* header from the actual connection, so a client cannot forge its own address. Leaving it at 0 behind a real proxy costs you the client’s true IP (every request appears to come from the proxy); setting it too high hands a client the ability to forge one. Count the tiers and state the number.

Two operator obligations come with it, neither of which the framework can verify: the outermost proxy must record the client-facing host and protocol, and every interior hop must pass them through unmodified.

CORS Origins

Declare cross-origin access in the ingress’s two origin lists rather than one, and treat AllowedCredentialedOrigins as the security-relevant one — it is the exact list of origins a browser will send cookies to. The wildcard is rejected there by construction, so the classic any-origin-plus-credentials misconfiguration cannot be expressed. A public API belongs in AllowedUncredentialedOrigins, where the browser blocks credentials for you.

Web Application Firewall (WAF)

Place a WAF between external clients and the ingress. Microbus does not ship its own WAF. Common rules:

OWASP Top 10 signatures (SQLi, XSS, RCE).
Request size limits.
Method allow-lists per route.
Bot management.

The WAF is the right place for these because they are stateless edge concerns. The ingress focuses on Microbus-specific concerns (token exchange, internal-port firewalling, ACL checks).

Rate Limiting

Apply rate limits at the perimeter:

Per-IP rate limits at the load balancer or WAF — coarse but cheap.
Per-actor rate limits at the ingress — finer, applied after token exchange so the limit is keyed on verified identity rather than the easily-spoofed Authorization header.

The framework’s certified caller identity means internal rate limits at downstream microservices are already keyed on verified identity. Perimeter rate limits exist to absorb pre-authentication abuse before tokens are even minted.

Port Filtering

Outside LOCAL deployment the ingress defaults to denying any internal port other than :443. Operators opt additional ports in via the ingress’s AllowedInternalPorts config; entries must satisfy 1024 <= port <= 65535, which keeps the framework’s internal-only and trust-root tiers — including :666 and :888 — out of reach regardless of configuration. A request for any other internal port returns 404. The full port catalog is in Ports.

Belt-and-suspenders: configure your load balancer to accept inbound traffic on :80 and :443 only. Anything else hitting the perimeter is a misconfiguration or an attack — drop it before it reaches the ingress.

Request URL Length

A request’s derived NATS subject is capped at 1024 characters, and the ingress enforces the same bound at the edge so an oversized URL is rejected 414 before it ever enters the mesh, its logs, or its spans. No configuration is involved; it is noted here because a legitimate client generating very long URLs will see 414 rather than a downstream error.

CIDR Rules and Zone Isolation

Constrain which networks can reach which components:

External-internet → load balancer — the public Internet ranges.
Load balancer → ingress — the load balancer’s source IP range only.
Ingress / microservices → NATS broker — the application subnet only.
NATS broker → NATS broker (in multi-zone deployments) — the inter-zone subnet only, and over a TLS-authenticated cluster route.

Encode these as security group rules, network ACLs, or whatever the cloud or on-prem network supports. They are independent from any framework-level enforcement.

NATS Broker Hardening

The broker is the heart of the deployment. Lock it down:

Listen on the private port only — no public NATS exposure ever.
Require TLS for client connections (Microbus microservices already do this).
Require credential authentication. Each microservice’s .creds is signed at deploy time by gencreds and presented to the broker on connect; the broker rejects unauthenticated connections.
Disable the monitoring port (:8222) on the public interface; expose it only on a management network.
Set conservative max-payload, max-pending, and slow-consumer thresholds appropriate for the deployment’s scale.

A compromised NATS broker is outside the framework’s threat model — see the Defense Matrix entry for “Compromised NATS broker” in the security index. Hardening the broker is on the operator.

What Perimeter Security Does Not Do

Perimeter security is the first layer, not the only one. Specifically:

It does not protect against a compromised microservice that is already on the bus. That is what interservice ACL and certified caller identity are for.
It does not protect against a stolen actor token that successfully reaches the ingress. That is what JWKS pinning, actor-claim authorization, and short-lived access tokens are for.
It does not protect against trust-root abuse by a microservice with a legitimate :666 grant. That is what the trust-root tier is for.

Perimeter security is necessary but not sufficient. Set it up well, then assume an attacker has already gotten past it and let the rest of the model close the next layer.