TLS Topology

Every network connection in an Arbitex deployment is encrypted. This page maps every connection, the TLS version used, the certificate authority that anchors trust, and whether mutual TLS is required.

For the overarching encryption principle, see Encryption Everywhere. For certificate lifecycle details, see Certificate management.

Topology diagram

┌─────────────────────────────────────────────────────────────────────┐
│                        SaaS Deployment                              │
│                                                                     │
│  Customer App                                                       │
│       │                                                             │
│       │ TLS 1.2+ (Cloudflare edge, public CA)                      │
│       ▼                                                             │
│  Cloudflare WAF / DDoS                                              │
│       │                                                             │
│       │ mTLS (Cloudflare Origin Pulls, Cloudflare CA)               │
│       ▼                                                             │
│  Azure App Gateway                                                  │
│       │                                                             │
│       │ Internal plain HTTP (within AKS pod network)                │
│       ▼                                                             │
│  Platform API                                                       │
│       │         │            │              │                       │
│       │         │            │              │                       │
│       │ ssl     │ rediss://  │ TLS 1.2+    │ TLS 1.3               │
│       │ mode=   │ (TLS)     │ (Key Vault   │ (system CA)           │
│       │ require │            │  private     │                       │
│       ▼         ▼            │  endpoint)   ▼                       │
│  PostgreSQL   Redis          ▼          LLM Providers               │
│                          Key Vault      (OpenAI, Anthropic, etc.)   │
│                                                                     │
│  Cloud Portal ──── mTLS (Arbitex CA pinned) ────► Platform          │
│  (Provisioner)                                    Provisioner       │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    Hybrid Outpost Deployment                        │
│                                                                     │
│  Customer App                                                       │
│       │                                                             │
│       │ TLS 1.3 + mTLS client cert (customer CA)                   │
│       ▼                                                             │
│  nginx / App Gateway (TLS termination)                              │
│       │                                                             │
│       │ Internal plain HTTP (localhost / container network)         │
│       ▼                                                             │
│  Outpost                                                            │
│       │              │                │              │              │
│       │ mTLS         │ TLS            │ TLS 1.3      │ TLS          │
│       │ (Arbitex     │ (Arbitex       │ (system CA)  │ (customer    │
│       │  CA pinned)  │  CA pinned)    │              │  CA)         │
│       ▼              ▼                ▼              ▼              │
│  Platform       Cloud             LLM Providers   SIEM             │
│  Management     Heartbeat         (OpenAI, etc.)  (QRadar,         │
│  API            API                               Splunk,          │
│                                                   Sentinel)        │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    Internal Service Mesh                             │
│                                                                     │
│  All inter-service connections: Arbitex CA pinned (not system CA)   │
│  Staff admin plane: Smallstep CA, FIDO2-only auth                  │
│  AKS pod-to-pod: Calico network policy (default-deny)              │
└─────────────────────────────────────────────────────────────────────┘

SaaS deployment

In the SaaS deployment, Arbitex runs entirely on Azure infrastructure. TLS terminates at the Cloudflare edge; internal traffic flows over the private AKS network.

Connection	Protocol	TLS version	CA trust anchor	mTLS
Customer → `api.arbitex.ai`	HTTPS	TLS 1.2+	Public CA (via Cloudflare)	No (server-only)
Cloudflare → AKS origin	HTTPS	TLS 1.2+	Cloudflare Origin CA	Yes (Authenticated Origin Pulls)
Platform → PostgreSQL	PostgreSQL wire protocol	TLS 1.2+	Azure-managed CA	No (server-only, `sslmode=require`)
Platform → Redis	Redis protocol over TLS	TLS 1.2+	Azure-managed CA	No (`rediss://` scheme)
Platform → Azure Key Vault	HTTPS	TLS 1.2+	Azure private endpoint CA	No (AAD token auth)
Platform → LLM providers	HTTPS	TLS 1.3	System CA bundle	No
Cloud Portal → Platform Provisioner	HTTPS	TLS 1.2+	Arbitex CA (pinned)	Yes (client cert from Arbitex Intermediate CA)

PostgreSQL TLS

The platform connects to PostgreSQL with sslmode=require embedded in the DATABASE_URL. The startup validator rejects plaintext PostgreSQL connections in production. Azure Flexible Server for PostgreSQL enforces TLS by default.

Redis TLS

Production Redis connections must use the rediss:// scheme (TLS). The startup validator validate_redis_tls() rejects redis:// (plaintext) URLs when ENVIRONMENT=production. Redis is optional — if REDIS_URL is empty, the validator passes.

LLM provider connections

All outbound connections to LLM providers (OpenAI, Anthropic, Azure OpenAI, Google, Cohere, etc.) use TLS 1.3 with the system CA bundle. There is no CA pinning for LLM provider connections — standard public PKI is used.

Hybrid Outpost deployment

In the Hybrid Outpost deployment, the Outpost runs on customer infrastructure (on-premises or customer cloud). All connections between the Outpost and Arbitex infrastructure use mTLS with Arbitex CA pinning.

