Encryption Everywhere

Arbitex enforces encryption on every data path — in transit, at rest, and at every integration boundary. There are no plaintext fallbacks, no optional TLS flags, and no silent downgrades. Every component validates its encryption posture at startup and refuses to operate if the posture is degraded.

This page is the canonical reference for the Encryption Everywhere principle.

In transit

All network connections use TLS. There are no HTTP fallbacks in production.

Connection type	Minimum TLS	Authentication
Customer → API Gateway	TLS 1.2+	Server certificate (public CA via Cloudflare)
Cloudflare → AKS origin	TLS 1.2+	mTLS (Cloudflare Authenticated Origin Pulls)
Outpost → Platform Management	TLS 1.2+	mTLS (Arbitex CA pinned)
Outpost → Cloud Heartbeat	TLS 1.2+	mTLS (Arbitex CA pinned)
Cloud Portal → Platform Provisioner	TLS 1.2+	mTLS (Arbitex CA pinned)
Platform → PostgreSQL	TLS 1.2+	Server cert (`sslmode=require`)
Platform → Redis	TLS 1.2+	Server cert (`rediss://` scheme)
Outpost → LLM providers	TLS 1.3	Server cert (system CA)
Outpost → SIEM connectors	TLS 1.2+	Server cert (customer CA)
Internal service mesh	TLS 1.2+	mTLS (Arbitex CA pinned, not system CA)

mTLS for service-to-service

All inter-component connections within the Arbitex infrastructure use mutual TLS. Both sides of the connection present certificates issued by the Arbitex CA hierarchy. The system CA bundle is not used — only certificates chaining to the Arbitex Root CA are trusted.

This means:

A compromised public CA cannot issue a trusted certificate for Arbitex internal services
MITM attacks require compromising the Arbitex CA private key (HSM-backed, offline root)
Each service identity is cryptographically verified on every connection

Arbitex CA pinning

Internal connections pin to the Arbitex CA rather than trusting the system CA bundle. The Outpost implements this via ssl.SSLContext.load_verify_locations(cafile=ca_path), which replaces the default trust store with the Arbitex CA certificate. Platform and Cloud components use the same pattern with MTLS_CA_BUNDLE.

For the complete connection map, see TLS Topology.

At rest

All persistent data is encrypted using Azure infrastructure encryption. Arbitex does not implement application-layer data-at-rest encryption — the encryption boundary is the Azure storage layer.

Control	Implementation
VM disk encryption	Azure Disk Encryption (ADE) — dm-crypt (Linux) or BitLocker (Windows)
Managed disk encryption	Encrypted by default; customer-managed keys (CMK) via Key Vault supported
Storage account encryption	Azure Storage Service Encryption (SSE) with AES-256
Database encryption	Azure Flexible Server for PostgreSQL — storage encryption enabled by default
Key storage	Azure Key Vault — FIPS 140-2 Level 3 HSM-backed

Why no application-layer DAR

Arbitex deliberately does not double-encrypt data at rest. Azure Disk Encryption and the Arbitex application run in the same trust boundary (the VM). If an attacker has access to VM memory, application-layer encryption keys are also accessible. Double encryption adds operational complexity (key rotation, recovery procedures, performance overhead) without changing the security outcome.

The exception is Fernet encryption for specific configuration secrets (SAML IdP metadata, webhook tokens), which protects against database-level compromise without VM access. See Encryption — Fernet.

For Azure DAR deployment requirements and a verification checklist, see Azure DAR Requirements.

Key management

All cryptographic keys are managed through Azure Key Vault with HSM backing.

Key type	Storage	Algorithm	Rotation
Root CA private key	YubiHSM 2 (offline)	EC P-384	Manual (hardware ceremony)
Intermediate CA private key	Azure Key Vault HSM	EC P-384	Annual
Service leaf certificates	cert-manager (Kubernetes secrets)	EC P-384	90 days (auto-renewed by cert-manager)
Disk encryption KEK	Azure Key Vault	RSA 4096	Configurable (auto-rotation supported)
Fernet data encryption key	Azure Key Vault	AES-128-CBC + HMAC-SHA256	Scheduled (re-encryption without downtime)
Operational secrets	Azure Key Vault	N/A (stored as Key Vault secrets)	Per-secret policy

Key custody

