Secrets

How the gateway centralises sensitive values in an encrypted store and lets other configuration reference them safely.

Secrets hold the sensitive material the gateway needs: passwords, keys, certificates, and tokens. Instead of embedding raw values across surfaces or credentials, the gateway stores secrets in one encrypted access-controlled store and other configuration references them by identifier.

Why secrets are centralised

Centralised secret storage means values are entered once, encrypted at rest, and never duplicated through configuration.

  • Surfaces, credentials, and authentication settings reference secret identifiers.
  • Rotation happens in one place and applies everywhere that secret is used.

This model reduces accidental exposure and simplifies operational rotation and revocation.

The three secret types

SecretsEncrypted key-value entries for OAuth client secrets, passwords, bearer tokens, and similar material. The list view hides values. Open the secret to view or update the stored value.
API KeysInbound authentication credentials for API key surface authentication. Each key shows as Active or Revoked and can be revoked to deny requests immediately.
Client CertificatesX.509 certificates for mTLS in caller verification and gateway-presented certificate scenarios. Certificate kind (Server leaf, Client leaf, Certificate Authority) controls usage.

Where secrets fit in the gateway

Secrets are the trust-material backing store for the entire product.

  • Inbound path: supplies API keys and certificates used to authenticate callers.
  • Outbound path: supplies keys and client secrets used by credentials when calling external services.

Because all other screens reference secrets rather than embedding values directly, rotation and revocation are immediate, centralised, and consistently enforced.

  • Credentials: Outbound delegation model built on secret references.
  • Settings: System operations including secure backup and restore behavior.