Nav

Cloudhub Dedicated Load Balancer for VPCs

logo cloud active logo hybrid disabled logo server disabled logo pcf disabled

Overview

CloudHub features a backend load-balancing service designed to automate the provisioning of infrastructure components. You can use this service to deploy one or more custom load-balancers within a VPC.

Each dedicated load balancers allows you to:

  1. Handle Load balancing amongst the different CloudHub workers that run your application.

  2. Define SSL configurations to provide custom certificates and optionally enforce two-way SSL client authentication.

  3. Easily configure proxy rules that map your applications to custom domains, enabling you to for example host everything under a single vanity domain.

This is an optional addition to your Anypoint infrastructure that is not included by default in all Anypoint Platform plans. To enable it, you must first own an Anypoint Virtual Private Cloud. You can associate multiple environments to the same VPC, meaning that you can use the same dedicated load balancer for your different environments.

Although this feature will eventually be built into the Runtime Manager UI, currently it’s only available as a service that can be used via the Anypoint Platform Command Line Interface or the Cloudhub API.
Check the Creating and Configuring a Dedicated Load Balancer section for more information.

Load Balancer Architecture

Your CloudHub dedicated Load Balancer has an internal domain name to be used by applications and clients within the VPC. The structure is internal-<lb-name>.lb.anypointdns.net where <lb-name> is the name you gave the load balancer when you created it. Additionally, your dedicated load balancer exposes an external domain name that you can be reached from outside your VPC network: <lb-name>.lb.anypointdns.net where <lb-name> is the name you gave the load balancer when you created it.

Each Dedicated Load Balancer has a DNS A Record pairing its external domain name (<lb-name>.lb.anypointdns.net) to the IP addresses of your workers.
Through your DNS provider, you can add this DNS A record to the DNS CNAME records of your DNS servers and use your own hostnames.

If you want your load balancer to handle all connections to your application and you don’t want your default domain name for your application publicly exposed, then each application needs to be listening over HTTP on port 8091 or 8092, or you can create a custom mapping policy to redirect outside requests from your load balancer to your specific application.

Your load balancer listens for outside requests over HTTPS and, by default, communicates internally with your worker over HTTP. If you configured your Mule application within the VPC to listen on HTTPS, make sure you set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

SSL Endpoints

By providing a certificate and private key pair, you configure an SSL endpoint for your load balancer to serve to clients.
Each load balancer can have multiple and independent SSL endpoints. Each one of them identified by their server certificate common name.

A dedicated load balancer needs to have at least one certificate associated to it, meaning that at least one SSL endpoint needs to be configured when creating the load balancer.

Requirements

To associate an SSL endpoint you need to provide:

  1. One file containing a pem encoded and not encrypted certificate file.

  2. A second file containing the private key of your .pem certificate.

    The private key file needs to be passphraseless

Each SSL Endpoint can have multiple CA certificates and CRLs. Each of these certificates needs to be provided in a single unencrypted, pem encoded file. Ordering for independent CA certificates is not important, but certificates in a chain of trust must be concatenated together.

Uploading Certificates

The certificate that you upload to your Load Balancer must be contained in one pem encoded and unencrypted file. This file could contain the entire certificate chain ordered one after the other, similar to the example section below:

Certificate Example

The Primary Certificate

-----BEGIN CERTIFICATE-----
(Your Primary SSL certificate: your_domain_name.crt)
-----END CERTIFICATE-----

The Intermediate Certificate

-----BEGIN CERTIFICATE-----
(Your Intermediate certificate: DigiCertCA.crt)
-----END CERTIFICATE-----

It is not necessary to include the root certificate in the certificate chain. However, make sure to include the ASCII armor in each certificate.

You can upload an SSL-Endpoint to your load balancer when creating one using the cloudhub load-balancer create or upload a new SSL endpoint to an existing load balancer using the cloudhub load-balancer ssl-endpoint add command.

Certificate Validation

If at least one CA certificate is provided for the SSL endpoint, the load balancer passes the client certificate data to the API using the HTTP headers below:

X-SSL-Client-Verify

This header returns either SUCCESS, FAILED, or NONE Only after SUCCESS, the client is verified.
It returns NONE when the certificate is not present and FAILED when other validation problems occur.

X-SSL-Client-DN

Contains the full Distinguished Name of the client certificate.

X-SSL-Issuer

Contains the full Distinguished Name of the issuing certificate.

X-SSL-Client-Serial

Contains the serial number used by the CA to identify the client.

Adding Revocation Lists

