Part 2 Edge security
3 Securing north/south traffic with an API gateway
In an ideal world, the microservices developer should worry only about the business functionality of a microservice, and the rest should be handled by specialized components with less hassle.
The API Gateway and Service Mesh are two architectural patterns that help us reach that ideal.
The API Gateway pattern is mostly about edge security, while the Service Mesh pattern deals with service-to-service security. Or, in other words, the API Gateway deals with north/south traffic, while the Service Mesh deals with east/west traffic.
3.1 The need for an API gateway in a microservices deployment
3.1.1 Decoupling security from the microservice
One key aspect of microservices best practices is the single responsibility principle. This principle, commonly used in programming, states that every module, class, or function should be responsible for a single part of the software’s functionality. Under this principle, each microservice should be performing only one particular function.
Executing all these steps becomes a problem because the microservice loses its atomic characteristics by performing more operations than it’s supposed to.
The coupling of security and business logic introduces unwanted complexity and maintenance overhead to the microservice.
（1）Changes in the security protocol require changes in the microservice
（2）Scaling up the microservice results in more connections to the authorization server
3.1.2 The inherent complexities of microservice deployments make them harder to consume
3.1.3 The rawness of microservices does not make them ideal for external exposure
3.2 Security at the edge
3.2.1 Understanding the consumer landscape of your microservices
Applications running within the organization’s computing infrastructure may consume both internal-facing and external-facing microservices.
3.2.2 Delegating access
3.2.3 Why not basic authentication to secure APIs?
The username and password are static, long-living credentials.
No restrictions on what the application can do.
3.2.4 Why not mutual TLS to secure APIs?
mTLS solves one of the problems with basic authentication by having a lifetime for its certificates. The certificates used in mTLS are time-bound, and whenever a certificate expires, it’s no longer considered valid.
However, just as in basic authentication, mTLS fails to meet access delegation requirements we discussed in section 3.2.2 in a microservices deployment.
Therefore, mTLS is mostly used to secure communication between a client application and a microservice, or communications among microservices. In other words, mTLS is mostly used to secure communications among systems.
3.2.5 Why OAuth 2.0?
To understand why OAuth 2.0 is the best security protocol for securing your microservices at the edge, first you need to understand your audience. You need to figure out who wants access to your resources, for what purpose, and for how long.
3.3 Setting up an API gateway with Zuul
3.3.1 Compiling and running the Order Processing microservice
3.3.2 Compiling and running the Zuul proxy
3.3.3 Enforcing OAuth 2.0–based security at the Zuul gateway
Enforcing token validation at the zuul gateway
A filter can be one of four types :
Prerequest filter—Executes before the request is routed to the target service
Route filter—Can handle the routing of a message
Post-request filter—Executes after the request has been routed to the target service
Error filter—Executes if an error occurs in the routing of a request
Oauth2.0 token introspection profile
{
“active”: true,
“client_id”: “application1”,
“scope”: “read write”,
“sub”: “application1”,
“aud”: “http://orders.ecomm.com”
}
Self-validation of tokens without integrating with an authorization server
But the gateway component relies heavily on the authorization server to enable access to your microservices, so the gateway component is coupled with another entity.
The way to deal with this problem is to find a mechanism that enables the gateway to validate tokens by itself without the assistance of an authorization server.
JWTs are designed to solve this problem . A JSON Web Signature (JWS) is a JWT signed by the authorization server. By verifying the signature of the JWS, the gateway knows that this token was issued by a trusted party and
that it can trust the information contained in the body.
Pitfalls of self-validating tokens and how to avoid them
If one of these tokens is prematurely revoked, the API gateway won’t know that the token has been revoked, because the
revocation happens at the authorization server end, and the gateway no longer communicates with the authorization server for the validation of tokens.
In practice, however, applications with longer user sessions have to keep refreshing their access tokens when the tokens carry a shorter expiration.
Another problem with the self-contained access token is that the certificate used to verify a token signature might have expired.
To solve this problem, you need to make sure that whenever a certificate is renewed, you deploy the new certificate on the gateway.
Then the gateway can fetch the token issuer’s certificate dynamically from an endpoint exposed by the authorization server to do the JWT signature validation, and check whether that certificate is signed by a certificate authority it trusts.
3.4 Securing communication between Zuul and the microservice
3.4.1 Preventing access through the firewall
3.4.2 Securing the communication between the API gateway and microservices by using mutual TLS
But mTLS verification happens at the Transport layer of the microservice and doesn’t propagate up to the Application layer.
Summary
The API Gateway pattern is used to expose microservices to client applications as APIs.
The API gateway helps to expose microservices of different flavors by using a consistent and easy-to-understand interface to the consumers of these microservices.
We do not have to expose all microservices through the API gateway. Some microservices are consumed internally only, in which case they will not be exposed through the gateway to the outside world.
Protocols such as basic authentication and mutual TLS are not sufficient to secure APIs, and microservices are exposed to the outside world via APIs.
OAuth 2.0 is the de facto standard for securing APIs and microservices at the edge.
OAuth 2.0 is an extensible authorization framework, which has a wide array of grant types. Each grant type defines the protocol indicating how a client application would obtain an access token to access an API/microservice.
We need to choose the right OAuth 2.0 grant type for our client applications based on their security characteristics and trustworthiness.
An access token can be a reference token or a self-contained token (JWT). If it is a reference token, the gateway has to talk to the issuer (or the authorization server) always to validate it. For self-contained tokens, the gateway can perform the validation by verifying the token signature.
A self-contained access token has its own pitfalls, and one way to get around token revocation is to have short-lived JWTs for self-contained access tokens.
The communication between the gateway and the microservice can be protected with either firewall rules or mutual TLS—or a combination of both.
All samples in this chapter use HTTP (not HTTPS) endpoints to spare you
from having to set up proper certificates and to make it possible for you to
inspect messages being passed on the wire (network), if required. In production systems, we do not recommend using HTTP for any endpoint.
4 Accessing a secured microservice via a single-page application
We believe in completing an end-to-end architecture with a microservices deployment, from data to screen. And SPAs are the most used client
application type.
4.1 Running a single-page application with Angular
4.1.1 Building and running an Angular application from the source code
4.1.2 Looking behind the scenes of a single-page application
4.2 Setting up cross-origin resource sharing
4.2.1 Using the same-origin policy
URL consists of the URI scheme, hostname, and port.
The same-origin policy exists to prevent a malicious script on one website from accessing data on other websites unintentionally. The same-origin policy applies only to data access, not to CSS, images, and scripts, so you could write web pages that consist of links to CSS, images, and scripts of
other origins.
4.2.2 Using cross-origin resource sharing
Web browsers have an exception to the same-origin policy: cross-origin resource sharing (CORS), a specification that allows web browsers to access selected resources on different origins;
Web browsers use the OPTIONS HTTP method along with special HTTP headers to determine whether to allow or deny a cross-origin request. Let’s see how the protocol works.
You can observe this request, known as a preflight request, by inspecting it on the Network tab of your browser’s developer tools. The request includes the following HTTP headers:
Access-Control-Request-Headers
Access-Control-Request-Method
Origin
The server responds to this preflight request with the following headers:
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
Access-Control-Allow-Methods
Access-Control-Allow-Origin
Access-Control-Max-Age
4.2.3 Inspecting the source that allows cross-origin requests
@CrossOrigin(origins = “http://localhost:4200”)
4.2.4 Proxying the resource server with an API gateway
4.3 Securing a SPA with OpenID Connect
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0.
4.3.1 Understanding the OpenID Connect login flow
{
“access_token”:”92ee7d17-cfab-4bad-b110-f287b4c2b630″,
“token_type”:”bearer”,
“refresh_token”:”dcce6ad7-9520-43fd-8170-a1a2857818b3″,
“expires_in”:1478,
“scope”:”openid”
}
4.3.2 Inspecting the code of the applications
4.4 Using federated authentication
4.4.1 Multiple trust domains
4.4.2 Building trust between domains
Summary
Single-page applications perform better by reducing network chattiness as they perform all rendering on the web browser and by reducing the workload on the web server.
The SPA architecture brings simplicity to microservices architectures because they do not require complex web application-hosting facilities such as JBoss or Tomcat.
The SPA architecture abstracts out the data layer from the user experience layer.
SPAs have security restrictions and complexities due to the same-origin policy on web browsers.
The same-origin policy ensures that scripts running on a particular web page can make requests only to services running on the same origin.
The same-origin policy applies only to data access, not to CSS, images, and
scripts, so you can write web pages that consist of links to CSS, images, and scripts of other origins.
OpenID Connect is an identity layer built on top of OAuth 2.0. Most SPAs
use OpenID Connect to authenticate users.
Because SPAs may consume APIs (data sources) from multiple trust domains, a token obtained from one trust domain may not be valid for another trust domain. We need to build token-exchange functionality when a SPA hops across multiple trust boundaries.
All samples in this chapter used HTTP (not HTTPS) endpoints to spare you
from having to set up proper certificates and to make it possible for you to
inspect messages being passed on the wire (network), if required. In production systems, we do not recommend using HTTP for any endpoint.
5 Engaging throttling, monitoring, and access control
5.1 Throttling at the API gateway with Zuul
5.1.1 Quota-based throttling for applications
5.1.2 Fair usage policy for users
5.1.3 Applying quota-based throttling to the Order Processing microservice
5.1.4 Maximum handling capacity of a microservice
5.1.5 Operation-level throttling
5.1.6 Throttling the OAuth 2.0 token and authorize endpoints
5.1.7 Privilege-based throttling
5.2 Monitoring and analytics with Prometheus and Grafana
The modern term for monitoring and analytics is known as observability.
Prometheus is a popular open source monitoring tool for microservices. It helps us keep track of system metrics over a given time period and can be used to determine the health of a software system. Metrics include memory usage and CPU consumption.
Grafana is an open source data visualization tool. It can help you build dashboards to visualize the metrics being provided by Prometheus or any other data source. At this time of writing, Grafana is the most popular data-visualizing tool in the market.
5.2.1 Monitoring the Order Processing microservice
As you can see, Grafana gives you a much more user-friendly view of the metrics exposed by the Order Processing microservice.
5.2.2 Behind the scenes of using Prometheus for monitoring
5.3 Enforcing access-control policies at the API gateway with Open Policy Agent
The API gateway here is acting as a policy enforcement point. OPA is a lightweight general-purpose policy engine that has no dependency on microservices. You can use OPA to define fine-grained access-control
policies and enforce those policies at different places in a microservices deployment.
5.3.1 Running OPA as a Docker container
5.3.2 Feeding the OPA engine with data
5.3.3 Feeding the OPA engine with access-control policies
5.3.4 Evaluating OPA policies
5.3.5 Next steps in using OPA
Summary
Quota-based throttling policies for applications help to monetize APIs/microservices and to limit a given application from overconsuming APIs/microservices.
Fair-usage policies need to be enforced on applications to ensure that all users get a fair quota of requests.
User privilege-based throttling is useful for allowing different quotas for users with different privilege levels.
An API gateway can be used to apply throttling rules in a microservices
deployment.
Prometheus is the most popular open source monitoring tool available as of this writing.
Grafana helps to visualize the data being recorded by Prometheus.
Open Policy Agent (OPA) helps control access to a microservices deployment.
OPA data, OPA input data, and OPA policies are used together to apply various access-control rules.
All samples in this chapter used HTTP (not HTTPS) endpoints to spare you
from having to set up proper certificates and to make it possible for you to
inspect messages being passed on the wire (network), if required. In production systems, we do not recommend using HTTP for any endpoint.