Notifications
Clear all
Topic starter
24/06/2026 8:55 pm
TL;DR: Microservices multiply API endpoints, authentication paths, and internal trust relationships, while traditional perimeter tools miss shadow APIs and east-west traffic, according to Kong. The result is a governance problem as much as a technical one: identity, access, secrets, and observability controls must be designed for distributed execution rather than monolithic assumptions.
NHIMG editorial — based on content published by Kong: 10 Ways Microservices Create New Security Challenges
By the numbers:
- Attacks targeting the business logic of APIs constituted 27% of attacks in 2023, a 10% growth since the previous year.
Questions worth separating out
Q: How should security teams govern APIs in microservices environments?
A: Security teams should govern APIs as a continuously changing identity surface, not as a fixed application perimeter.
Q: Why do microservices increase lateral movement risk?
A: Microservices increase lateral movement risk because one service compromise can expose internal trust relationships, shared secrets, and downstream permissions.
Q: What do teams get wrong about Kubernetes Secrets?
A: Teams often treat Kubernetes Secrets as if they are secure by default, but base64 encoding is not encryption and cluster access can expose them.
Practitioner guidance
- Build a continuous API inventory Automate endpoint discovery across all environments and tag each route with ownership, data sensitivity, and business criticality so shadow APIs can be removed or governed quickly.
- Enforce explicit east-west authentication Require mTLS and service identity validation for every internal call, and block any default trust between workloads in the same cluster or namespace.
- Centralise secrets lifecycle control Move service credentials, API keys, and certificates into a managed lifecycle with rotation, revocation, and audit logging tied to service ownership.
What's in the full article
Kong's full blog covers the operational detail this post intentionally leaves for the source:
- Endpoint-by-endpoint mitigation guidance for microservices architectures
- Examples of API gateway, service mesh, and OPA policy patterns in practice
- Configuration and secrets management recommendations for Kubernetes environments
- Additional data points from industry research on API attack trends
👉 Read Kong's analysis of 10 microservices security challenges →
Microservices security gaps: what IAM and API teams need to know?
Explore further
25/06/2026 5:48 am
Microservices security is an identity governance problem before it is a tooling problem. The article correctly shows that endpoint growth, internal trust, and secrets sprawl all expand faster than manual controls can track. That means the real failure mode is not just exposure, but the absence of a governance model that can keep pace with distributed execution. Practitioners should treat microservices as a lifecycle and access-control challenge, not only an infrastructure pattern.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: How do organisations know if their microservices controls are working?
A: The clearest signal is whether every active endpoint is inventoried, every internal call is authenticated, and every credential has a known owner and rotation path. If teams cannot answer those three questions quickly, governance is incomplete and the environment contains unmanaged exposure.
👉 Read our full editorial: Microservices security gaps are exposing API sprawl and shadow APIs
