How to secure web communications in a Service Fabric cluster in Azure

I came to this question during a conversion with a customer. They have an ASP.NET Core WebApi inside a Service Fabric cluster and they want the WebApi to be exposed publicly on the cluster. As you may know, the default deployment setup for Service Fabric in Azure is to use a public Load Balancer with a Public IP address. While this is great to connect to the management API and the dashboard UI, is not the preferred way to expose the WebApi. Both the management API and the Service Fabric Explorer are using a certificate as the authentication mechanism. This certificate is store in the Key Vault that user selected during the deployment.

My approach to this problem is to use Application Gateway as the Layer 7 load balancer to expose and consume the WebApi from the public Internet. In the Application Gateway I can install the certificate and server the content from it. The internal communication between the Application Gateway and the Service Fabric don’t need to be secured. I can have SSL-offload for the WebApi.

To achieve this, we can modify the default ARM template for Service Fabric and instead of deploying a public load balancer we can deploy using an internal load balancer. This will prevent any kind of public traffic to hit any Service Fabric endpoint. We can follow this documentation for the Service Fabric Cluster networking patterns.

Once we have the cluster deploy using the internal load balancer the Service Fabric Explorer URI will be https://10.0.0.250:19080/, the management endpoint is 10.0.0.250:19000.

Application Gateway.

The next step will be to create a new subnet inside the VNET where the Service Fabric cluster is. After the subnet is created, we can deploy the Application Gateway in that newly created subnet. When the Application Gateway is created, in the configuration setting for the Backend pool we need to add the internal IP address for the internal load balancer that the Service Fabric cluster is using.

This will enable the Application Gateway to route the HTTP/HTTPS traffic through the internal load balancer. If the scale set associated with the Service Fabric cluster increase or decrease the number of VMs, this configuration will be transparent for the Application Gateway, making things easy.

We have everything ready to expose the WebApi using the Application Gateway. Application Gateway is connected to the internal IP of the Internal Load Balancer, who is connected to Service Fabic Scale Set. Inside the Application Gateway we need to setup the Listener, Rule and HTTP Setting to map the port 443, upload the certificate and we ready to go.

Service Fabric management API

The internal load balancer is great because we’re sure that all communication is isolated and secure. But when we would like to deploy a new application to the cluster, or update an existing one, we need communication with the Management API as well with the Service Fabric Explorer. This is a problem right now because only devices in the same VNET are the one who can communicate to the internal load balancer. To solve this connectivity issue, we have two options.

First, deploy a Virtual Machine on the VNET where Service Fabric Cluster is. Install the Visual Studio Agent and deploy from there. We’re going to miss the Service Fabric Explorer as well. But we can connect using remote desktop to that VM and browse from there.

Second option is deploying another load balancer, but in this scenario a public one, and explore both the Management API and the Service Fabric Explorer.

Once the public load balancer is created, go to the backend pools and click on add, give a name and select associated to Virtual machine scale set. Select the Scale Set associated with the Service Fabric cluster.

Then map both the 19000 and 19080 ports to make the management API and the Service Fabric Explorer.

Final architecture

This is final architecture for the proposed solution. With two public IP addresses, one with the Application Gateway to expose using SSL the WebApi and the other one to manage the Service Fabric cluster itself. A final option that it’s a more complicated is to have a VPN Gateway in the VNET and connect your local on-prem network. This could be overly complicated depending on your IT department.

Luis Guerrero.