Service Fabric is a great framework, but yet a complicated one. Often, when we try to improve the security of the cluster, we end up adding a lot of complexity in our development pipeline. The local development experience become a nightmare and there's a big lost in productivity for team.

But! It doesn't have to be that way. Productivity and security could play well together if you think about them from the start. Let's take a look at how we can improve our cluster security following all the industry's best practices and still have a good local development experience.

Requirements

From a productivity point of view we want

  • SSL Offload

From a security point of view we want

  • Network isolation
  • WAF (Web Application Firewall) for our front-end nodes
  • IP filtering for the management ports

SSL Offload

It's a nightmare to setup a secure Service Fabric cluster on your local machine that needs to communicate only through HTTPS. First, you'll most likely waste numerous hours reading blog posts to find the right settings to tweak. Then you'll need to generate dev certificates and install them correctly. Obviously, they need to be configurable in order to replace them by the production ones later when you want to deploy to the cloud. Once it's working on your machine, you need to do the same thing for everybody on the team. Otherwise you'll end up in the "Works only on my machine" scenario. As you can see, it's feasible... but really painful to make happen and maintain over time.

There's a better and simpler solution to this problem. The idea is to push the SSL security the edge of your cluster. Azure Application Gateway is a good fit for this, as it will allow us to manage our certificates directly at the entry point of all the incoming requests instead of managing them in every web applications inside the cluster. Then the gateway can communicate over HTTP with all the web applications. Doing so, the only thing we need to be careful about is to have a good network isolation between the front-end nodes and the gateway, as the traffic isn't encrypted between them.

The real gain is that IT can take over managing the application gateway and the certificates, making sure to roll the certificates when they're about to expire. The developers can then focus on delivering features without worrying to much about HTTPS. Developers can run the entire service fabric cluster with all the web applications on their local machine with HTTP. Their local configuration of the cluster in HTTP is exactly as it will be in the Azure Service Fabric cluster hosted in the cloud. Less variables, less configuration, less bugs and surprises in production. Win win win.

Network isolation

It's fine to communicate between the Gateway and the front-end nodes over HTTP as long as we are sure that the front-end nodes are not reachable from the outside world. Every request must pass through the Application Gateway. You can solve this in minutes with an Azure VNet + NSG (Network Security Group), making sure that only traffic from the Application Gateway is routable to the front-end nodes.

Web Application Firewall

As everything pass through the Application Gateway it's a great place to enable a WAF and analyze the traffic further to detect threats against our applications. Azure Application Gateway already have such a feature built-in. It includes a predefined set of rules which detect/prevent most common attacks.

IP Filtering

One thing that is often forgotten is that the Service Fabric management ports are open to the internet by default. A good practice is to restrict these ports to specific IP range like your office's IP range for example. Again NSG to the rescue. Add a simple routing rule and you're done.

Conclusion

Using these simple tactics you'll secure your cluster to the next level. Nothing will be exposed to the outside world which greatly limit the attack vectors against your application. The only entry point will be through your Application Gateway where you'll have great control over what can pass through or not. Also, having only one entry point is much more easier to maintain and monitor over time. The nice thing with this approach is that even with all those security upgrades we haven't complexified our development flow. In the contrary, we simplified it as the developers don't have to worry about network and transport security anymore and only focus on the application security.