Secure Conversation between CloudHub VPC and Private Space
Context
Recently MuleSoft has launched the newest offering of its iPaaS cloud deployment model under the flagship CloudHub 2.0. With this new launch there has been an increase in the migrations that are taking place from the older version of CloudHub viz., CloudHub 1.0 to this newer one. However, not all applications of an organization that used to reside in CloudHub 1.0 VPC can be immediately and gracefully migrated to CloudHub 2.0 Private Space.
Here arises the need for the ability to still keep certain applications on CloudHub 1.0 VPC while still being able to establish their connectivity with applications that now reside on CloudHub 2.0 Private Space, just like they were able to do while they were situated in the same CloudHub 1.0 VPC before CloudHub 2.0 came into being, thereby upholding usability and business goals as usual.
Objective
To delve deeper into the solution that we are going to discuss today, let’s first understand our requirement more appropriately.
I have a MuleSoft application that is deployed inside my VPC (test-vpc) for CloudHub 1.0 and I have another MuleSoft application that is deployed inside my Private Space (test-ps) for CloudHub 2.0. Now I want these two applications to be able to communicate with each other, preferably using their private endpoints (just like, as if they are situated in the same private network) for better security, and not via the public internet.
Ideation
Thinking about ways in which the aforementioned connectivity can be achieved, I was left rather baffled as while the older version of CloudHub allowed VPC peering as one of the options for straightforward connecting VPCs amongst each other, the newer version has done away with that option altogether. The only two connectivity options now allowed by CloudHub 2.0 are VPN and Transit Gateway.
The Transit Gateway is the one that I have chosen for establishing connectivity between CloudHub 1.0 and CloudHub 2.0, as its the closest substitute (and infact, an even robust and multifaceted option) to the VPC peering option, which seemed to be the go-to here, as we are connecting a VPC and its equivalent Private Space.
Note:- The VPC, Private Space and the Transit Gateway are all required to be mandatorily present in the same AWS region for the setup to work as desired.
Setup present on Anypoint Platform
I already have a Private Space (test-ps) that I have created using all defaults, for deploying my CloudHub 2.0 applications within it. For now, just take a note of its CIDR block used.
Similarly, for deploying my CloudHub 1.0 applications I already have a VPC (test-vpc) configured as default and associated with my appropriate Business Group and Environment. For now, taking a note of its CIDR block should be enough.
At this juncture, please note that both my Private Space and VPC have been created in the same region viz., US East (Ohio) or us-east-2
Creating the Transit Gateway on the AWS side
To configure the connectivity via the Transit Gateway option, first create the Transit Gateway on AWS. To do this follow the given steps:
- After logging in to your AWS console, search for Transit Gateways in the main search tab. Click on Transit gateways from the search results
2. Next change the AWS region to US East (Ohio) or us-east-2, as that’s where our entire setup from MuleSoft lies (here, by default).
3. Next click on the Create transit gateway option, and just provide a name for the transit gateway (bridging-transit) and leave everything else to their default settings.
That’s all that you need to do for setting up the Transit Gateway on AWS!
Next, we will create the Transit Gateway and its attachments for the Private Space (test-ps) and VPC (test-vpc) on the Anypoint Platform and return back to the AWS side for some more fun!
Creating Transit Gateway and Attachment for Private Space
- From the Private Spaces → Network tab click on Create Connection
- Choose the Transit Gateway option and provide its name (preferably, same name as we gave to the Transit Gateway on the AWS side) and click Next
3. Next, in the Configure Routes section you can provide the VPC CIDR of your Anypoint Platform VPC (test-vpc), which is 12.0.0.0/22
4. Now we will need to create a Resource Share on the AWS side to share and connect to the Transit Gateway that we had earlier created. For this, first note the 12 digit Mulesoft AWS account ID that’s now displayed on your screen and store it for later use. Next simply click on the Create Resource Share link and you will be redirected back to your AWS console’s Resource Access Manager → Shared by me: Resource shares page.
5. Here provide an appropriate name (aws-mulesoft-tgw) for your Resource Share and select Transit Gateways under the Resources — optional section and choose the earlier created Transit Gateway viz., bridging-transit.
6. In the next screen, leave the Associated managed permissions to AWSRAMDefaultPermissionTransitGateway and click Next
7. Now from the Grant access to principals page, choose the Allow sharing with anyone radio button under the Principals — optional section. Then select the principal type as AWS account from the Select principal type dropdown and provide the Mulesoft AWS account ID that you had earlier copied in step 4 above and click Next.
8. Finally review your choice and click on Create resource share. The resource share will be created as shown.
9. Back in Anypoint Platform Add Transit Gateway page, you can now Verify Resource Share using the Owner and ID values from the created resource share, as shown above and click Next.
10. In the Accept Attachment section, click the Transit Gateway Attachments link. This will redirect you back to your AWS console’s Transit gateway attachments section, where you will find the attachment in pending acceptance under the State column. You might not be able to see this instantaneously, so please be patient for it to show up.
11. Once it shows up, click on its Transit gateway attachment ID to open the attachment. Verify that it is indeed from your MuleSoft Private Space by confirming that its Resource owner ID matches the 12 digit Mulesoft AWS account ID that you had earlier noted in step 4 and assigned as the Principal in step 7.
12. After verifying click on the Actions dropdown on the top right and select Accept transit gateway attachment option. Its State will now change to Available and once it does, you can return to the Add Transit Gateway page back in Anypoint Platform and click Done.
13. Back in the Networks tab of your Private Space under the Connections section now shows the Transit Gateway attachment that you just configured with state as Available, as shown below
14. Click on the three dots beside the connection name and check whether the route to the MuleSoft VPC is configured properly or not, as
Here, we see that the 12.0.0.0/22 route for our MuleSoft VPC is present and any traffic for it will be routed via the transit gateway in just the way we want!
Creating Transit Gateway and Attachment for Virtual Private Cloud
- From the Runtime Manager page click on Transit Gateways from the left side panel and confirm to the I’m ready banner.
- Next provide a name for this transit gateway (preferably, same name as we gave to the Transit Gateway on the AWS side) and choose the Region with care to select the same region as our Private Space and Transit Gateway on AWS and then click Next
3. Next just take a note of this new 12 digit MuleSoft AWS account ID that is now being shown in the Add transit gateway page, as below
4. Now, since we had already configured a Resource share for our Private Space in the previous section, we now just need to modify that same Resource share (aws-mulesoft-tgw) on AWS and add this new Principal (12 digit Mulesoft AWS account ID, from step 3 above) to it.
5. For that click on the Create Resource Share link from the Add transit gateway page on MuleSoft or simply navigate to Resource Access Manager → Shared by me: Resource shares on your AWS console and click on the aws-mulesoft-tgw.
6. Next click on Modify and directly click on Grant access to principals section from the left hand panel, leaving the rest unchanged and proceed to add the new 12 digit MuleSoft AWS account ID copied from step 3 above, as yet another Principal for this Resource Share, as shown below
7. Click Next and Review your changes before clicking Update resource share
8. Back in the Anypoint Platform, click Next and provide the Owner and ID of the AWS Resource share (aws-mulesoft-tgw) in their respective fields and click Add
9. The Transit Gateways page shows the progress for connecting to AWS and adding the transit gateway to Anypoint Platform. When the transit gateway addition succeeds, the Transit Gateways page updates the owner and ID from AWS and the state as Available, as below
10. Next select the + Attach VPC option from the same Transit Gateways page and select the VPC that we have viz., test-vpc before clicking Next. Please note that only those VPCs will be shown here that are situated in the same region as the Transit Gateway.
11. In Anypoint Platform, on the Accept VPC Attachment page, click the Transit Gateway Attachments link and then in the AWS console’s Transit gateway attachments section, you will find another attachment in pending acceptance under the State column. You might not be able to see this instantaneously, so please be patient for it to show up.
12. Once it shows up, click on its Transit gateway attachment ID to open the attachment. Verify that its Resource owner ID matches the 12 digit Mulesoft AWS account ID that you had earlier noted in step 3 and assigned as the Principal in step 6.
13. After verifying click on the Actions dropdown on the top right and select Accept transit gateway attachment option. Its State will now change to Available and once it does, you can return to the Accept VPC Attachment page back in Anypoint Platform and click Done.
14. The Transit Gateways page shows the progress for accepting the VPC attachment from Anypoint Platform to AWS. Click Refresh to update the attachment status. When the VPC attachment succeeds, the Transit Gateways page displays the VPC attached message and the attachment state indicates that it’s Attached to Transit Gateway.
15. Finally, we need to click on Add Route and in the Add VPC Route add the CIDR range of our MuleSoft Private Space (test-ps) viz., 10.0.0.0/22 and click Add route
16. Finally the VPCs section along with configured Routes in the Transit Gateways page will look as shown below,
Transit Gateway Attachments on AWS
After configuring Principals and accepting the transit gateway attachment, our Transit Gateway Attachments page on AWS console will look like below
With this we have come to the end of all our setup and configurations and are ready to validate the communication between an Anypoint MuleSoft VPC (for CloudHub 1.0) and Anypoint MuleSoft Private Space (for CloudHub 2.0)
The Proof is in the Pudding
I have configured two simple applications that try to call each other. One of them I will deploy on CloudHub 2.0 inside the Private Space, test-ps and the other on CloudHub 1.0 inside the VPC, test-vpc. Let’s quick glance at the applications one by one.
for-cloudhub2
This application has two flows. The sendFlow has a scheduler that will invoke the application deployed in CloudHub 1.0 VPC, using its private internal worker host via the Transit Gateway that we setup. The Request to C1.0 component is therefore configured as shown below
The Transform Message generates the payload as shown below,
The other flow, the receiveFlow is present to respond back to the application that calls it from CloudHub 1.0, in return and is simply configured with a message to respond back as the payload as,
The loggers are strategically placed to inform and vindicate the application’s desired behavior.
for-cloudhub1
This application also has two flows. The sendFlow has a scheduler that will invoke the application deployed in CloudHub 2.0 Private Space, using its private endpoint host via the Transit Gateway that we setup. The Request to C2.0 component is therefore configured as shown below
The Transform Message generates the payload as shown below,
The other flow, the receiveFlow is present to respond back to the application that calls it from CloudHub 2.0, in return and is simply configured with a message to respond back as the payload as,
The loggers are strategically placed to inform and vindicate the application’s desired behavior.
Verifying Connectivity Behavior and Application Logs
The for-cloudhub2 application is successfully able to communicate with the for-cloudhub1 application located inside the VPC (test-vpc) for CloudHub 1.0, as shown below
Similarly, the for-cloudhub1 application is successfully able to communicate with the for-cloudhub2 application located inside the Private Space (test-ps) for CloudHub 2.0, as shown below
Conclusion
As you might have noticed, all communication between these two applications, and for that matter any application that resides in the MuleSoft VPC (test-vpc, for CloudHub 1.0) and MuleSoft Private Space (test-ps, for CloudHub 2.0), take place via the hub and spoke private network established using the Transit Gateway connectivity option.
To ensure that the communication between the two applications is indeed happening using the Transit Gateway, the CloudHub 1.0 application is called via its internal worker host viz., mule-worker-internal-for-cloudhub1.us-e2.cloudhub.io and the CloudHub 2.0 application is called via its private endpoint host viz., for-cloudhub2-vgh86p.internal-7hy5e6.usa-e2.cloudhub.io. None of these endpoints are exposed to, or available/reachable from the outside world (public internet) in any way!
Finally, not all traffic is allowed via the Transit Gateway (bridging-transit). Only the traffic from those CIDR blocks configured and added as routes to the transit gateway route tables for the VPC (test-vpc) and Private Space (test-ps) are allowed to flow through the transit gateway thereby providing maximum security controls and peace of mind!
References:
Feel free to reach out to me at my LinkedIn profile for more insights, and please post your queries.
Thanks a bunch for staying around till the end. Hope I have helped you learn a thing or two. Cheers!
