Spring Cloud Gateway for VMware Tanzu was released January 2020 as a service on Tanzu Application Service (TAS) and was quickly deployed into production by many of our customers. Our focus is to offer the most developer-friendly API gateway experience while still providing the operational configuration, security and governance needed for successful enterprise management. As of today, we’ve made progress in enhancing Spring Cloud Gateway on TAS and are announcing an early-access beta for Spring Cloud Gateway on Kubernetes.
Based on the feedback we’ve received, customers are attaining significant results, such as reduced duplication of cross-cutting concerns like Single Sign-On (SSO) and securing access to their APIs. If you’d like to try it yourself on TAS today, install the Spring Cloud Gateway for VMware Tanzu tile and take it for a spin with our Animal Rescue sample application.
In subsequent releases, Spring Cloud Gateway for VMware Tanzu has matured to support client certificate authorization, cross-origin resource sharing, configuring header size and timeout limits, and supporting TAS security features. Read on for more detail.
Client Certificate Authorization (mTLS)
For security-conscience application topologies that require mutual authentication (mTLS), Spring Cloud Gateway needs to authorize incoming client certificates and also forward it to the application that is responding to the request. TAS provides options for forwarding client certificates to applications. A gateway service instance is ultimately a Spring Boot application running in a managed space on TAS. Therefore, once TAS is enabled to forward client certificates, then the gateway can authorize access to API routes based on it.
An API route can be configured to authorize access based on client certificate by adding the ClientCertificateHeader filter. This filter requires the certificate’s common name and also takes an optional parameter to validate the fingerprint. Here is a simple example:
{
“routes”: [
{
“path”: “/my/secure/api”,
“filters”: [
“ClientCertificateHeader=my.secure.domain.com,sha-256:aa:bb:…”
]
}
]
}
Now any request to /my/secure/api on the gateway will authorize the client certificate before forwarding the request, including the client certificate itself, to the application that is responding to this API path.
Cross-Origin Resource Sharing (CORS)
It is common for APIs to be consumed by applications that are served from a different origin domain. For security reasons, browsers follow the same-origin policy to restrict such access by default. The CORS standard was developed for APIs to allow access from other origins based on specified criteria. Gateway instances can now be configured with CORS properties.
To show an example, let’s say that an application at https://coolsite.com wants to use an API on our gateway, named our-gateway, at https://api.mycooldomain.com from a JavaScript function. If the gateway has no CORS properties configured, the browser will not allow the request to be made and will show an error, like:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at api.mycooldomain.com.
To allow requests to our-gateway from coolsite.com, we can update our gateway with the following configuration:
$ cf update-service our-gateway -c ‘{ “cors”: { “allowed-origins”: [ “https://coolsite.com” ] } }’
Now the requests from https://coolsite.com can be allowed by the browser.
Set Maximum HTTP Header Size
There are situations where HTTP request header size needs to be verified. As an example, some marketing email tools could have links back to a gateway path and include many additional headers for tracking information. In this case you would want to increase beyond the default maximum header size of 8KB. You can now set the maximum header size for all HTTP requests to a gateway service instance. This can be done by setting the max-header-size property.
$ cf update-service mygateway -c ‘{“max-header-size”: “32k”}’
With the above configuration, requests with a header larger than 32KB will receive an HTTP 431 response code with message Request Header Fields Too Large.
Set Request and Response Timeout Limits
A gateway instance may be configured to handle requests to resources off-platform. Depending on the environment, this could lead to latency and connection timeouts when handling a request. There are now configuration parameters to control the timeouts for routing HTTP requests to applications that are responding to the request. The request-timeout-ms property sets the timeout duration in milliseconds before a connection is established with an application responding to the requested gateway route. The response-timeout-ms property sets the timeout duration in milliseconds for the application to respond to the gateway request. Following is an example command setting these properties:
$ cf update-service mygateway -c ‘{“request-timeout-ms”: 5000, “response-timeout-ms”: 10000}’
In this example, the request timeout would be set to 5 seconds and the response timeout is 10 seconds.
Application Security Groups
Tanzu Application Service provides an option to set outbound network traffic rules via a concept called Application Security Groups. These outbound rules can be applied to a specific space where applications are running. An example use case for using Application Security Groups with a gateway instance is when an API route is configured to an application that is running off-platform in its own virtual machine (VM). We may not want all spaces defined in a TAS foundation to have access to this off-platform application and so we want to restrict the outbound access to it. An administrator can create an Application Security Group and give it a name such as off-platform-app. To apply the off-platform-app outbound rules to a gateway instance, you can add it to the application-security-groups array:
$ cf update-service mygateway -c ‘{“application-security-groups”: [“off-platform-app”]}’
This will allow requests to mygateway routes to be handled by the application running off-platform in its own VM. This is being used by customers today as a way to apply the Strangler pattern to incrementally migrate a legacy monolithic application to a microservices architecture.
Isolation Segments
The concept of isolation segments describes a way to isolate deployment workloads to separate resource pools in TAS. This means that the applications deployed to a space that is part of a specified isolation segment will be deployed to a separate resource pool from other applications using the default resource pool. Isolation segments can also be configured to isolate network traffic routing from the default TAS resource pool. This can be used to handle a separate network domain and range of IP addresses.
To take advantage of isolation segments on a gateway instance, they can be configured by adding the name of the isolation segment to the property array:
$ cf update-service mygateway -c ‘{“isolation-segments”: [“other-isoseg”]}’
Now this gateway instance is able to route traffic to other applications deployed into the other-isoseg isolation segment in entirely separate resource pools and networks.
The Road Ahead
Spring Cloud Gateway for VMware Tanzu will continue to enhance the developer experience on Tanzu Application Service. But we aren’t stopping there. Developers are looking for a comparable experience on Kubernetes, too. And they are looking for richer API management capabilities to interact with any number of deployed gateway instances. We’re currently running a beta early-access program for Spring Cloud Gateway on Kubernetes and additional API management features.
