Centralised API security for microservices on a container platform

Context

In banking, strict security and regulatory requirements make identity and access management a critical part of any microservices architecture. A Kubernetes-based container platform gives teams scale and speed, but the security controls still have to sit at the right layer of the architecture.

The bank ran its microservices on such a platform, and each service handled authentication and authorisation itself, through its own integration with a custom identity and access management (IAM) solution. With security spread across application code, central control was difficult and unauthorised traffic could not be stopped early. As the number of microservices grew, the approach became harder to scale and to maintain.

The constraints

• Authentication and authorisation logic embedded directly in application code
• No central inspection of traffic before requests reached the container platform
• IAM implemented differently in each microservice, with the risk of security policies drifting apart
• Operational overhead that grew with every new microservice
• No clear line between the security responsibilities of the platform team and those of the application teams

Our approach

1. A gateway outside the cluster. The API gateway was deployed on a virtual machine, independent of the container platform, so that the security controls sat apart from the platform they protect.
2. Tied to the bank’s identity provider. The gateway was integrated with the bank’s existing identity provider and validated OAuth 2.0 tokens against it.
3. All inbound traffic through one point. Traffic to the microservices was routed through the gateway at the network level, and every service was placed behind it.
4. Access rules defined once. Authentication and authorisation controls were defined centrally, in the gateway’s policy layer, instead of in each service.
5. Refused before the platform. Unauthorised or malformed requests were rejected at the gateway and never reached the container platform.
6. Security code out of the services. The custom IAM integration code in each service was removed. The business logic was not touched, and the services were left to do only that.

The result

All inbound traffic was authenticated and authorised at the gateway before it reached the cluster, so security was enforced at a single, consistent control point. Unauthorised access was blocked before the container platform, and the cluster’s external attack surface was removed.

Moving the IAM integration out of each microservice simplified the services and centralised the security policies: a new security requirement can now be applied to every service at once, from one place. Because every access is recorded at the gateway, security became easier to manage and to audit, and the development teams went back to building application logic.