The CloudHub Load balancer can optionally verify client requests against Certificate Revocation Lists (CRL). All CRL files need to be concatenated into a single pem encoded file for upload. Ordering is not important.

You can add a revocation list when creating the load balancer using the ´--crl´ option in your load-balancer create command.

Additionally, if your load balancer is already created, you can use the REST API to update it.
You can send a PATCH request to the /organizations/{orgid}/vpcs/{vpcId}/loadbalancers/{lbId} endpoint adding a revocationList element:


          
       
1
2
3
4
5
6
7
[
  {
    "op": "replace",
    "path": "/sslEndpoints/0/revocationList",
    "value": "-----BEGIN X509 CRL-----\nMIIBTTCBtwIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJBVTETMBEGA1UE\nCBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk\nMRAwDgYDVQQDEwdvcmcuY29tFw0xNjAzMTUwOTI2MThaFw0xODAzMTUwOTI2MTha\nMBwwGgIJAIBvvO4dJHjhFw0xNjAzMTUwODUwMTZaoA4wDDAKBgNVHRQEAwIBBjAN\nBgkqhkiG9w0BAQUFAAOBgQCCAbGXW+Hnzmd1bXqWsFXfogOsJScoxkJOhhmjui3I\nhTUyO5plGHUBLjBnDkypM+iLfn0W4wPcNj7FZdz4Hu/WLntxwrTtR5YOcfIhEGcq\nwvJq/1+WKUPC6eqGwx0iKOOBIWsaf5CNOOUQMo6RaeTeu8Uba2EGFk1Vu/SoZYAK\nsw==\n-----END X509 CRL-----\n"
  }
]

It is recommended to use the CloudHub REST API to programmatically update your revocation lists.
In order to get the necessary vpcId, and loadbalancerId from the CLI, you can use a vpc JSON describe and load-balancer JSON describe command respectively.

You can send a PATCH request to your load balancer’s endpoint to update any other property.

Certificate Ciphers

A list of recommended ciphers suites with a good balance between compatibility and security for your SSL endpoint are below:
They all offer forward secrecy, except RC4-SHA which is there to support Internet Explorer 8.

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA
ECDHE-RSA-DES-CBC3-SHA
EDH-RSA-DES-CBC3-SHA
AES256-GCM-SHA384
AES128-GCM-SHA256
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

ClourHub’s dedicated load balancer supports TLSv1.1 and TLSv1.2. Additionally, you can configure TLS v1.0, but bear in mind that such protocol is no longer accepted by PCi compliance due to its significant vulnerabilities.

Mapping Rules

The load balancer configuration is defined by a list of Mapping Rules which describe how input URL should be translated into calls to different CloudHub apps.
Mapping rules are attributes of the load balancer’s SSL endpoint.
When you create a mapping rule, you need to specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

When creating a simple matching rule, one input address is literally matched to the defined output: the endpoint of one of your applications.
Instead of using literal matchings you can also use a Pattern to match a variable-like input text to an endpoint.

By using proxy rules, you can map a domain or subdomain to one of your Mule applications that run in CloudHub

Using Patterns in Mapping Rules

A pattern is a string that defines a template for matching an input text. Whatever is placed into curly brackets ({ }) is treated like a variable. These variables can contain only letters (a-z) and cannot contain any other characters, such as digits, slashes, etc. The variable values can contain the following characters ‘a-z0-1.&?-_’ but no slashes.

For example, you can literally bind two hostnames for redirect:


          
       
