Best practices for Azure Service Fabric security

For more information, see Service Fabric security checklist.

Deploying an application on Azure is fast, easy, and cost-effective. Before you deploy your cloud application into production, review this list of essential and recommended best practices for implementing secure clusters in your application.

Azure Service Fabric is a distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable microservices. Service Fabric also addresses the significant challenges in developing and managing cloud applications. Developers and administrators can avoid complex infrastructure problems and focus on implementing mission-critical, demanding workloads that are scalable, reliable, and manageable.

For each best practice, this article explains:

• What the best practice is.
• Why to implement the best practice.
• What might happen if you don't implement the best practice.
• How you can learn to implement the best practice.

Use the following Azure Service Fabric security best practices:

• Use Azure Resource Manager templates and the Service Fabric PowerShell module to create secure clusters.
• Use X.509 certificates.
• Configure security policies.
• Implement the Reliable Actors security configuration.
• Configure TLS for Azure Service Fabric.
• Use network isolation and security with Azure Service Fabric.
• Configure Azure Key Vault for security.
• Assign users to roles.
• Host untrusted applications in a Service Fabric cluster.

Best practices for securing your clusters

Always use a secure cluster:

• Implement cluster security by using certificates.
• Provide client access (admin and read-only) by using Microsoft Entra ID.

Use automated deployments:

• Use scripts to generate, deploy, and roll over the secrets.
• Store the secrets in Azure Key Vault and use Microsoft Entra ID for all other client access.
• Require authentication for human access to the secrets.

Also, consider the following configuration options:

• Create perimeter networks (also known as demilitarized zones, DMZs, and screened subnets) by using Azure Network Security Groups (NSGs).
• Access cluster virtual machines (VMs) or manage your cluster by using jump servers with Remote Desktop Connection.

Secure your clusters to prevent unauthorized users from connecting, especially when a cluster is running in production. Although it's possible to create an unsecured cluster, anonymous users can connect to your cluster if the cluster exposes management endpoints to the public internet.

There are three scenarios for implementing cluster security by using various technologies:

• Node-to-node security: This scenario secures communication between the VMs and the computers in the cluster. This form of security ensures that only computers authorized to join the cluster can host applications and services in the cluster. In this scenario, the clusters that run on Azure, or standalone clusters that run on Windows, can use either certificate security or Windows security for Windows Server machines.
• Client-to-node security: This scenario secures communication between a Service Fabric client and the individual nodes in the cluster.
• Service Fabric role-based access control (Service Fabric RBAC): This scenario uses separate identities (certificates, Microsoft Entra ID, and so on) for each administrator and user client role that accesses the cluster. You specify the role identities when you create the cluster.

To configure a standalone Windows cluster, see Configure settings for a standalone Windows cluster.

Use Azure Resource Manager templates and the Service Fabric PowerShell module to create a secure cluster. For step-by-step instructions to create a secure Service Fabric cluster with Azure Resource Manager templates, see Create a Service Fabric cluster.

Use the Azure Resource Manager template:

• Customize your cluster by using the template to configure managed storage for VM virtual hard disks (VHDs).
• Drive changes to your resource group by using the template for easy configuration management and auditing.

Treat your cluster configuration as code:

• Be thorough when checking your deployment configurations.
• Don't use implicit commands to directly modify your resources.

You can automate many aspects of the Service Fabric application lifecycle. The Service Fabric PowerShell module automates common tasks for deploying, upgrading, removing, and testing Azure Service Fabric applications. Managed APIs and HTTP APIs for application management are also available.

Use X.509 certificates

Best practice: Always secure your clusters by using X.509 certificates or Windows security. Detail: Configure security only at cluster creation time. You can't turn on security after you create the cluster.

To specify a cluster certificate, set the value of the ClusterCredentialType property to X509. To specify a server certificate for outside connections, set the ServerCredentialType property to X509.

In addition, follow these practices:

• Create the certificates for production clusters by using a correctly configured Windows Server certificate service. You can also obtain the certificates from an approved certificate authority (CA).
• Never use a temporary or test certificate for production clusters if you created the certificate by using MakeCert.exe or a similar tool.
• Use a self-signed certificate for test clusters, but not for production clusters.

If the cluster isn't secure, anyone can connect to the cluster anonymously and perform management operations. For this reason, always secure production clusters by using X.509 certificates or Windows security.

To learn more about using X.509 certificates, see Add or remove certificates for a Service Fabric cluster.

Configure security policies

Service Fabric also secures the resources that applications use. Service Fabric stores resources like files, directories, and certificates under the user accounts when the application deploys. This feature makes running applications more secure from one another, even in a shared hosted environment.

• Use an Active Directory domain group or user: Run the service under the credentials for an Active Directory user or group account. Be sure to use Active Directory on-premises within your domain and not Microsoft Entra ID. Access other resources in the domain with permissions granted to a domain user or group. For example, resources such as file shares.

• Assign a security access policy for HTTP and HTTPS endpoints: Specify the SecurityAccessPolicy property to apply a RunAs policy to a service when the service manifest declares endpoint resources with HTTP. Ports allocated to the HTTP endpoints are correctly access-controlled lists for the RunAs user account that the service runs under. When the policy isn't set, http.sys doesn't have access to the service and you can get failures with calls from the client.

To learn how to use security policies in a Service Fabric cluster, see Configure security policies for your application.

