Service fabric managed cluster and Azure Firewall

Question

We want to use Service Fabric Managed Cluster (SFMC) to host some custom TCP gateways. We prefer that over plain Service Fabric Cluster (SFC) due to the simpler configuration and automated certificate rollover.

We have a Hub + Spoke architecture, where a firewall in the hub protects all our services in a service spoke.

However, all the documentation I have read says the SFMC primary node types must have a public load balancer IP, which would presumably mean you can't protect it with an Azure Firewall.

That seems like a fairly fundamental issue to me, simply relying on NSGs etc.

https://learn.microsoft.com/en-us/azure/service-fabric/how-to-managed-cluster-networking

Describes putting your primary nodes on a public IP load balancer, and a secondary set of nodes on an internal only load balancer. That means doubling up on the number of VMs, probably 12 nodes in total.

It seems the SFC can do it using an internal only LB for everything, but that would be a support / management downgrade, as it doesn't have auto certificate rotation.

Also, you would lose the Azure portal cluster status widgets when going private.

Is there a way to create an SFMC on an internal load balancer, and if possible, still get the service fabric status accessible via a firewall <> private load balancer config?

or do we have to really build an SFMC with primary and secondary nodes (primary with a public LB and secondary with a private LB)?

Thanks

Answer 1

@Mike Sharp

Welcome to Microsoft Q&A Platform, thanks for posting your query here.

For production environments we have a general recommendation to create a dedicated primary node type for system services. And use Secondary Node types for applications which will be accessed by end users, Add placement constraints to reserve the primary node type for system services.

If you want to see your cluster in the Azure portal, your load balancer must expose a public IP address, and your network security group must allow incoming port 19080 traffic. If your setup does not meet these requirements, the Azure portal does not display the status of your cluster.

Please refer to this article for more details.

In this article, we can see the example that shows how the architecture would look like and who can access, where the primary node type uses public IP to allow the SFRP, SFX and SF admin to communicate with the primary node type on the management endpoint and this communication is secured with the cluster certificate.

Hope this helps.
If you need further help on this, tag me in a comment.
If the suggested response helped you resolve your issue, please 'Accept as answer', so that it can help others in the community looking for help on similar topics.

Answer 2

Hi,

The answer doesn't address any of my security concerns.

What is the point of creating a AZ Firewall with Hub / spoke architecture, making it very secure, and then make a cluster which is half in and half out of that protection?

In your example image, Internet access to VNBET Subnet 1 is made without any route through the firewall, and therefore things like advanced threat detection are not possible.

Subnet 2 and 3 route through the firewall, but the concept of a secure VNet is lost, as a tractor has just been driven through it by exposing half of the cluster to the internet?

Secondly, this proposed architecture would need 2 x 6 VMs, and the minimum size VM costs approximately £106 per month per VM, before any discounts. So that is £1,272 a month just to create the service fabric. That puts it out of range for a lot of small scale projects.