1
‘app.example.com’ ->  application: `app` URI: `/example’

Or you can define a pattern to hold the input value:


          
       
1
‘example.com/{mypattern}’ -> application: `app-{mypattern}` URI: /data

The example above causes that both ’example.com/bookings’ and ‘example.com/sales’ match to app-bookings/data and app-sales/data respectively, as the variable mypattern holds these values.
For input=”bookings.example.com”, the pattern can be resolved by assigning mypattern=”bookings” and for input=`sales.example.com, the pattern is resolved to assign `mypattern=”sales”

Depending on your design, you can choose to leverage your internal redirects to your endpoints using patterns or simply literal mappings.

Note that currently patterns in the application URI are not supported.

Creating Mapping Rules

A mapping rule is a set of fields that define an Input URL, and a set of fields that describe the Output URL.

  • The input URL is described using a URI parameter which can be specified by the user:

    1. URI - a String or Pattern that describes the Input URI.

      The input URL follows the main load balancer’s domain (This value should remain constant for the same load balancer)

  • The Output URL is specified by two fields.

    1. appName - Output the application name where the request will be forwarded to.

    2. appURI - the URI string that is passed to the resolved application.

Both input and output URLs can be defined using patterns or literal Strings.

Mapping rules are attributes of the load balancer’s SSL endpoint, which is identified by the certificate name.
When you create a mapping rule, you need to specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

If your SSL endpoint sets a wildcard certificate, and you want to use the subdomain portion in a mapping rule, you can use the pre-defined {subdomain} variable.

The rule which is defined first has high priority against other ones defined after it. This means that the first matched rule will be applied.
You can create, view and delete existing rules using the mappings add, mappings describe and mappings remove commands respectively.

Mapping Rule Examples

The table below contains some mapping rule examples:

Given that the external load balancer domain name depends on the unique name you assign to it, assume that the load balancer in these examples is lb-demo.

By default, your load balancer listens to external requests on HTTPS and communicates internally with your worker over HTTP. If you configured your Mule application within the VPC to listen on HTTPS, make sure you set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

URL Mapping

You can pass the app name as an input URI and map it directly to the app name in CloudHub:

Rule # Input URL Output URL

URI

appName

appURI

0

/{app}/

{app}

/

This rule maps lb-demo.lb.anypointdns.net/{app} to {app}.cloudhub.io.
{app} being a pattern for application name you choose to pass.

Host Mapping

If you have a wildcard certificate (like *.example.com), you can use the ´subdomain´ variable to map any subdomain:

Rule # Input URL Output URL

URI

appName

appURI

0

/

{subdomain}

/

This rule automatically maps any request passed to a subdomain of example.com to the corresponding appName. For example:

  • Passing api.example.com would redirect to api.cloudhub.io

  • Passing application.example.com is mapped to application.cloudhub.io.

The same applies for the Subject Alternative Names (SANs) of your SSL Endpoints.
If you have different SANs configured for a certificate’s common name, you can use the ´subdomain´ variable to map the subdomain portion of your domain name to your application. For this to work, however, your applications need to have the same name as the common portion of your domain name.

For example, having:

  • Two deployed applications:

    • dev-app

    • qa-app

  • And an SSL endpoint with the Subject Alternative Names:

    • dev.example.com

    • qa.example.com

  • The mapping rule:

    Rule # Input URL Output URL

    URI

    appName

    appURI

    0

    /

    {subdomain}-app

    /

Then, this rule would map the subdomain part of your domain name to the application name:

  • Passing dev.example.com redirects to dev-app.cloudhub.io.

  • Passing qa.example.com redirects to qa-app.cloudhub.io.

1:1 Mapping

If you have only one application, you can map the literal app name.

Rule # Input URL Output URL

URI

appName

appURI

0

/

myApp

/

This maps your default load balancer lb-demo.lb.anypointdns.net directly to your app in Cloudhub myApp.cloudhub.io.

Indexing the Priority of Rules

When creating a mapping rule, you need to assign an index to it to define the rule’s priority order.
A rule defined first, at index 0 has higher priority against other rules defined after it. The higher the index assigned, the less priority the mapping rule has.

Every rule must have a priority defined. It is highly recommended to pay attention to each rules’ order when creating them, and multiple rules might override each other.

Ordering and Prioritizing Rules

You can set the order of your mapping rules when creating them using the cloudhub load-balancer mappings add command in the Anypoint-CLI by specifying an index value.

When using the API to create a rule, you can not specify a priority order, but you can send a PATCH request later to the load balancer endpoint anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId} and update your rules expressions with an order index, to match your needs based on the order logic explained above.

The load balancer ID is provided to you when you create it.
You can also perform a GET request to your endpoint /organizations/{orgid}}/loadbalancers` to get the ID.

Whitelists

In order to whitelist IP addresses to your load balancers, you need to pass those IP addresses in CIDR notation using the load-balancer whitelist add command.

The whitelist works for inbound connections at the load balancer level, not at the CN certificate level. Make sure you only pass IP addresses.

Creating and Configuring a Dedicated Load Balancer

In order to be able to create and configure a load balancer, your profile needs to be an administrator of the organization to which the load balancer is associated.

There are two ways of creating and configurin a dedicated load balancer for your VPC:

  1. Using the cloudhub load-balancer create command from the Anypoint Platform Command Line Interface

  2. Using the Cloudhub API through the endpoints anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers and anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs.

A full description of loadbalancers and vpcs endpoints is available accessing your API Portal.
In the link above, search among other Mule APIs for the "CloudHub" API and enter its latest version.

Tutorial