Deployment

Identity Model

Zone identity, mTLS, and NATS authorization

Audience: Security architects, infrastructure engineers. Use: Define zone identity, certificate, and account-scoping rules for BSFG nodes.

Zone Identity Principle

Each zone has a zone identity derived from deployment configuration, not from application semantics or network location. The zone identity is:

Zone Identity Examples

enterprise-bsfg      (Enterprise zone)
idmz-bsfg           (IDMZ zone)
plant-a-bsfg        (Plant A zone)
plant-b-bsfg        (Plant B zone)

Naming Convention

Zone names follow the pattern: <deployment-context>-bsfg

Alternative formats (if preferred):

mTLS Certificates

Each BSFG node has an mTLS certificate whose Subject CN (Common Name) is the zone identity.

Certificate Structure

Subject:
  CN=enterprise-bsfg
  O=MyOrganization
  OU=Operations
  L=Headquarters
  ST=StateOrProvince
  C=CountryCode

SubjectAltName (SAN):
  DNS: bsfg-enterprise.example.com
  DNS: bsfg-ent.local
  IP: 10.0.1.10

Key Usage:
  TLS Web Server Authentication
  TLS Web Client Authentication

Issuer:
  CN=MyOrganization-CA
  O=MyOrganization

Certificate Generation

Example (using openssl):

# Generate private key
openssl genrsa -out enterprise-bsfg.key 4096

# Generate CSR (Certificate Signing Request)
openssl req -new \
  -key enterprise-bsfg.key \
  -out enterprise-bsfg.csr \
  -subj "/CN=enterprise-bsfg/O=MyOrg/C=US"

# Sign with CA (assume CA cert and key exist)
openssl x509 -req \
  -in enterprise-bsfg.csr \
  -CA ca.crt \
  -CAkey ca.key \
  -CAcreateserial \
  -out enterprise-bsfg.crt \
  -days 365 \
  -sha256 \
  -extfile <(echo "subjectAltName=DNS:bsfg-ent.local,IP:10.0.1.10") \
  -extensions v3_req

NATS Accounts and Authorization

Each zone's JetStream domain is isolated. NATS accounts are zone-scoped, not globally shared.

Account Model

Accounts in Enterprise JetStream:
  - enterprise-account (all applications in Enterprise)
  - system-account (BSFG node system calls)

Accounts in Plant A JetStream:
  - plant-a-account (all applications in Plant A)
  - system-account (BSFG node system calls)

Accounts in IDMZ JetStream:
  - idmz-account (IDMZ applications and mediated workloads)
  - system-account (BSFG node system calls)

Authorization Rules

Each account has permissions on subjects (streams) and operations (publish, subscribe):

enterprise-account:
  publish:
    subject: "facts.>" (allow publishing to all fact streams)
    allow
  subscribe:
    subject: "facts.>" (allow subscribing)
    allow

plant-a-account:
  publish:
    subject: "facts.>" (allow publishing)
    allow
  subscribe:
    subject: "facts.>" (allow subscribing)
    allow

system-account:
  publish:
    subject: "$JS.>"  (system streams for cursor, confirmations)
    allow
  subscribe:
    subject: "$JS.>"
    allow

Envelope Validation

When a fact arrives with envelope fields from_zone and to_zone, the BSFG node validates them against the authenticated peer identity (mTLS certificate CN).

Validation Logic

peer_cert = extract_peer_certificate()
peer_zone_id = peer_cert.Subject.CN

fact_envelope = extract_envelope(incoming_fact)
claimed_from_zone = fact_envelope.from_zone

if (claimed_from_zone != peer_zone_id) {
  reject(error: "from_zone does not match authenticated peer identity")
}

// Envelope is valid; proceed with AppendFact

Why Validate?

The from_zone field is declarative (claims origin). An attacker with network access could forge it. mTLS authentication binds the claim to a verified certificate, preventing spoofing.

Zone Identity in Logs and Monitoring

All audit logs should include the zone identity:

[2026-03-06T14:30:00Z] AppendFact
  from_zone: enterprise-bsfg
  authenticated_peer: enterprise-bsfg (cert CN)
  message_id: "evt-12345"
  offset: 1000
  status: success

Identity Lifecycle

Initial Setup

  1. Define zone names in deployment configuration (e.g., Terraform, Helm values)
  2. Generate mTLS certificates with zone identity in CN
  3. Deploy BSFG nodes with certificates
  4. Create NATS accounts per zone

Adding a New Zone (e.g., Plant B)

  1. Choose zone identity: plant-b-bsfg
  2. Generate mTLS certificate with CN=plant-b-bsfg
  3. Deploy BSFG node in Plant B zone
  4. Create NATS account for Plant B applications
  5. Update firewall rules to allow Plant B ↔ IDMZ communication
  6. Update any cross-zone routing policies or discovery

Certificate Rotation

Periodically rotate certificates (every 1–2 years or when policy changes):

  1. Generate new certificate with the same CN (zone identity)
  2. Install new certificate on the BSFG node
  3. Restart BSFG node (or hot-reload if supported)
  4. Verify connectivity with all peer zones

Multi-Instance HA (Optional)

If a zone runs multiple BSFG node instances (for HA):

Zone: Enterprise
  Instance 1 (10.0.1.10):  CN=enterprise-bsfg
  Instance 2 (10.0.1.11):  CN=enterprise-bsfg
  Instance 3 (10.0.1.12):  CN=enterprise-bsfg

Peers see one zone identity "enterprise-bsfg" (the logical zone), not three nodes.

Deployment Checklist

← Back: Network Policy Next: Operations Runbook →