On Prem Service Fabric Cluster with Windows and gMSA Security

scott_mccollough · 30 May 2019 12:45

What is the recommended way to deploy to an on premise Service Fabric cluster that is using Windows client authentication and cluster gMSA security. I cannot create a deployment target as there is no option for Windows authentication. We are in the process of securing our on premise clusters and this is a bit of a road block.

Alex.Rolley · 31 May 2019 04:13

Hi Scott,

Thanks for getting in touch!

I’ll lead with the bad news, Octopus doesn’t officially support connecting to Service Fabric clusters with Windows Authentication.

Unofficially, with quite a few caveats, we do have limited options.

Our ServiceFabricContext powershell script has a condition that checks for the “SecureAD” security mode, which sets the WindowsCredential parameter to true, but this was to try and support an earlier version of the SF PowerShell cmdlets and was never tested (we never officially supported it, and this condition accidentally slipped in during a PR).

See the condition here:

github.com

OctopusDeploy/Calamari/blob/master/source/Calamari.Azure/Scripts/AzureServiceFabricContext.ps1#L197


    if (!$AccessToken)
    {
        Write-Error "No access token could be found for Service Fabric to connect with."
        Exit
    }


    $ClusterConnectionParameters["ServerCertThumbprint"] = $OctopusFabricServerCertThumbprint
    $ClusterConnectionParameters["AzureActiveDirectory"] = $true
    $ClusterConnectionParameters["SecurityToken"] = $AccessToken


} ElseIf ($OctopusFabricSecurityMode -eq "SecureAD") {


    # Secure AD
    Write-Verbose "Connecting to Service Fabric using AD security."


    $ClusterConnectionParameters["WindowsCredential"] = $true


} Else {
    # Unsecure
    Write-Verbose "Connecting to Service Fabric unsecurely."
}

Our UI does not allow setting this variable to any value except Unsure/ClientCerts/AzureAD, however if you set a variable in your project Octopus.Action.ServiceFabric.SecurityMode to SecureAD calamari would use that instead. To be clear we have never tested this, and SF PowerShell cmdlets would likely require other variables since it’s evolved since this was originally written

This is the SF cmdlet we’re essentially passing parameters through to. See Example 4 on that page - it requires both the WindowsCredential and the ClusterSpn to be specified now, so you are welcome to try, but I’d expect it will want you to specify additional parameters as well to make it work

The developer I’ve been talking to indicated that we may be able to add support for this, but you would need to tell us exactly what example from that page you would use, and we’d just make sure those parameter gets forwarded from our UI to Calamari to the cmdlet, and that would be the extent of our investment in adding support for this. This wouldn’t be tested and so wouldn’t have any proactive support behind it.

The reason we originally never supported this because we had no customer demand for it at the time, and testing it and officially supporting it would require us to spin up Active Directory servers, which none of us had any experience in and was generally a massive time-sink (so investment vs reward wasn’t there).

Any questions please let me know,

Regards,
Alex

scott_mccollough · 31 May 2019 12:41

Alex,

Thank you for the very detailed explanation. Seeing as how general support for Windows authentication to stand alone service fabric clusters seems to be severely limited, I have decided to pursue certificate based client authentication instead.

Scott

Alex.Rolley · 3 June 2019 01:21

Hi Scott,

Thanks for the update, and sorry we don’t have a better story here. It comes down to developer resources and (lack of) customer demand unfortunately.

If there is anything else we can help with please let me know!

Regards,
Alex