Understanding mTLS

Before diving into the specifics of CloudHub, let's briefly touch on mTLS. mTLS is a two-way authentication process between the client and server. While traditional SSL/TLS ensures server-side security, mTLS ensures that both the client and server authenticate each other.
To harness mTLS in CloudHub, developers must ensure that every API consumer is mTLS compatible. But, as in any real-world scenario, there might be a mix of consumers - some capable of mTLS and some not.

mTLS in CloudHub 1.0

In CloudHub 1.0, by setting the Dedicated Load Balancer (DLB) 'Client Certificate Validation' to 'Optional,' API access was granted even to those consumers that couldn't handle mTLS. Developers could then inspect the 'X-SSL-Client-Verify' header in their APIs to ascertain whether a valid client certificate was transmitted.

mTLS in CloudHub 2.0

The landscape has shifted a bit in CloudHub 2.0. Unlike its predecessor, CloudHub 2.0 doesn't offer the flexibility to optionally set mTLS. Instead, developers need to prepare two distinct endpoints - one with mTLS enabled and one without. The crucial decision lies in the application's Ingress settings, where developers specify which endpoint to use based on whether mTLS is required or not.

Conclusion

Adapting to CloudHub 2.0's mTLS implementation requires some rethinking and retooling, especially for those who have been operating with mixed API consumer environments in CloudHub 1.0. By understanding the core changes and preparing adequately, developers can continue to ensure secure and seamless integrations in the MuleSoft ecosystem.