Run a service as a local user account or local system account
By using Azure Service Fabric, you can secure applications that are running in the cluster under different user accounts. By default, Service Fabric applications run under the account that the Fabric.exe process runs under. Service Fabric also provides the capability to run applications under a local user or system account. Supported local system account types are LocalUser, NetworkService, LocalService, and LocalSystem. If you're running Service Fabric on a Windows standalone cluster, you can run a service under Active Directory domain accounts or group managed service accounts.
In the application manifest, you define the user accounts required to run services or secure resources in the Principals section. You can also define and create user groups so that one or more users can be managed together. This is useful when there are multiple users for different service entry points and they need common privileges that are available at the group level. The users are then referenced in a RunAs policy, which is applied to a specific service or all the services in the application.
By default, the RunAs policy is applied to the main entry point. You can also apply a RunAs policy to the setup entry point, if you need to run certain high-privilege setup operations under a system account, or both main and setup entry points.
Note
If you apply a RunAs policy to a service and the service manifest declares endpoint resources with the HTTP protocol, you must specify a SecurityAccessPolicy. For more information, see Assign a security access policy for HTTP and HTTPS endpoints.
Run a service as a local user
You can create a local user that can be used to help secure a service within the application. When a LocalUser account type is specified in the principals section of the application manifest, Service Fabric creates local user accounts on machines where the application is deployed. By default, these accounts do not have the same names as those specified in the application manifest (for example, Customer3 in the following application manifest example). Instead, they are dynamically generated and have random passwords.
In the RunAsPolicy section for a ServiceManifestImport, specify the user account from the Principals section to run the service code package. The following example shows how to create a local user and apply a RunAs policy to the main entry point:
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer3" EntryPointType="Main" />
</Policies>
</ServiceManifestImport>
<DefaultServices>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Users>
<User Name="Customer3" />
</Users>
</Principals>
</ApplicationManifest>
Create a local user group
You can create user groups and add one or more users to the group. This is useful if there are multiple users for different service entry points and they need to have certain common privileges that are available at the group level. The following application manifest example shows a local group named LocalAdminGroup that has administrator privileges. Two users, Customer1 and Customer2, are made members of this local group. In the ServiceManifestImport section, a RunAs policy is applied to run the Stateful1Pkg code package as Customer2. Another RunAs policy is applied to run the Web1Pkg code package as Customer1.
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Stateful1_MinReplicaSetSize" DefaultValue="3" />
<Parameter Name="Stateful1_PartitionCount" DefaultValue="1" />
<Parameter Name="Stateful1_TargetReplicaSetSize" DefaultValue="3" />
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Stateful1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer2" EntryPointType="Main"/>
</Policies>
</ServiceManifestImport>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
<Policies>
<RunAsPolicy CodePackageRef="Code" UserRef="Customer1" EntryPointType="Main"/>
</Policies>
</ServiceManifestImport>
<DefaultServices>
<Service Name="Stateful1" ServicePackageActivationMode="ExclusiveProcess">
<StatefulService ServiceTypeName="Stateful1Type" TargetReplicaSetSize="[Stateful1_TargetReplicaSetSize]" MinReplicaSetSize="[Stateful1_MinReplicaSetSize]">
<UniformInt64Partition PartitionCount="[Stateful1_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
</StatefulService>
</Service>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Groups>
<Group Name="LocalAdminGroup">
<Membership>
<SystemGroup Name="Administrators" />
</Membership>
</Group>
</Groups>
<Users>
<User Name="Customer1">
<MemberOf>
<Group NameRef="LocalAdminGroup" />
</MemberOf>
</User>
<User Name="Customer2">
<MemberOf>
<Group NameRef="LocalAdminGroup" />
</MemberOf>
</User>
</Users>
</Principals>
</ApplicationManifest>
Apply a default policy to all service code packages
You use the DefaultRunAsPolicy section to specify a default user account for all code packages that don’t have a specific RunAsPolicy defined. If most of the code packages that are specified in the service manifest used by an application need to run under the same user, the application can just define a default RunAs policy with that user account. The following example specifies that if a code package does not have a RunAsPolicy specified, the code package should run under the MyDefaultAccount user specified in the principals section. Supported account types are LocalUser, NetworkService, LocalSystem, and LocalService. If using a local user or service, also specify the account name and password.
<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application7Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
<Parameters>
<Parameter Name="Web1_InstanceCount" DefaultValue="-1" />
</Parameters>
<ServiceManifestImport>
<ServiceManifestRef ServiceManifestName="Web1Pkg" ServiceManifestVersion="1.0.0" />
<ConfigOverrides />
</ServiceManifestImport>
<DefaultServices>
<Service Name="Web1" ServicePackageActivationMode="ExclusiveProcess">
<StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]">
<SingletonPartition />
</StatelessService>
</Service>
</DefaultServices>
<Principals>
<Users>
<User Name="MyDefaultAccount" AccountType="NetworkService" />
</Users>
</Principals>
<Policies>
<DefaultRunAsPolicy UserRef="MyDefaultAccount" />
</Policies>
</ApplicationManifest>
Debug a code package locally using console redirection
Occasionally, it's useful for debugging purposes to see the console output from a running service. You can set a console redirection policy on the entry point in the service manifest, which writes the output to a file. The file output is written to the application folder called log on the cluster node where the application is deployed and run.
Warning
Never use the console redirection policy in an application that is deployed in production because this can affect the application failover. Only use this for local development and debugging purposes.
The following service manifest example shows enabling console redirection with a FileRetentionCount value:
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>VotingWeb.exe</Program>
<WorkingFolder>CodePackage</WorkingFolder>
<ConsoleRedirection FileRetentionCount="10"/>
</ExeHost>
</EntryPoint>
</CodePackage>