Apigee X: 2 Way SSL Authentication for API proxies

[LuckyEK]

Objective: I want to set up MTLS for our API proxies so API consumers can connect via our APIs on Apigee X.

From my research in different forums and docs, we understand that MTLS  Northbound for Apigee X must be handled at the Load balancer (strict or lenient mode).

To restrict certain partners and validate we must manage their certificates on our platform, also I do not want to allow any self-sign certificate and only allow public CAs' certs

Questions:

1. Where can we manage different API consumer certificates (in the trust config's allowList certificate or Apigee KVM)?
2. Do we need to add an intermediate certificate for the API consumers?
3. How can we validate if the cert exists before allowing users to call the API proxies, can this be done at the proxy level or LB
4. If at the proxy level, what policies shall we use to extract SSL info and ensure it is not expired or from invalid Certs?

This is a POC project for my knowledge of how apigeeX works with MTLS client authentication

[hartmann · Accepted solution]

Hello,

As you mentioned, most of the mTLS orchestration is typically handled via Load Balancer before the inbound service reaches Apigee. The following documentation (noted here: https://medium.com/google-cloud/configuring-mtls-for-apigee-x-northbound-traffic-using-global-https-...) explains how to set up the differing layers of the orchestration incredibly well. As per your questions/concerns:

1. Managing certificates would be performed at the Load Balancer layer via TrustConfig (as noted in the above documentation). The only scenario I have seen where Apigee could be utilized is in a passthrough scenario where you require added validation for the given certificate (serial number, etc). In the above, you could pass through the certificate to Apigee, and Apigee could check the inbound information via KVM (extract key/value pair from KVM and compare/contrast incoming versus trusted). This is not incredibly common, but could be supported given the following: https://cloud.google.com/load-balancing/docs/https/setting-up-mtls-ccm#add-custom-header

2. This would be dependent on your implementation/validation via mTLS, both are supported at the Load Balancer layer

3. This would still be evaluated at the LB as well

4. If anything needs to be evaluated at the proxy level (more uncommon) it would be something along the lines of what was noted above (evaluating the pass through headers with "trusted" certificates stored via KVM)

Thanks!

[LuckyEK]

Thanks for your suggestion, from my understanding if I use allowed list certificate to addthe  API consumer's client(leaf) certificate, it would pass through even if its from wrong CN, expired, trusted CA

How can I prevent these scenarios? and if I use Trust anchor (root cert), it opens up a risk to all the API consumers whom certificate are under that particular CA accessing my apigee service

[hartmann]

Hello,

I am not sure I fully understand your ask - is there any specific reason why you would use allow listed certificates? Are they self signed? Allow listed certificates would in theory bypass all of the validation noted here: 

https://cloud.google.com/load-balancing/docs/mtls#validation-steps which covers expiration, SAN validation, etc (most of what is noted above)

Is there no potential chain internally that could address this issue? If not, you could always forward all of the pertinent custom headers to Apigee (see here: 

https://cloud.google.com/load-balancing/docs/https/setting-up-mtls-ccm#add_mtls_custom_headers_to_ur...) where Apigee could store a list of 1-N "trusted" key value pairs via KVM, and you could evaluate the header value against a KVM entry to determine pass/fail

Thanks!

[LuckyEK]

I am not using self-signed but i don't understand for every API consumer whom are using different public CAs connecting to our service we would need to request their root ca + intermediate, this creates operational overhead in managing.

Normally can't we just add client's server cert to the truststore and validate against that?

Also what I noticed on Apigee X there is no UI to manage key value map entries, its only creating the value map names

[hartmann]

Hello,

If you do not want to deal with the overhead of managing certificates for mTLS scenarios at the LB level, the next best case would be to pass through all mTLS-based workflows to Apigee and allow Apigee to evaluate based on your acceptance criteria given what is available via custom header.

In this scenario you can either use a KVM to store pertinent attribute data and perform lookups given validation (you are correct in that there is no UI and the recommended approach is to use KVM APIs as noted here: https://cloud.google.com/apigee/docs/reference/apis/apigee/rest/v1/organizations.apis.keyvaluemaps.e...

or pull pertinent data from an Apigee keystone/truststore and evaluate as noted here: https://cloud.google.com/apigee/docs/reference/apis/apigee/rest/v1/organizations.environments.keysto...

Please let us know if you have any further questions and/or concerns - thanks!

[hartmann]

Hello,

I am not sure I fully understand your ask - is there any specific reason why you would use allow listed certificates? Are they self signed? Allow listed certificates would in theory bypass all of the validation noted here: 

https://cloud.google.com/load-balancing/docs/mtls#validation-steps which covers expiration, SAN validation, etc (most of what is noted above)

Is there no potential chain internally that could address this issue? If not, you could always forward all of the pertinent custom headers to Apigee (see here: 

https://cloud.google.com/load-balancing/docs/https/setting-up-mtls-ccm#add_mtls_custom_headers_to_ur...) where Apigee could store a list of 1-N "trusted" key value pairs via KVM, and you could evaluate the header value against a KVM entry to determine pass/fail

Thanks!