...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
On this page.
| Table of Contents |
|---|
Introduction
Microservice architecture consists of a suite of independently deployable, small, modular, and compassable (composable) services. Each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.
In addition to modular services, the API gateway and other elements are integral parts of microservice architecture.
...
What and Why of API Gateways
Basically, the API Gateway is a reverse proxy to microservices and acts as a single-entry point into the system. It is similar to a Facade pattern from object-oriented design and similar to the notion of an “Anti-Corruption Layer” in Domain Driven Design.
...
With a single-entry point into the system (references), it becomes easy (and manageable) to enforce runtime governance such as common security requirements, common design decisions (e.g. every consumer of the service should have X-Correlation-ID header), and real-time policies such as monitoring, auditing and measuring API usage, and throttling.
Security
Authentication and Authorization
Federated identity is the preferred solution for implementing authentication and authorization in microservice architecture. Each microservice does not necessarily need to obtain and store users’ credentials in order to authenticate them. Instead, microservices can use an identity management system that is already storing a user’s identity to authenticate the user. This approach allows the decoupling of the authentication and authorization functions. It also makes it easier to centralize these two functions, to avoid a situation where every service must manage a set of credentials for every user.
There are three major protocols for federated identity: OpenID, SAML, and OAuth.
Every API request is authenticated at the gateway layer.
On behalf of the end user, the application client first grabs an access token from the authentication server by presenting credentials. This access token is then passed along with the API request in Authorization HTTP header. The API Gateway then validates the access token with the authorization server. The JWT token, which contains the claims for the user, is then passed to backend microservices. Backend microservices then use the information inside the JWT token for authorization purpose. The same JWT token is passed along when one microservice communicates with another microservice.
| Note |
|---|
Ideally, every microservice should authenticate the token as received from its caller (gateway or microservice). There is a trade-off between security and performance. |
Threat Protection from DDoS
Most of the API Gateway provides (either integral or addon packages) features that can handle DDoS attacks, by regulating and controlling the traffic as it proceeds to backend microservices. Consider configuring the following traffic regulating parameters for the API Gateway:
Limiting the rate of requests: Maximum number of requests an API can access within a given time frame, based on rate limiting approach. Some of the approaches are Authenticated User, Request Origin, Authenticated User, and Request Origin. For example, you might decide that an API may be accessed only once a day, by an authenticated user from a specific mobile application.
Limiting the number of connections: Maximum number of connections that can be opened by a single client for an API.
Closing slow connections: Time span, after which a connection will be closed from a client that is writing data too infrequently, which can represent an attempt to keep connections open as long as possible.
Black list / White list IP addresses, if you can definitely identify valid and invalid end users of your APIs.
Limiting the connections to backend microservices.
Blocking requests: o that seem to target a specific API o that have a User-Agent header, set to a value that does not correspond to normal client traffic o that have a referrer header, set to a value that can be associated with an attack o that have other headers with values that can be associated with an attack
Secure Communication
It is always desirable to have SSL/TLS compliant endpoints at the API Gateway, as well as at the microservices layer, to safeguard against man-in-middle attacks, and bi-directional encryption of message data to protect against tampering.
| Info |
|---|
If you are dealing with a number of certificates, then managing those becomes a huge administrative burden. There are solutions like http://letsencrypt.org , an certificate manager, which makes it possible to transparently issue or revoke certificates. |
Deployment Considerations
To strengthen security further, you should host all microservices on private subnet and whitelist the gateway IP at the microservices layer.If it is not possible to have microservices on private subnet, then you should validate each token with the authorization server per service call, however, this will impact performance.
Service Registry and Service Discovery
Ease in scaling is one of the key advantage of microservice architecture. Service instances have dynamically assigned network locations.
Service Registry
It helps to keep track of these instances. It is a database containing the network locations of the service instances. Every service instance registers itself on start-up and de-registers on shutdown. The API Gateway uses this information during service discovery.
...
There are two models for checking the status of a service: pull model and push model. Although some of the registries support the pull model, it is not recommended, as it puts an additional load on the registry. Moreover, it is the service’s responsibility to update the registry about its availability/ unavailability to serve the request.
The service registry needs to be highly available. You should plan for a cluster of registries that uses replication to maintain consistency. Never try to cache the network locations obtained from the registry at the registry user (API Gateway or registry aware client). That information eventually becomes out-of-date, causing clients to become unable to discover service instances.
Service Discovery
….