To prevent unauthorized access to a Service Fabric cluster, you must secure the cluster. Security is especially important when the cluster runs production workloads. This article describes how to configure node-to-node and client-to-node security by using Windows security, where gMSA is the preferred security model.
A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators.
The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as Network Load Balanced solution, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.
Step 1 - Create the infrastructure to host Service Fabric cluster
Step 2 - Setup Node0 as Active Directory - Domain Controller
Step 3 - Join servers to newly created AD Domain
Step 4 - Create gMSA Service Account & Join nodes
Step 5 - Prepare nodes for SFC and deploy Service Fabric cluster secured with gMSA Service Account
Since this step depends on the business needs, we will skip it. Standalone Service Fabric Cluster can run on any environment (On-Prem, Azure VMSS, AWS or any other cloud platform that complies with the minimum requirement of SF and gMSA).
Find below article on how to setup the infrastructure on Azure & AWS:
Create infrastructure for a cluster on Azure VMs - Azure Service Fabric | Microsoft Learn
Create infrastructure for a cluster on AWS - Azure Service Fabric | Microsoft Learn
Keep in mind that for SFC secured with Windows Security, gMSA in particular, we will need at least 4 nodes: 1 AD Domain Controller + 3 Cluster Nodes.
As always, be mindful about the cluster capacity planning. You can decide upon your environment that will host SFC by following the guidelines described in the following article: Service Fabric cluster capacity planning considerations - Azure Service Fabric | Microsoft Learn
Now that we have a functional Domain Controller, we can go ahead and setup the other nodes to join our newly created AD Domain:
Now that we have a fully functional AD Domain and all of our servers are already joined our Domain, we can proceed with the gMSA Service Account Creation. We will first deploy our gMSA Service Account on the DC and then move, node by node to join this newly created Service Account.
Links: Create the Key Distribution Services KDS Root Key | Microsoft Learn
Getting Started with Group Managed Service Accounts | Microsoft Learn
Run an Azure Service Fabric service under a gMSA account - Azure Service Fabric | Microsoft Learn
Add-KdsRootKey -EffectiveImmediately
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
New-ADServiceAccount -name wild-gmsa$ -DnsHostName wild-gmsa.wilddomain.local -ServicePrincipalNames http/wild-gmsa.wilddomain.local -PrincipalsAllowedToRetrieveManagedPassword EWILDVMSS000001$,EWILDVMSS000002$,EWILDVMSS000003$
Please be aware that we must use "$" after each machine name in order to work
Links : Run an Azure Service Fabric service under a gMSA account - Azure Service Fabric | Microsoft Learn
Install-ADServiceAccount wild-gmsa$
Test-AdServiceAccount wild-gmsa$
Links: Create infrastructure for a cluster on Azure VMs - Azure Service Fabric | Microsoft Learn
Install Service Fabric standalone client - Azure Service Fabric | Microsoft Learn
To enable SMB, run this PowerShell command:
netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=Yes
To open the ports in the firewall run this PowerShell command:
New-NetFirewallRule -DisplayName "Service Fabric Ports" -Direction Inbound -Action Allow -RemoteAddress LocalSubnet -Protocol TCP -LocalPort 135, 137-139, 445
{
"nodeName": "vm0",
"iPAddress": "10.17.0.5",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
},
"security": {
"ClusterCredentialType": "Windows",
"ServerCredentialType": "Windows",
"WindowsIdentities": {
"ClustergMSAIdentity": "wild-gmsa$@wilddomain.local",
"ClusterSPN": "http/wild-gmsa.wilddomain.local",
"ClientIdentities": [
{
"Identity": "wilddomain\\localuser",
"IsAdmin": true
}
]
}
},
Be mindful of the format to be used. Not following this format will result in failed SFC Deployment. For example, ClustergMSAIdentity must be in format mysfgmsa@mydomain .
I have found out that these formats may be different from one OS to another. If SFC deployment fails, I would recommend trying these formats as well:
"ClustergMSAIdentity": "gMSAname.domain"
"ClustergMSAIdentity": "gMSAname"
If none of these option is working, feel free to contact Microsoft Support.
.\CreateServiceFabricCluster.ps1 -ClusterConfigFilePath .\ClusterConfig.gMSA.Windows.MultiMachine.json -AcceptEULA
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.