Last Updated on 30/05/2021 by Patryk Bandurski
In the last article, you have seen how to set up the development environment on the AWS platform. By default, inbound access to each application deployed on such environment is prohibited. How to enable HTTP traffic? In this article, you will find simple walkthrough explaining how to configure ingress.
Requirements
Runtime Fabric allows only to listen over TLS. In other words, only the HTTPS protocol is allowed. For this, we need to prepare both certificate and DNS entries.
In the walkthrough, I will use domain mulesoft.meetup.profit-online.pl. For me, was the most convenient choice to use my blogs’ subdomain.
Certificate
If you have already certificate you may skip this step. In my case, however, I need to generate one. Below you will find the command to execute:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out meetup.pem -days 365
During generation, you need to answer a couple of questions. Here is the output of the command from the above:
Here, FQDN is important. Based on the value the app URI will be different. But about that later.
DNS configuration
The certificate is not enough. We need to have a domain or subdomain.
We need to have two values. First is the domain/subdomain name. Second is the IP to associate. The subdomain is already known it is mulesoft.meetup.profit-online.pl. But which IP should we choose?
We need to take Controller’s public IP address. To do this we need to log in on Amazon AWS console then go to EC2 instances. Select runtime-fabric-controller instance. On the details page, you will find the public IP address.
Controllers’ IP address
Amazon assigns public address dynamically when the instance starts. When you decide to stop the machine or some sort of crush will happen, the public IP address will change. In order to retain one IP, you need to define Elastic IP address and assign it to a controller.
Remember that this service is not free of charge 🙂
When you have collected all. Create A and MX DNS entries.
Ingress configuration
Now we are ready to create ingress configuration. Log in to Anypoint Platform. Then go to Secrets Manager. BTW I love the name :P. Harry Potter and Secrets Manager.
Information
If you see a message like:
Your account does not have permissions to use this feature in the ‘Prod’ environment. Please contact your account administrator for access. You need to amend your access privileges.
Go to Access Management and then click users. Select the user that should have access to Secrets Manager. Go to Secrets Manager tab and grant access for the specified environment. In my case ‘Prod‘.
Secret Group
Click the big blue button called Create Secret Group. On the next screen choose the name for the newly created group and then click the Save button.
My group’s name is DevSecurityGroup.
Keystore
In this section, we will upload our certificates with the private key. Click the Keystore section on the left-hand side. After that click Add Keystore button.
All you need to fill in are the Name, Type, Certificate File, Key File, and Key Passphrase fields. By default, PEM is used as a cert type. Your filled Keystore should look similar to the one depicted on the screen below.
TLS Context
Now it is time to associate Keystore with the Anypoint Platform. In order to do this click TLS Context. Then click Add TLS Context button.
We need to
- name it
- select TLS Version. TLS 1.2 is much safer
- Anypoint Security as a target to connect it with Runtime Fabric
- keystore that we have defined in the previous step
Enable ingress on Runtime Fabric
Once we have all prepared we are now ready to attach the Secret Group with Runtime Fabric definition.
On Anypoint Platform go to the Runtime Manager. Next, select the Runtime Fabric menu. Select the fabric that you would like to associate with TLS context and the display Inbound Traffic tab. As you can see on the picture below I have display Inbound Traffic for dev-fabric definition.
You need to Enable it as in the picture above.
Next, you need to specify the number of replicas. By replica, we mean internal load balancer. For your production environment, you should specify at least 2. For our dev environment, 1 would be enough.
On the picture below you can see that we may specify how much vCPU and memory to allocate to our load balancers. I have decided to use the minimum of what is allowed.
Under TLS Configuration section you link your Runtime Fabric with the secret group and TLS context that we have already defined in the previous steps.
Advanced configuration
You may further configure a load balancer in the Advanced configuration section. More about each property you can find in MuleSoft documentation.
Now click “Deploy” button.
Test our configuration
Okay, it is time to deploy an application with an HTTP Listener. When you do this and your application will be in Running state you should see Application URL. As in the screenshot below, my URL is pointing to
https://health-app-dev.mulesoft.profit-online.pl.
My application publishes health resource that can be easily accessed from the Web Browser or Postman. In the picture below you can see that I was able to access my application.
In my case the URL consists of:
- application name: health-app-dev
- domain name: mulesoft.meetup.profit-online.pl
- resource: health
This is caused by the certificate with an asterisk in front of the FQDN. In my case that is *.mulesoft.meetup.profit-online.pl. If you would omit the asterisk your application URL would look like:
https://mulesoft.meetup.profit-online.pl/health-app-dev/health
As you can see the URL is slightly reordered. However, I prefer the first notation where the application name is at the beginning of the URI
Summary
In comparison to CloudHub and on-premise, the Runtime Fabric restrict inbound access by default. You need to configure it manually. However, it is rather straightforward to do. From a different point of view, you have a more secure environment.
Feel free to leave a comment below, or comment on LinkedIn.