By default all MuleSoft APIs deployed to CloudHub are exposed to external traffic. It is standard practice to protect them using SSL/TLS combined with an authentication policy such as client ID and secret, as well as any other required policies such as IP blocking. This level of security still exposes process and system layer APIs to external traffic, which could have adverse effects if invoked directly. Assuming an API-led connectivity approach, the process and system APIs should not be invoked directly from external clients.
During a recent client engagement, I was asked to remove all external access to the process and system layer APIs. In this blog, I’ll walk you through removing all external access to certain API layers.
When using internal hostnames, the CloudHub shared load balancer is not used and there is no load balancing being done. Although the benefits of the load balancer are not utilized, the request is still routed to different workers based on the Round Robin DNS response. This becomes very client dependent, the DNS requests will be cached, and the behavior will be OS and library specific as to round robin balancing and failover procedures. See MuleSoft help article describing more on this scenario.
When the HTTP listeners on each API are configured using the standard host and port using the shared CloudHub load balancer, they are exposed to outside traffic. This requirement was to only expose the experience layer API to external traffic while still allowing for internal communication between the experience, process, and system layers. By default ‘minimal access’ practices should be followed, and the APIs that aren’t meant to be invoked directly should be protected.
By configuring the HTTP listeners to use the internal host and port, the shared load balancer would only allow connectivity to the exposed experience API. The other APIs would only allow communication on the internal host and port references.
Project Changes
We are going to take advantage of the internal DNS hostnames and ports provided by MuleSoft. This does require that the client has a configured VPC within Anypoint. By default, the VPC has 4 pre-configured firewall rules; 2 that allow external access on 8081 and 8082, and 2 rules that only allow internal traffic on 8091 and 8092. This is what we’re going to configure in the HTTP listeners. Note that it is a best practice to block external access on 8081 and only allow TLS connections on 8082.
HTTP Listener Changes
On the system and process APIs, update the HTTP listener to listen on the internal HTTPS private port. This will be set by CloudHub automatically with a default value of 8092.
<http:listener-connection host="0.0.0.0" protocol="HTTPS" port="${https.private.port}">HTTP Request Changes
On the experience and process APIs, the HTTP requests need to be updated to refer to the new port and need to include a ‘mule-worker-internal’ hostname prefix. Below is a sample of the property file that had the host/port for the ‘tps-sys-dev’ API.
#tps sapi
tps-sys.host=mule-worker-internal-tps-sys-dev.us-w2.cloudhub.io
tps-sys.port=8092
tps-sys.basePath=/v1Additionally, because the requests are all internal, MuleSoft uses your provided certificate which will likely be an invalid, self-signed certificate. To support this, the TLS Context trust-store needs to be marked ‘insecure’ on the HTTP request configuration. Another option to avoid the ‘Insecure’ attribute, would be to create a custom trust store using an internal certificate authority you use to sign the listener certificates.
<tls:context/>
<tls:trust-store insecure="true"/>
<tls:context/>Conclusion
Sometimes security teams will challenge you with additional requirements. Now, with just a few changes to the HTTP listener and HTTP request configurations, your APIs will only communicate internally.
For questions or support needs, please contact us.