A useful guide on exposing APIs using DLB on CloudHub

Last Updated on 12/09/2021 by Patryk Bandurski

If you want to follow the API-led principles your process and system APIs should not be accessible from outside. These APIs are only for internal usage. On top of them, other APIs are built and the application network grows. Experience APIs should be available for consumers to use. Today I show you how can it be achieved using a Dedicated Load Balancer. The ideas presented in the article are based on my real project experience with securing API on CloudHub.

API-led layers infrastructure with DLBs

On the diagram below you can see my API-led layers proposition. We have experience, process, and system APIs layers in a VPC. In front of the experience APIs layer, we have a Dedicated Load Balancer for public network communication. DLB listens on port either 80 or 443 and translates it accordingly to 8091 or 8092. Our experience API is calling process API, using internal traffic only.

On the right-hand side, you can see Hacker. He tries to call our process API directly. This should be prevented. It is just a matter of a proper configuration of the VPC’s firewall settings. So let’s see how to properly configure it.

API-led approach with Dedicated Load Balancers
API-led approach with Dedicated Load Balancers

VPC configuration

First, let’s take care of the VPC configuration. In our scenario, we would like to block access to all our APIs from the internet. APIs should be only accessible from within the virtual private network. On the screen below you can see four main firewall rules. For all of them, I set up Source to be Local VPC. As a result, to call an API over port 8081/8082 or 8091/8092 I need to be within the VPC. I won’t be able to call the API from the internet.

VPC firewall rules allowing only local VPC traffic
VPC firewall rules allowing only local VPC traffic

Let’s verify the configuration. My experience API is available under the following URI dlb-eapi.us-e2.cloudhub.io. It has an HTTP listener, listening on port 8091. Now I need to verify two possible ways to call my API. First is the access via shared load balancer – http://dlb-eapi.us-e2.cloudhub.io/api/v1/customer. The second one is a direct call, bypassing SLB – http://mule-worker-dlb-eapi.us-e2.cloudhub.io:8091/api/v1/customer. In both cases, I receive a timeout.

Information

More about DLB you can read in my previous post. Why did I expose API over 8091 port? I plan to use DLB to expose HTTPS. It translates incoming request URI to mule-worker-internal-[appname].[region].cloudhub.io. This specific application URI listens only on HTTP private port 8091 or 8092.

DLB configuration

Now that we have configured VPC firewall rules and no traffic is allowed from the internet it is time to configure both DLBs for the public and internal traffic. I won’t focus on creating DLBs as I described it already in this article.

DLB for public traffic

Open a DLB and go to the Whitelisted CIDRs tab. For public traffic, you should put here either 0.0.0.0/0 (the internet) or any specif public IP ranges. The latter one is useful if experience APIs are restricted for specific consumers.

DLB allowing public internet access to our experience APIs by setting whitelisting CIDR range to 0.0.0.0/0
DLB allowing public internet access to our experience APIs

This was just the first part. Now we need to configure the URL mapping rule so the consumer can call only experience APIs. This is very project-specific, and it depends on project guidelines. Let’s assume that the applications’ name pattern is as follows [myproject]-[api]-eapi for experience APIs. The configuration presented down below rewrite URL from /{api}/ to myproject-{api}-eapi. For example /sfdc-customers/ is rewritten to myproject-sfdc-customers-eapi. That way the caller will never be able to call my process or system APIs. Because they have postfix -papi and -sapi.

URL mapping allowing to call only experience APIs (in my case -eapi postfix)
URL mapping allowing to call only experience APIs (in my case –eapi postfix)

Let’s analyze examples. Consumer is calling /sfdc-customers/api/v1 on DLB. DLB matches the URL mapping rule pattern and computes the target application name. In this case, it is myproject-sfdc-customers-eapi. Based on the mapping rule postfix with eapi is appended. The URL is rewritten to myproject-sfdc-customres-eapi.us-e2.cloudhub.io/api/v1. Imagine now a case when someone tries to call the process API. The URL Mapping rule computes not existing application name as always eapi is appended to the name.

URL mapping transforming API name into application name deployed on CloudHub
URL mapping transforming API name into application name deployed on CloudHub

Internal traffic

You must have noticed that I use internal hostnames to call process and system APIs. I append mule-worker-internal to the application name. DNS resolves the hostname to the private IP address from the VPC range. As a consequence, the URI will never be reachable from outside of the VPC.

Applications’ configuration

Once we have our configuration in place, we are ready to alter MuleSoft applications with URLs in HTTP requestors. On the diagram below you can see the sample configuration. Let’s break it down per integration layer:

  • Experience API: my-public-dlb.anypointdns.com/portal-orders/api/v1/orders
  • Process API: mule-worker-internal-myproject-order-mgm-papi.us-e2.cloudhub.io:8092/api/v1/orders
  • System API: mule-worker-internal-myproject-sfdc-orders-sapi.us-e2.clouidhub.io:8092/api/v1/orders
URI configuration for MuleSoft Application
URI configuration for MuleSoft Application

To make it more generic:

  • Experience API: [public DLB name].anypointdns.com/[API name]/[URI Path]
  • Process API: mule-worker-internal-[application name].[region].cloudhub.io:[port]/[URI Path]
  • System API: mule-worker-internal-[application name].[region].cloudhub.io:[port]/[URI Path]

Summary

Following API-led architecture principles can result in bulletproof design. Today I described how to combine DLB into our architecture. We can use Dedicated Load Balancers to enable traffic from public networks. The DLB is dedicated to exposing experience APIs. Both process and system APIs are accessed only via private hostname (mule-worker-internal). DLB configuration is fairly straightforward. It comprises whitelisting setup and URL mapping rules. In order to prepare mapping rules we need to have an application name pattern defined for our project, without it, it just won’t work. The next step was to disable the direct access to APIs by setting up firewall rules on VPC. Once the configuration is ready, we can easily replace hostnames and paths in MuleSoft applications.

A useful guide on exposing APIs using DLB on CloudHub

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top