LinkedIn
Twitter
Apigee is a platform for developing and managing API proxies that often requires the use of mutual TLS for northbound (Client --> Apigee) connections. There is an existing solution for mTLS using a TCP Load Balancer with Envoy Proxy backend. This solution provides an overview of the steps required to configure an External Application Load Balancer (XLB) for mTLS.
For a complete step-by-step guide and Cloud Shell tutorial with a sample API Proxy, see the Apigee Samples repository reference for Mutual TLS Northbound Security.
Architecture
Basically, mTLS is an "addon" configuration to an existing XLB, you don't need another XLB and you can still use the same hostname.
XLB without mTLS
XLB with mTLS
About mTLS on XLB (GA 2023-10-03)
GCP's mTLS support applies to both the external Application Load Balancer and the classic Application Load Balancer, the steps are the same. You can set up mutual TLS with user-provided certificates or with a private CA. You can also enforce mTLS "strictly" or "leniently" by allowing missing or invalid certificates. In the later case, the backend is responsible for rejecting the request, in this case, that will be the Apigee proxy.
Implementation on Apigee
There are no Apigee specific configuration steps, all that is required is to access the custom header values populated in the XLB configuration. The sample Apigee proxy (sample-mtls) is a simple no target proxy with an Assign Message policy that will extract the custom request header values and return them in a JSON response. It also has a RaiseFault policy that is used to reject requests when mTLS is not strictly enforced in the XLB.
Implementation on GCP XLBs
Adding mTLS is done on an existing XLB configuration setup for Apigee external access. No changes are required to the existing certificates used for API TLS termination and the existing hostname(s) can still be used.
Configuration options allow mTLS to be either enforced "strictly" or "leniently" by allowing invalid or missing certificates. In either case, custom header values are populated and made available to the API proxy.
- Strict enforcement happens at the load balancer and invalid connections will be rejected. In this case the XLB logs can be used to view connection errors for details.
- Lenient enforcement happens in the API proxy flow. In this case, the proxy must use Conditions on the custom header values and a RaiseFault policy to reject the request.
These are the high level tasks to configure mTLS on an existing XLB configuration.
- Create Private CA
- Create Private Certificate Authority pool, “root” CA(s) and client certificates.
- Create Trust Configuration for the “root” CA(s).
- Create Server TLS Policy using the Trust Configuration.
- Update existing XLB
- Update the XLB Target HTTPS Proxy to use the Server TLS Policy.
- Update the XLB Backend Service to add custom headers for the TLS variables.
It's that simple, the nice thing is that you can operate the XLB in a "dual" mode, supporting both mTLS and TLS connections, the choice is yours.
Next step: Head on over to the Apigee Samples Mutual TLS Northbound Security reference for a hands-on step-by-step guide and CloudShell tutorial.
