Apigee X Northbound Mutual TLS using External Application Load Balancer

Google Cloud Apigee Knowledge Hub
,
1

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

kurtkanaskie_0-1697809926819.png
kurtkanaskie_0-1697809926819.png575×211 14.7 KB

XLB with mTLS

kurtkanaskie_1-1697809948900.png
kurtkanaskie_1-1697809948900.png576×344 24.6 KB

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.

Mastered mTLS? Now, secure your AI agent ecosystem.

The journey to enterprise security is ongoing. Join Google Cloud experts to learn how Apigee is redefining security for the next wave of innovation: AI agent integration, development, and governance.

  • New York City: September 16

  • Chicago: September 18

  • Sunnyvale: October 8

Join the Roadshow!

2

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.

3

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

4

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

5

Can MTLS be done without XLB? I am trying to connect Apigee behind another service.

6

To enable mutual TLS for Apigee with Xlb create a Private CA set up a Trust Configuration and apply a Server TLS Policy Update the Xlb Target Https Proxy and Backend Service to handle mTLS Choose between strict or lenient enforcement as needed.

7

Hi @amitkhosla ,

Re: Can MTLS be done without XLB? I am trying to connect Apigee behind another service.

Yes, you can configure mTLS on any of the application load balancers.

See docs here: https://cloud.google.com/load-balancing/docs/mtls

8

What if we want to whitelist certain consumers by IP and allow others only via mTLS? Can we implement this security logic directly within the same XLB (mtls + ip whitelisting) ?

9

Re: What if we want to whitelist certain consumers by IP and allow others only via mTLS? Can we implement this security logic directly within the same XLB (mtls + ip whitelisting) ?

Not in the XLB alone, you can whitelist IPs using Cloud Armor but that will block all others.

You could configure lenient mTLS in the XLB and use Apigee’s Access Control policy in your proxies. In your proxy or shared flow, you would configure the Access Control policy to allow whitelisted IPs and set it to continue on error. Then use a Condition to Raise Fault if Access Control policy failed is true and request.header.x-client-cert-chain-verified is false.

Example Access Control policy:

<AccessControl continueOnError="true" enabled="true" name="AC-allow">
  <IPRules noRuleMatchAction="DENY">
    <MatchRule action="ALLOW">
      <SourceAddress mask="32">131.106.40.233</SourceAddress>
    </MatchRule>
  </IPRules>
  <ValidateBasedOn>X_FORWARDED_FOR_FIRST_IP</ValidateBasedOn>
  <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
</AccessControl>

Condition to Raise Fault:

<PreFlow name="PreFlow">
  <Request>
    <Step>
      <Name>AC-allow</Name>
    </Step>
    <Step>
      <Condition>(acl.AC-allow.failed == "true") AND (request.header.x-client-cert-chain-verified == "false")</Condition>
      <Name>RF-mtls</Name>
    </Step>
  </Request>
  <Response>
    <Step>
      <Name>AM-response</Name>
    </Step>
  </Response>
</PreFlow>

Hope that helps.