Connection security
How Flax protects warehouse credentials — an encrypted secrets key-ring with rotation, and an SSRF egress guard that vets every outbound connection.
Every connection holds a secret — a password, token, or private key. Flax protects those secrets at rest and guards where it is allowed to connect. This page covers both controls; for organization-wide security, see Security.
#Encrypted secrets key-ring
Connection secrets are encrypted with AES-256-GCM before they are stored; Flax keeps only this safe, secret-free view of a connection in plain form. Encryption uses a key-ring rather than a single static key (ADR-0028), which enables rotation:
- The ring has one primary key (used to encrypt) and any number of retired keys (still able to decrypt), so you can roll to a new key without a coordinated outage or bulk re-encryption.
- Each ciphertext is bound to additional authenticated data (AAD) derived from its context (the connection and its owning organization), so a secret cannot be silently lifted and reused in a different context.
Keys are supplied via configuration and never exposed through the API or UI.
#SSRF egress guard
Because Flax dials network targets you supply, it enforces an egress guard against server-side request forgery (ADR-0027). The guard vets the resolved IP of every outbound connection at dial time:
- Private, loopback, link-local, and cloud metadata addresses are blocked by default, closing the door on using Flax as a confused deputy to reach internal services.
- Self-hosted deployments whose warehouse legitimately lives on a private network can allowlist specific ranges to permit those targets.
Checking at dial time — not only on a pre-flight check — defends against DNS rebinding, where a host resolves public during validation but private at connect time.