Secrets Management in API Gateways: Why Vault Integration Should Be Non-Negotiable

Every API gateway needs credentials to call upstream services. Your payments backend requires an API key. Your internal data service uses a service token. Your SMTP relay needs username and password. These are upstream credentials — the secrets your gateway uses to talk to the services behind it.

The question is where those credentials live and what happens to them across their lifetime.

Most gateways store upstream credentials in their own configuration database — encrypted at rest, accessible to the gateway at runtime, managed through the gateway's admin interface. This is functional. It is also a security model that puts the gateway's database as the single point of exposure for every upstream secret in your estate.

Vault integration changes this model. Instead of the gateway holding credentials, it fetches them from a dedicated secrets management system at runtime — with full audit trail, automatic rotation, and dynamic secrets that expire after use. Here is why this difference matters and what it looks like in practice.

What is wrong with storing secrets in the gateway database

The blast radius of a database exposure is unbounded. If the gateway's configuration database is compromised — through a misconfiguration, a backup that ends up in the wrong place, a SQL injection vulnerability, or a support process that exports configuration — every upstream credential in that database is exposed simultaneously. One incident affects every integration the gateway manages.

Backups are a credential exposure surface. Configuration backups are necessary for disaster recovery. They are also a common source of credential leaks. A backup file that contains gateway configuration contains every upstream credential the gateway has stored. If that backup is stored insecurely, transferred to a developer's laptop for debugging, or retained longer than your data retention policy allows, the credentials in it are at risk.

Credential rotation requires gateway configuration changes. When an upstream service rotates its API key — because of a security policy, an incident, or a periodic rotation schedule — the gateway configuration must be updated to use the new key. This is a manual process that involves a gateway admin, a configuration change, and a deployment or reload. It creates a window where the old key is still in the gateway config but has been revoked at the upstream. It also creates a window where the new key is in transit between the upstream service's team and the gateway admin's update.

There is no independent audit trail for secret access. When the gateway uses a credential stored in its own database, there is no external record of when that credential was accessed and by which process. If you need to demonstrate that a credential was only used by the gateway and not by any other system, the evidence comes from the gateway's own logs — logs that the gateway itself controls.

Static credentials are long-lived by default. A credential stored in the gateway configuration is valid until explicitly rotated. In practice, rotation is deferred — it requires coordination between teams, a planned maintenance window, and testing. Credentials that "should" be rotated quarterly are often valid for years.

How Vault integration works

HashiCorp Vault (and equivalent systems — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) is a dedicated secrets management platform with properties specifically designed for the risks above.

The gateway integration pattern:

At startup or on credential request, the gateway authenticates to Vault using an application role credential. This authentication uses Vault's AppRole auth method (or Kubernetes auth in a containerised environment), which provides the gateway with a short-lived token to access specific secrets.

The gateway requests the specific secret it needs — the upstream API key, the database password, the service token — from Vault. Vault returns the current value of the secret and (for dynamic secrets) a lease ID and expiry.

The gateway uses the credential to authenticate to the upstream service.

On credential expiry or rotation, Vault notifies the gateway (or the gateway proactively re-fetches) and the updated credential is used for subsequent requests. The gateway never stores the credential beyond its active use — it fetches fresh credentials on a schedule aligned with the Vault lease.

Dynamic secrets: the strongest model

The most powerful capability in Vault integration is dynamic secrets — credentials that are generated on demand and expire after a defined period.

Instead of the gateway having a static API key that is valid indefinitely, Vault's dynamic secrets engine generates a unique credential for each gateway session or at each rotation interval. The credential is valid for a defined period (hours or days). After expiry, it is automatically revoked. The upstream service never has a credential that is valid indefinitely — only credentials with bounded lifetimes.

The security properties of dynamic secrets:

A leaked dynamic credential expires automatically. If a dynamic credential appears in a log file, a debug output, or a compromised system, it becomes invalid at its expiry time without any manual intervention. The blast radius of a credential leak is bounded by the credential's lifetime.

Each credential generation is audited in Vault. Every time the gateway requests a new credential from Vault, that request is logged in Vault's audit trail — which client requested it, at what time, and what credential was issued. This audit trail is independent of the gateway's own logs.

Revocation is immediate and verifiable. If a gateway instance is compromised, you can revoke the specific lease associated with its credentials in Vault. Other gateway instances using different leases are unaffected. The revocation is recorded in Vault's audit trail.

No long-lived credentials exist in the gateway. The gateway's configuration database contains Vault addresses and role credentials — not the upstream secrets themselves. A database dump of the gateway configuration does not expose the upstream credentials; it exposes only the Vault authentication material, which is subject to Vault's own access controls and can be rotated independently.

Vault integration requirements for API gateways

Not all "Vault integration" is equivalent. When evaluating a gateway's Vault integration, verify:

Dynamic secret support, not just secret retrieval. Some gateways can read a static secret from Vault but do not support dynamic secret leases. Static secrets read from Vault still need manual rotation — the gateway fetches the secret once at startup and holds it indefinitely. This is better than storing credentials in the gateway database, but it does not provide the automatic expiry and rotation properties of dynamic secrets.

Automatic renewal and re-fetch. The gateway should renew leases before they expire and fetch new credentials automatically when leases are not renewable. A gateway that requires a restart to pick up rotated credentials is not providing operational Vault integration.

Vault authentication aligned with your security model. The gateway should support Vault's AppRole, Kubernetes, or AWS IAM auth methods — appropriate to your deployment model. A gateway that uses a long-lived Vault token for authentication is creating a different long-lived credential problem.

Audit trail integration. Vault's audit log should be integrated into your SIEM alongside the gateway's own structured logs. The combination provides: who called the API (gateway log), which credential was used (gateway log + Vault dynamic secret log), and when that credential was issued and by which process (Vault audit log).

When gateway-native storage is acceptable

Vault integration is the right model for upstream credentials in production environments handling sensitive data. There are contexts where gateway-native credential storage is acceptable:

Development and sandbox environments where the upstream services are not handling real data and credential exposure carries low risk
Non-sensitive integrations where the upstream credential provides access to non-sensitive data (a public API key, a read-only reporting endpoint)
Environments where Vault is not part of the infrastructure and the operational cost of introducing it would not be justified by the risk reduction

The principle is proportionality: the sensitivity of the data accessible through the upstream credential determines the required security model for that credential. Production credentials for financial systems, healthcare data, or personal data justify Vault integration. A development API key for a third-party postcode lookup does not.

The compliance evidence Vault provides

For regulated industries, Vault integration provides compliance evidence that gateway-native storage cannot:

A complete, tamper-evident log of every credential access event, independent of the gateway's own logging
Automatic expiry records showing that credentials were rotated within policy-defined intervals
Revocation records demonstrating that compromised credentials were invalidated within the required response time
Separation of credential management from the system that uses credentials (the gateway), satisfying separation of duties requirements

These are requirements that appear in SOC 2, PCI DSS, HIPAA, and most financial services compliance frameworks. Gateway-native storage can satisfy some of them with sufficient operational process. Vault integration satisfies them by design.

Zerq supports HashiCorp Vault integration for upstream credential management — dynamic secret leases, automatic rotation, and independent audit trail — alongside gateway-native credential storage for environments where Vault is not in the infrastructure. See the security and secrets management capabilities or request a demo to walk through your specific credential management and compliance requirements.