Cloud-native authentication closes the static secret gap in Kong Gateway

At a glance

What this is: Kong argues that its Gateway 3.14 authentication model removes per-integration static secrets by using cloud-native identity across major clouds and connected services.

Why it matters: For IAM teams, this matters because gateway-to-service authentication is a common place where static credentials reappear, creating hidden NHI governance risk across cloud estates.

👉 Read Kong's article on cloud-native authentication support in Gateway 3.14

Context

Static credentials remain a stubborn governance gap in cloud-native architectures because they create separate trust paths for each integration. In practice, that means the gateway, database, cache, or secrets manager may all use different authentication patterns, which weakens identity consistency across NHI and infrastructure programmes.

Kong's article is about replacing those integration-specific exceptions with a cloud-native identity model that can be applied across AWS, Azure, and GCP. The operational question for practitioners is not whether gateways can authenticate, but whether the programme can keep every service-to-service connection inside the same identity and audit model.

Key questions

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. The priority is to make the gateway prove its identity through temporary, scoped credentials and signed requests rather than reusable secrets. That reduces leakage risk and makes audit trails more reliable.

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. Once one integration keeps a reusable secret, rotation becomes manual, audit evidence fragments, and the same pattern tends to be copied elsewhere. Over time, the programme inherits hidden NHI sprawl.

Q: What breaks when gateway integrations use different auth patterns for each service?

A: What breaks is consistency. Mixed authentication patterns make it harder to enforce least privilege, harder to compare audit logs, and harder to prove which integrations are still using temporary identity versus lingering static secrets. That unevenness is often the real failure mode, because it creates exceptions that no one can govern at scale.

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.

Technical breakdown

Cloud-native authentication in gateway-to-service paths

Cloud-native authentication means a service proves its identity using the cloud provider's native identity system instead of sending a reusable password or access key. In Kong's example, the gateway uses IAM roles and STS to obtain temporary credentials, then signs a request that Vault verifies independently. That removes a long-lived secret from the connection path and replaces it with a signed identity assertion. The architecture matters because the gateway is often the choke point for many upstream and downstream services, so one flawed pattern can replicate widely.

Practical implication: inventory every gateway integration that still depends on static secrets and replace them with provider-native identity where the target service supports it.

Why IAM roles change the trust model for secrets managers

When a gateway authenticates to a secrets manager through IAM, the trust relationship shifts from shared knowledge of a secret to verification of a caller's role and scope. Kong's described flow uses an EC2 instance profile, STS role assumption, and Vault role binding to prove identity without transmitting a password. That creates two independent control points: the cloud trust policy and the application policy inside Vault. The result is not just less secret sprawl, but a narrower and more inspectable trust chain.

Practical implication: align cloud trust policies and application policy bindings so the same integration cannot be over-permitted in one layer and under-governed in another.

Consistency across AWS, Azure and GCP avoids policy drift

The main governance problem Kong is addressing is not authentication itself, but authentication inconsistency. When each integration requires a different fallback, teams accumulate exceptions: one service uses a token, another a hardcoded key, and a third a provider-specific identity flow. Over time, that creates policy drift, uneven auditing, and uneven rotation practices. A consistent pattern across clouds reduces the temptation to accept the least secure available option for each pairing, which is where many NHI failures begin.

Practical implication: standardise a single service identity pattern for gateway integrations and reject one-off exceptions unless there is a documented technical constraint.

NHI Mgmt Group analysis

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.

Identity consistency across integrations is the real control objective. The article shows why isolated improvements are not enough. A single cloud-native auth pattern has more value than a handful of local fixes because it reduces policy drift across environments, services, and teams. That matters for large IAM programmes where the failure mode is rarely one bad secret, but a growing patchwork of exceptions that no one can govern cleanly.

Gateway authentication is a lifecycle problem as much as an access problem. Temporary credentials solve one part of the issue, but lifecycle discipline still matters for IAM roles, trust policies, and service bindings. If the role persists after the workload changes, the control gap simply moves from secret exposure to stale authorization. The implication is that identity lifecycle management must extend to machine-to-machine pathways, not stop at human accounts.

Cloud-native authentication narrows blast radius, but only if the surrounding policy model is equally disciplined. Temporary credentials and signed requests reduce exposure, yet the effective boundary is still defined by trust policy, role scope, and Vault policy. If those layers are broader than the workload requires, the programme has only replaced one kind of overreach with another. Practitioners should align identity scope with the actual service relationship, not the convenience of the deployment.

From our research:

• 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.
• For the broader governance picture, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that reduce standing access.

What this signals

Kong's direction points to a wider programme signal: gateway authentication is moving into the same governance conversation as NHI lifecycle and workload identity. With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, the issue is no longer theoretical.

Identity consistency debt: this is the accumulation of one-off auth exceptions across services, clouds, and control planes. Once that debt exists, every new integration can reintroduce the same static-secret pattern unless teams enforce a common identity model and lifecycle discipline.

For practitioners, the next step is to treat service authentication reviews as part of IAM governance, not platform housekeeping. The operational benchmark is whether each workload can authenticate without a reusable secret and whether the resulting trust chain is short enough to audit end to end.

For practitioners

• 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.
• Extend lifecycle reviews to workload roles. Verify that IAM roles, Vault bindings, and service trust relationships are removed or tightened when the workload, environment, or owning team changes.

Key takeaways

• The real problem is not gateway authentication itself, but the persistence of static secrets in service-to-service paths.
• Consistent cloud-native identity across integrations improves auditability, but only if trust policies and role bindings stay tightly scoped.
• IAM teams should review gateway and workload roles as lifecycle assets, because stale trust relationships become the next hidden access risk.

Key terms

• Cloud-native authentication: An authentication pattern that uses the cloud provider's native identity primitives instead of shared passwords or API keys. For machine identities, this usually means temporary, scoped credentials and signed requests that can be validated independently by the target service.
• Static secret: A long-lived credential such as a password, token, access key, or certificate that remains usable until someone rotates or revokes it. In machine identity programmes, static secrets create hidden exposure because they outlive the workload and are often copied into code, config, or automation.
• Trust policy: The rule set that defines which identities are allowed to assume or use a role. For workload identity, the trust policy is critical because it determines who can enter the authentication path before any application-level permission is evaluated.
• Workload identity: The identity assigned to a non-human system such as an application, service, container, or gateway. It lets the workload authenticate and authorise itself without relying on human credentials, but it still needs lifecycle control, least privilege, and clear ownership.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: No More Static Secrets: Kong Expands Cloud-Native Authentication Support. Read the original.