Apigee X Northbound Mutual TLS using External Application Load Balancer

[kurtkanaskie]

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.

1. Create Private CA
   1. Create Private Certificate Authority pool, “root” CA(s) and client certificates.
   2. Create Trust Configuration for the “root” CA(s).
   3. Create Server TLS Policy using the Trust Configuration.
2. Update existing XLB
   1. Update the XLB Target HTTPS Proxy to use the Server TLS Policy.
   2. 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.

[rani123]

Hi, Enabling SSL from Northbound traffic is still not clear on the configurations to be done.Can someone help me with step by step process to be followed for the same.Thanks in advance.

[kurtkanaskie]

What part of the Apigee Samples Mutual TLS Northbound Security hands-on step-by-step guide are you having problems with?

[DineshMannam]

Hello, 

Thanks for putting this together, is there a similar documentation in the context of apigee Hybrid, I'm trying to understand what happens when we enable mTLS by adding TLSMode : MUTUAL in the virtual hosts stanza of overrides file.

Thank you