A Kubernetes custom resource that defines vault-backed secret access for Kong Gateway. It connects Gateway to external secret stores such as cloud key management systems or HashiCorp Vault, so sensitive values can be injected at runtime instead of stored directly in application manifests.
KongVault CRD in Kong Gateway
KongVault CRD is the Kubernetes-native layer that tells Kong Gateway how to resolve sensitive values from an external vault at runtime. It shifts secret retrieval out of manifests and into a controlled secret-access path, which reduces static exposure while preserving application behavior.
Because the CRD sits between the gateway and the backing secret store, it becomes part of the trust boundary for configuration delivery. The operational question is not just whether the secret exists, but whether Kong can fetch the right value, from the right source, at the right time, without widening access.
How the CRD changes secret handling
Traditional Kubernetes configuration often bakes credentials into environment variables, values files, or mounted material that can linger in Git history, images, or cluster state. KongVault CRD changes that pattern by treating secret material as external dependency data rather than as embedded application configuration.
That design is useful when the secret store is already the system of record, such as a cloud key management service or HashiCorp Vault. The manifest describes intent, while the runtime resolution step provides the value, which helps keep secret distribution aligned with central rotation and revocation workflows. For a related control perspective, OWASP Non-Human Identity Top 10 is useful when you are thinking about secret sprawl, overprivilege, and lifecycle exposure around machine-to-machine access.
Where KongVault CRD fits in the Kubernetes secret lifecycle
The CRD is most valuable when the platform team wants declarative secret references but the security team wants centralized ownership of the actual secret values. In practice, it introduces dependency on the vault’s availability, the correctness of the reference, and the gateway’s ability to authenticate to the secret backend.
This pattern also changes failure modes. A missing secret is no longer just a configuration typo, it can become a startup or routing failure. A mis-scoped reference can expose the wrong secret class to the wrong gateway route, and a stale reference can break deployments even when the application image itself is healthy. The mechanism is therefore as much about configuration integrity as it is about confidentiality.
For the cryptographic side of that lifecycle, NIST SP 800-57 Key Management is the clearest external reference when runtime secret delivery depends on disciplined rotation, cryptoperiods, and key stewardship.
Security implications for runtime access and trust
KongVault CRD narrows static exposure, but it does not remove risk. The gateway still needs a trustworthy path to the vault, and that path must be limited to only the secrets and operations the deployment actually requires. If access is broader than necessary, the CRD can become a convenient bridge from a relatively small compromise to a much larger set of retrieved credentials.
That makes access control, authentication, and auditability part of the security story. In environments where the CRD resolves multiple secret classes, the main concern is not only leakage of the stored value, but also abuse of the retrieval mechanism itself. Framework guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-207 Zero Trust Architecture both reinforce the need to bound access paths and verify each request rather than assuming the gateway context is inherently safe.
Operational patterns and deployment trade-offs
The main trade-off is convenience versus dependency. External secret injection improves separation of duties and rotation, but it also makes the gateway dependent on the vault service, its network path, and the correctness of the CRD configuration. Teams using the pattern should expect to test secret resolution during rollout, failover, and certificate or token rotation events.
It is also important to distinguish between a Kubernetes resource that references secrets and a broader API security problem. The CRD is not about API payload validation or request authorization at the edge, although those controls still matter around Kong Gateway. For gateway and API control alignment, OWASP API Security Top 10 is the most directly relevant external reference when the deployment exposes secret-backed services through APIs.
Risk and Threat Considerations
KongVault CRD reduces the blast radius of static secret storage, but it also concentrates value in the secret-retrieval path. If the gateway’s vault access is overprivileged, compromised, or misrouted, an attacker can pivot from one runtime request to broader secret exposure, configuration tampering, or service disruption.
Failure mechanism: The CRD, gateway credentials, and vault policy can fail as a linked chain, so a mistake in any one layer can expose secrets, break service startup, or allow retrieval of data outside the intended trust boundary.
Impact: The result can be credential theft, unauthorized access to downstream systems, or availability loss if secret resolution fails during deployment or rotation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57, NIST Zero Trust (SP 800-207) and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | KongVault CRD externalizes secret material and changes where leakage can occur. |
| NHI-05 — Overprivileged NHI | Gateway-to-vault access is a non-human secret access path that must stay least-privileged. | |
| Recommendation — Keep vault-backed values out of manifests and limit secret exposure to runtime retrieval. Scope gateway secret retrieval to the minimum vault paths and operations required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runtime secret injection depends on the lifecycle of credentials, tokens, and related authenticators. |
| AC-6 — Least Privilege | The gateway should only retrieve the specific secrets it needs from the backend store. | |
| AU-2 — Event Logging | Secret retrieval and access failures should be logged for detection and investigation. | |
| Recommendation — Rotate and protect the authenticators used for vault access on a defined lifecycle. Restrict vault permissions to the smallest set of secret paths and actions. Log vault access events and review retrieval failures or unexpected access patterns. | ||
| NIST SP 800-57 | Key Management | The term depends on disciplined handling of vault-managed cryptographic and secret lifecycles. |
| Recommendation — Align secret and key rotation with defined cryptoperiods and retirement rules. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The gateway-to-vault path should be continuously verified rather than implicitly trusted. |
| Recommendation — Verify each vault access request and constrain trust to the specific runtime context. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Declarative secret references become part of the deployment supply path for runtime configuration. |
| Recommendation — Treat secret resolution inputs as part of the protected deployment supply chain. | ||
Practitioner Guidance
Governance implication: Treat the CRD as a controlled secret-access interface, not just a configuration convenience. Ownership should span platform engineering, application operators, and whoever governs the backing secret store, because the security outcome depends on all three.
What to watch for: Watch for wide vault policies, unmanaged secret references, and rollout failures that only appear when runtime resolution occurs. If a gateway can retrieve more than the intended secret set, the deployment has crossed from convenience into privilege expansion.