Connection	Protocol	TLS version	CA trust anchor	mTLS
Customer → nginx/App Gateway	HTTPS	TLS 1.3	Customer-provided cert	Optional (mTLS client cert if configured)
nginx → Outpost	HTTP	N/A (localhost)	N/A	No (internal only)
Outpost → Platform Management API	HTTPS	TLS 1.2+	Arbitex CA (pinned via `OUTPOST_CA_PATH`)	Yes
Outpost → Cloud Heartbeat API	HTTPS	TLS 1.2+	Arbitex CA (pinned via `OUTPOST_CA_PATH`)	Yes (preferred) or Bearer token fallback
Outpost → LLM Providers	HTTPS	TLS 1.3	System CA bundle	No
Outpost → SIEM connectors	Syslog/TLS or HTTPS	TLS 1.2+	Customer CA	Depends on SIEM

nginx TLS termination

The Outpost ships with an nginx configuration (nginx-mtls.conf) that terminates TLS at the edge:

Protocol: TLS 1.3 only (ssl_protocols TLSv1.3)
Server certificate: /etc/nginx/certs/outpost.pem
Client verification: Optional — ssl_verify_client on when mTLS is enabled
Client CA: /etc/nginx/certs/ca.pem (customer’s CA for verifying client certificates)
Proxy to Outpost: Plain HTTP on localhost:8300 (never exposed outside the container network)
Health check: /health endpoint bypasses mTLS (ssl_verify_client off)

Outpost → Platform mTLS

The Outpost authenticates to the Platform Management API and Cloud Heartbeat API using mTLS. The SSL context is constructed identically in both PolicySyncClient and HeartbeatSender:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_cert_chain(certfile=cert_path, keyfile=key_path)
ctx.load_verify_locations(cafile=ca_path)  # Arbitex CA pinned
ctx.check_hostname = True
ctx.verify_mode = ssl.CERT_REQUIRED

The three certificate files are configured via:

Environment variable	Default	Purpose
`OUTPOST_CERT_PATH`	`certs/outpost.pem`	Outpost client certificate
`OUTPOST_KEY_PATH`	`certs/outpost.key`	Outpost client private key
`OUTPOST_CA_PATH`	`certs/ca.pem`	Arbitex CA certificate for server verification

If any of these files are missing at startup, the Outpost raises a RuntimeError and refuses to start. There is no fallback to unverified connections for policy sync.

CA pinning

The Outpost pins to the Arbitex CA certificate rather than the system CA bundle. This means:

A rogue public CA cannot issue a certificate that the Outpost would trust
MITM attacks require compromising the Arbitex CA private key (stored in Azure Key Vault HSM)
The Outpost ignores all system-installed CA certificates for Platform and Cloud connections

SIEM connector TLS

SIEM connectors require TLS with a verified server certificate:

SIEM	Protocol	TLS configuration
QRadar	CEF over TLS syslog	`QRADAR_TLS_CA_PATH` for server verification; optional mTLS via `QRADAR_TLS_CERT_PATH` + `QRADAR_TLS_KEY_PATH`
Splunk HEC	HTTPS	System CA or customer CA bundle
Microsoft Sentinel	HTTPS	Azure-managed CA
Elastic	HTTPS	System CA or customer CA bundle
Datadog	HTTPS	System CA
Sumo Logic	HTTPS	System CA

In production, SIEM connections require verified TLS. The QRadar connector rejects CERT_NONE (unverified) configurations in production environments — QRADAR_TLS_CA_PATH must be set.

Internal service mesh

Within the AKS cluster, all inter-service communication is encrypted and policy-controlled:

Layer	Control
Network	Calico default-deny; explicit allowlist per service pair
Transport	TLS on all private endpoints (PostgreSQL, Redis, Key Vault)
Identity	Arbitex CA pinned for all internal mTLS connections (not system CA)
Authentication	mTLS client certificates identify services; no bearer token fallback for internal calls

Staff admin plane

Arbitex maintains a separate administrative plane for internal operations, isolated from customer-facing infrastructure. The staff admin plane uses a separate certificate authority (Smallstep CA) and requires FIDO2 hardware key authentication with no fallback.

Startup enforcement

Every Arbitex component validates its encryption posture at startup. Production deployments reject cleartext paths with fail-fast errors:

Component	Validator	What it checks
Platform	`validate_redis_tls()`	Rejects `redis://` in production; requires `rediss://`
Platform	`validate_secrets_backend_production()`	Rejects `SECRETS_BACKEND=env` in production
Cloud	mTLS enforcement (lifespan)	Rejects startup if `CLOUD_SERVICE_CERT_PATH` and `CLOUD_SERVICE_KEY_PATH` are not configured in production
Cloud	Secrets backend check	Requires `SECRETS_BACKEND=vault` in production
Outpost	`check_mtls_certs()`	Validates PEM format, x509 expiry, file permissions on cert files
Outpost	`validate_siem_url()`	Rejects `http://` SIEM URLs in production (unless `INSECURE_ALLOW_HTTP=true`)
Outpost	`check_tls_cert_readable()`	Confirms file read access on all configured cert paths

No component silently falls back to cleartext. If a TLS path is misconfigured, the component logs a CRITICAL error and either refuses to start or blocks the affected functionality.