Root CA: The root private key never leaves the YubiHSM hardware. The HSM is physically disconnected after signing the Intermediate CA certificate. Root operations require physical access.
Intermediate CA: HSM-backed key in Azure Key Vault. Access is restricted to the cert-manager service principal.
Operational secrets: SECRETS_BACKEND=azure_keyvault (Platform) or SECRETS_BACKEND=vault (Cloud) is enforced in production. Plaintext environment variable storage (SECRETS_BACKEND=env) is rejected at startup.

Startup enforcement

Every Arbitex component validates its encryption posture at startup. Production deployments fail fast on misconfiguration — there are no silent fallbacks.

Platform validators

Validator	Behavior
`validate_redis_tls()`	Rejects `redis://` (plaintext) when `ENVIRONMENT=production`. Requires `rediss://` scheme.
`validate_secrets_backend_production()`	Rejects `SECRETS_BACKEND=env` in production. Requires `azure_keyvault` or `vault`.
`validate_jwt_secret()`	Rejects known weak values (`CHANGE-ME-IN-PRODUCTION`, etc.) with `RuntimeError`.

Cloud validators

Validator	Behavior
mTLS enforcement	Rejects startup if `CLOUD_SERVICE_CERT_PATH` and `CLOUD_SERVICE_KEY_PATH` are not configured in production.
Secrets backend	Requires `SECRETS_BACKEND=vault` in production.
JWT key check	Rejects startup if both `_JWT_SIGN_KEY` and `_JWT_VERIFY_KEY` are empty.

Outpost validators

Validator	Behavior
`check_mtls_certs()`	Validates PEM format, x509 expiry, and file permissions. Warns at 30 days before expiry.
`check_tls_cert_readable()`	Confirms file read access on all configured certificate paths.
`validate_siem_url()`	Rejects `http://` for SIEM URLs in production (unless `INSECURE_ALLOW_HTTP=true`).
`validate_security_requirements()`	Requires `POLICY_HMAC_KEY` and `AUDIT_HMAC_KEY`; rejects `INSECURE_SKIP_HMAC` in production.
`check_config_file_permissions()`	Private keys must be `0640` or more restrictive; certs must not be world-readable.

Fail-fast, not fail-open

The design principle is explicit: if encryption cannot be verified, the component does not start. This prevents accidental deployment of unencrypted services. Operators must fix the configuration before the service will accept traffic.

Development environments use ENVIRONMENT=development (or INSECURE_ALLOW_HTTP=true for specific validators) to relax these checks. Production enforcement cannot be bypassed by environment variables alone — the checks are separate per validator and require explicit opt-out.

Audit trail

Encryption posture is auditable. The following events are logged and available via SIEM integration:

Event	What is logged
Startup validator results	Each validator logs its pass/fail status at startup. Failures log at CRITICAL.
mTLS connection events	Cloud middleware logs the `mtls_cn` (Common Name) of the client certificate on every internal request.
Certificate expiry warnings	Outpost logs WARNING when certificates are within 30 days of expiry.
SIEM TLS configuration	QRadar, Splunk, Sentinel, and all SIEM connectors require verified TLS in production. Unverified connections are rejected.
`_SUPPORT_MTLS_BYPASS` usage	When the emergency mTLS bypass flag is active, every request is logged at CRITICAL level.

SIEM TLS requirements

All SIEM connectors enforce TLS for the connection to the customer’s SIEM:

QRadar: Requires QRADAR_TLS_CA_PATH in production for server certificate verification
Splunk HEC / Elastic / Datadog / Sumo Logic: Use HTTPS with standard CA verification
Microsoft Sentinel: Uses Azure-managed endpoints with Azure CA

No SIEM connector sends audit data over an unencrypted connection in production.

Summary

Principle	Implementation
All transit encrypted	TLS on every connection; no HTTP fallbacks
All rest encrypted	Azure Disk Encryption + Storage Service Encryption on all storage
Internal trust is pinned	Arbitex CA, not system CA, for all inter-service mTLS
Keys in HSM	Root CA on YubiHSM; operational keys in Azure Key Vault HSM
Enforcement at startup	Every component validates encryption posture; production rejects cleartext
No silent fallbacks	Misconfiguration causes startup failure, not degraded operation
Full auditability	Validator results, mTLS identity, cert expiry — all logged to SIEM