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:
Where can we manage different API consumer certificates (in the trust config’s allowList certificate or Apigee KVM)?
Do we need to add an intermediate certificate for the API consumers?
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
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
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
This would be dependent on your implementation/validation via mTLS, both are supported at the Load Balancer layer
This would still be evaluated at the LB as well
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 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
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:
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:
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
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.