Implement the Reliable Actors security configuration

Service Fabric Reliable Actors is an implementation of the actor design pattern. As with any software design pattern, the decision to use a specific pattern is based on whether a software problem fits the pattern.

In general, use the actor design pattern to help model solutions for the following software problems or security scenarios:

• Your problem space involves a large number (thousands or more) of small, independent, and isolated units of state and logic.
• You're working with single-threaded objects that don't require significant interaction from external components, including querying state across a set of actors.
• Your actor instances don't block callers with unpredictable delays by issuing I/O operations.

In Service Fabric, the Reliable Actors application framework implements actors. This framework is based on the actor pattern and built on top of Service Fabric Reliable Services. Each reliable actor service that you write runs as a partitioned stateful reliable service.

Every actor is an instance of an actor type, identical to the way a .NET object is an instance of a .NET type. For example, an actor type that implements the functionality of a calculator can have many actors of that type distributed on various nodes across a cluster. An actor identifier uniquely characterizes each distributed actor.

Use replicator security configurations to secure the communication channel that replication uses. This configuration prevents services from seeing each other's replication traffic and ensures that highly available data is secure. By default, an empty security configuration section prevents replication security.

Replicator configurations configure the replicator responsible for making the Actor State Provider state highly reliable.

Configure TLS for Azure Service Fabric

The server authentication process authenticates the cluster management endpoints to a management client. The management client then recognizes that it's talking to the real cluster. This certificate also provides TLS for the HTTPS management API and for Service Fabric Explorer over HTTPS. You must obtain a custom domain name for your cluster. When you request a certificate from a certificate authority, the certificate's subject name must match the custom domain name that you use for your cluster.

To configure TLS for an application, first obtain an SSL/TLS certificate that a CA signs. The CA is a trusted third party that issues certificates for TLS security purposes. If you don't already have an SSL/TLS certificate, obtain one from a company that sells SSL/TLS certificates.

The certificate must meet the following requirements for SSL/TLS certificates in Azure:

• The certificate must contain a private key.

• Create the certificate for key exchange and make it exportable to a personal information exchange (.pfx) file.

• The certificate's subject name must match the domain name used to access your cloud service.

  • Acquire a custom domain name to use for accessing your cloud service.
  • Request a certificate from a CA with a subject name that matches your service's custom domain name. For example, if your custom domain name is contoso.com, the certificate from your CA should have the subject name .contoso.com or www.contoso.com.

  Note

  You can't obtain an SSL/TLS certificate from a CA for the cloudapp.net domain.

• The certificate must use a minimum of 2,048-bit encryption.

The HTTP protocol isn't secure and is subject to eavesdropping attacks. The web browser sends data transmitted over HTTP as plain text to the web server or between other endpoints. Attackers can intercept and view sensitive data sent through HTTP, such as credit card details and account logins. When a browser sends or posts data by using HTTPS, SSL encrypts sensitive information and keeps it secure from interception.

To learn more about using SSL/TLS certificates, see Configuring TLS for an application in Azure.

Use network isolation and security with Azure Service Fabric

Best practice: Set up a secure cluster with network isolation. Detail: Use Azure Resource Manager templates to set up a three-node-type secure cluster. Control the inbound and outbound network traffic by using the template and Network Security Groups.

The template has an NSG for each virtual machine scale set and controls traffic in and out of the set. The rules allow all traffic necessary by default for the system services and the application ports specified in the template. Review these rules and make any changes to fit your needs, including adding new rules for your applications.

For more information, see Common networking scenarios for Azure Service Fabric.

Set up Azure Key Vault for security

Best practice: Use Azure Key Vault to manage certificates for Service Fabric clusters. Detail: Service Fabric uses X.509 certificates to secure a cluster and to provide application security features. Use Azure Key Vault to manage certificates for Service Fabric clusters in Azure. The Azure resource provider that creates the clusters pulls the certificates from a key vault. The provider then installs the certificates on the VMs when Azure deploys the cluster.

A certificate relationship exists between Azure Key Vault, the Service Fabric cluster, and the resource provider that uses the certificates. When Azure creates the cluster, it stores information about the certificate relationship in a key vault.

There are two basic steps to set up a key vault:

1. Create a resource group specifically for your key vault.

   Put the key vault in its own resource group. This action helps prevent the loss of your keys and secrets if Azure removes other resource groups, such as storage, compute, or the group that contains your cluster. The resource group that contains your key vault must be in the same region as the cluster that uses it.

2. Create a key vault in the new resource group.

   Enable the key vault for deployment. The compute resource provider can then get the certificates from the vault and install them on the VM instances.

To learn more about how to set up a key vault, see What is Azure Key Vault?

Assign users to roles

Best practice: Assign users to the roles supported by Service Fabric. Detail: After you create the applications to represent your cluster, assign your users to the read-only and admin roles. Use the Azure portal to assign these roles.

Azure Service Fabric supports two access control types for clients that connect to a Service Fabric cluster: administrator and user. The cluster administrator can use access control to limit access to certain cluster operations for different groups of users. Access control makes the cluster more secure.

Considerations for hosting untrusted applications in a Service Fabric cluster

See Hosting untrusted applications in a Service Fabric cluster.

Next steps

• Service Fabric security checklist
• Set up your Service Fabric development environment.
• Learn about Service Fabric support options.