[Azure] Removing Debugger NAT rules for service fabric load balancer

Sometimes your project forces you to do something you rather wouldn’t: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that’s fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. 

To facilitate this connection, some rules are added in the load balancer which point certain ports to the machines in your VM scale sets. We have found that for each role you’re running, you’ll get 4 rules to open up 4 different ports. Best practice would be to, after you’ve finished debugging, to remove these rules again by disabling the debugger functionality (which you easily can do from Visual Studio as well). In practice we’ve found that our devs sometimes forget (or neglect, whatever you prefer) to do this. This presents us with two problems:

  1. You’ve got some additional ports opened up, which impact the security of your nodes. This doesn’t mean you get easy access, but each additional port is a potential security risk by definition.
  2. If you’re rolling out your infrastructure using ARM templates, your deployment will now fail when using the ‘Incremental’ mode. It will detect the additional rules and hold deployment.

In order to resolve these issues without having to bother the developers each time, I created two Powershell functions you can use to automate the removal of the debugger rules. These scripts rely on the AzureRM module, so you’ll need that one installed. To use these functions, first log in (Connect-AzureRMAccount) and select the correct subscription (Select-AzureRMSubscription). After that, the rest is as simple as calling Remove-VMScaleSetDebuggerNatPools and Remove-LoadBalancerDebuggerNatPools!

Remove-VMScaleSetDebuggerNatPools


function Remove-VMScaleSetDebuggerNatPools {
param (
[string]$ResourceGroupName,
[string]$VMScaleSetName
)
Write-Information "Removing NAT pools with 'debugger' in the name from VM scale set $VMScaleSetName"
$vmScaleSet = Get-AzureRmVmss -ResourceGroupName $ResourceGroupName -VMScaleSetName $VMScaleSetName
$natPools = $vmScaleSet.VirtualMachineProfile.NetworkProfile.NetworkInterfaceConfigurations.ipConfigurations.LoadBalancerInboundNatPools
$debugPools = $natPools | Where-Object { $_.Id -match "Debugger" }
foreach ($debugPool in $debugPools)
{
$natPools.Remove($debugPool)
}
if ($debugPools.Count -lt 0)
{
Write-Information "Updating $VMScaleSetName to save the changes"
Update-AzureRmVmss -ResourceGroupName $ResourceGroupName -VMScaleSetName $VMScaleSetName -VirtualMachineScaleSet $vmScaleSet
} else
{
Write-Information "Skipping updates on $VMScaleSetName, no debugger pools found."
}
}

view raw

gistfile1.txt

hosted with ❤ by GitHub

Remove-LoadBalancerDebuggerNatPools


function Remove-LoadBalancerDebuggerNatPools
{
param(
[string]$ResourceGroupName,
[string]$LoadBalancerName
)
Write-Information "Removing NAT pools with 'debugger' in the name from load balancer $LoadBalancerName"
$loadBalancer = Get-AzureRmLoadBalancer -Name $LoadBalancerName -ResourceGroupName $resourceGroupName
$pools = $loadBalancer.InboundNatPools | Where-Object { $_.Name -match "debugger" }
foreach ($pool in $pools) {
$loadBalancer.InboundNatPools.Remove($pool)
}
if ($pools.Count -lt 0)
{
Write-Information "Updating $LoadBalancerName to save the changes"
Set-AzureRmLoadBalancer -LoadBalancer $loadBalancer
}
else {
Write-Information "Skipping updates on $LoadBalancerName, no debugger pools found."
}
}

view raw

gistfile1.txt

hosted with ❤ by GitHub

, ,

Related posts

Long Term Support… or not?

Sometimes your project forces you to do something you rather wouldn't: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that's fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. 

[DevOps] Should you migrate onto YAML release pipelines?

Sometimes your project forces you to do something you rather wouldn't: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that's fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. 

Latest posts

Long Term Support… or not?

Sometimes your project forces you to do something you rather wouldn't: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that's fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. 

[DevOps] Should you migrate onto YAML release pipelines?

Sometimes your project forces you to do something you rather wouldn't: debug in staging or production. Although you should definitely try to avoid these situations, sometimes sh*t just happens and that's fine. If your project is running on Service Fabric, Azure offers you the option to attach a debugger right from within Visual Studio. This is a very powerful option which creates a connection between VS and your service fabric nodes in order to communicate with the remote debugger. 

Leave a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *