Context
BSFG already commits to zone-local JetStream domains, mTLS-authenticated peer identity, explicit cross-zone synchronization, and service-mediated access to fact streams and object storage. That leaves one broker-topology question unresolved:
- should all BSFG zones share one broad NATS account namespace?
- or should each zone own its own account boundary, with cross-zone sharing remaining explicit?
This matters because accounts are not only an authentication detail. They define visibility, permissions, and the scope within which subjects and services are naturally visible.
Options Considered
| Option | Description | Benefits | Drawbacks |
|---|---|---|---|
| Single shared account across all zones | Put Enterprise, IDMZ, and Plants into one broad account namespace. | simple initial setup easy visibility across subjects |
weakens zone isolation permissions become broad and brittle boundary separation erodes into naming convention only |
| Mixed account model | Some zones share one account while others get isolated accounts. | can ease migration permits local exceptions |
inconsistent trust model harder reasoning about visibility and policy boundary semantics become deployment-specific folklore |
| Zone-scoped accounts with explicit sharing only where needed (Selected) | Each zone owns its own account boundary; cross-zone exchange remains explicit through BSFG peers and narrowly granted exports/imports where required. | strong alignment between trust zones and broker isolation subject visibility is naturally constrained permissions stay narrow and auditable cross-zone sharing remains deliberate rather than ambient |
more account and permission administration exports/imports must be curated deliberately |
| Per-service accounts only | Ignore zone boundaries and isolate mainly by service/application identity. | fine-grained service isolation strong least-privilege potential |
over-fragments the boundary substrate misaligns with the zone-centered architecture adds operational overhead without clarifying boundary semantics |
Decision
NATS accounts are treated as zone-scoped isolation boundaries, not as one global shared namespace.
zone
-> zone-local account
-> zone-local subjects
-> zone-local permissions
Cross-zone communication does not rely on ambient subject visibility across a shared account. It remains explicit through:
- BSFG peer protocol
- mTLS-authenticated zone identity
- narrow, deliberate broker-level sharing only when truly required
This means account boundaries reinforce the same separation already present in:
- zone-local JetStream domains
- zone-local object stores
- receiver-driven pull synchronization
- service-mediated storage access
Consequences
Benefits:
- broker visibility aligns with architectural trust zones
- subject authorization stays narrow and comprehensible
- cross-zone traffic remains explicit and auditable
- shared-account shortcuts do not silently undermine the boundary model
Tradeoffs:
- account and permission management becomes a first-class operational concern
- inter-zone sharing requires deliberate configuration rather than accidental convenience
- teams must resist collapsing isolation for short-term ease