Notifications
Clear all
Topic starter
24/06/2026 7:24 pm
TL;DR: Cloud-native authentication now extends across AWS, Azure and GCP so gateway connections to services like Vault, Redis and Postgres can avoid static secrets and use IAM-based identity instead, according to Kong. That shifts the control problem from secret handling to trust-policy consistency and auditability across production systems.
NHIMG editorial — based on content published by Kong: No More Static Secrets: Kong Expands Cloud-Native Authentication Support
Questions worth separating out
Q: How should security teams replace static secrets in gateway-to-service authentication?
A: Security teams should move gateway integrations to cloud-native identity where the target system supports it, then remove hardcoded keys, shared tokens, and embedded passwords from the path.
Q: Why do static credentials create more governance risk in cloud-native architectures?
A: Static credentials create governance risk because they survive longer than the workload that uses them, spread across code, configuration, and operational exceptions.
Q: What breaks when gateway integrations use different auth patterns for each service?
A: What breaks is consistency.
Practitioner guidance
- Map every gateway integration that still uses static credentials. Inventory connections from gateways to databases, caches, and secrets managers, then classify which ones can move to cloud-native identity without breaking service dependencies.
- Separate trust policy from application policy. Review both the cloud role trust boundary and the target service policy so that neither layer silently overgrants access to the same workload identity.
- Eliminate per-integration auth exceptions. Create one approved service-identity pattern for gateway authentication across your cloud estate and require formal review before any team introduces a fallback secret.
What's in the full article
Kong's full article covers the operational detail this post intentionally leaves for the source:
- Concrete configuration examples for Kong, Vault, and AWS IAM role assumption in production
- Step-by-step policy snippets for trust relationships and Vault role bindings
- Architecture notes on how the gateway authenticates without access keys or AppRole tokens
- Implementation guidance for extending the same pattern across Postgres, Redis, and Vault
👉 Read Kong's article on cloud-native authentication support in Gateway 3.14 →
Cloud-native authentication for gateways: are static secrets still needed?
Explore further
25/06/2026 4:40 am
Static secret avoidance is now a gateway governance requirement, not a nice-to-have. Kong's article reflects a broader shift in infrastructure identity: the places where secrets were historically tolerated are becoming the weakest points in the control plane. When gateways broker access to databases, caches, and vaults, every static credential becomes a latent audit and rotation problem. Practitioners should treat gateway auth as part of core NHI governance, not an implementation detail.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Who should own lifecycle control for IAM roles used by applications?
A: Lifecycle ownership should sit with the team responsible for both the workload and the identity policy, not with a separate team that only manages the secret store. If the role, trust binding, or service policy outlives the workload change, the access path remains active longer than intended. That is a lifecycle failure, not just an authentication issue.
👉 Read our full editorial: Cloud-native authentication closes the static secret gap in Kong Gateway
