Merge pull request #188896 from shsha-msft/dev/shsha/ServiceFabricRuntimeAccess

RemoveServiceFabricRuntimeAccess: Isolate the cluster and its trusted…

Author: PRMerger20

articles/security/fundamentals/service-fabric-best-practices.md

@@ -9,6 +9,8 @@ ms.topic: article
 ms.date: 01/16/2019
 ---
 # Azure Service Fabric security best practices
+In addition to this article, please also review [Service Fabric security checklist](../../service-fabric/service-fabric-best-practices-security.md) for more information.
+
 Deploying an application on Azure is fast, easy, and cost-effective. Before you deploy your cloud application into production, review our 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.
@@ -30,6 +32,7 @@ We recommend the following Azure Service Fabric security best practices:
 -	Use network isolation and security with Azure Service Fabric.
 -	Configure Azure Key Vault for security.
 -	Assign users to roles.
+-	Things to consider if hosting untrusted applications in a Service Fabric cluster.
 
 
 ## Best practices for securing your clusters
@@ -172,8 +175,11 @@ After you've created the applications to represent your cluster, assign your use
 
 Azure Service Fabric supports two access control types for clients that are connected to a [Service Fabric cluster](../../service-fabric/service-fabric-cluster-creation-via-arm.md): 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.
 
+## Things to consider if hosting untrusted applications in a Service Fabric cluster
+Please see [Hosting untrusted applications in a Service Fabric cluster](../../service-fabric/service-fabric-best-practices-security.md#hosting-untrusted-applications-in-a-service-fabric-cluster).
+
 ## Next steps
 
 - [Service Fabric security checklist](../../service-fabric/service-fabric-best-practices-security.md)
 - Set up your Service Fabric [development environment](../../service-fabric/service-fabric-get-started.md).
-- Learn about [Service Fabric support options](../../service-fabric/service-fabric-support.md).
+- Learn about [Service Fabric support options](../../service-fabric/service-fabric-support.md).

articles/service-fabric/service-fabric-application-and-service-manifests.md

@@ -157,8 +157,8 @@ Within the ServiceManifestImport, you override configuration values in Settings.
 
 **Policies** (not set in the preceding example) describes the log collection, [default run-as](service-fabric-application-runas-security.md), [health](service-fabric-health-introduction.md#health-policies), and [security access](service-fabric-application-runas-security.md) policies to set at the application level, including whether the service(s) have access to the Service Fabric runtime.
 
-> [!NOTE] 
-> By default, Service Fabric applications have access to the Service Fabric runtime, in the form of an endpoint accepting application-specific requests, and environment variables pointing to file paths on the host containing Fabric and application-specific files. Consider disabling this access when the application hosts untrusted code (i.e. code whose provenance is unknown, or which the application owner knows not to be safe to execute). For more information, please see [security best practices in Service Fabric](service-fabric-best-practices-security.md#platform-isolation). 
+> [!NOTE]
+> A Service Fabric cluster is single tenant by design and hosted applications are considered **trusted**. If you are considering hosting **untrusted applications**, please see [Hosting untrusted applications in a Service Fabric cluster](service-fabric-best-practices-security.md#hosting-untrusted-applications-in-a-service-fabric-cluster).
 >
 
 **Principals** (not set in the preceding example) describe the security principals (users or groups) required to [run services and secure service resources](service-fabric-application-runas-security.md).  Principals are referenced in the **Policies** sections.

articles/service-fabric/service-fabric-best-practices-security.md

@@ -254,8 +254,17 @@ By default, Windows Defender antivirus is installed on Windows Server 2016. For
 > Refer to your Antimalware documentation for configuration rules if you are not using Windows Defender. 
 > Windows Defender isn't supported on Linux.
 
-## Platform Isolation
-By default, Service Fabric applications are granted access to the Service Fabric runtime itself, which manifests itself in different forms: [environment variables](service-fabric-environment-variables-reference.md) pointing to file paths on the host corresponding to application and Fabric files, an inter-process communication endpoint which accepts application-specific requests, and the client certificate which Fabric expects the application to use to authenticate itself. In the eventuality that the service hosts itself untrusted code, it is advisable to disable this access to the SF runtime - unless explicitly needed. Access to the runtime is removed using the following declaration in the Policies section of the application manifest: 
+## Hosting untrusted applications in a Service Fabric cluster
+A Service Fabric cluster is single tenant by design and hosted applications are considered **trusted**. Applications are, therefore, granted access to the Service Fabric runtime, which manifests in different forms, some of which are: [environment variables](service-fabric-environment-variables-reference.md) pointing to file paths on the host corresponding to application and Fabric files, host paths mounted with write access onto container workloads, an inter-process communication endpoint which accepts application-specific requests, and the client certificate which Fabric expects the application to use to authenticate itself.
+
+If you are considering hosting **untrusted applications**, you must take additional steps to define and own the hostile multi-tenant experience for your Service Fabric cluster. This will require you to consider multiple aspects, in the context of your scenario, including, but not limited to, the following:
+* A thorough security review of the untrusted applications' interactions with other applications, the cluster itself, and the underlying compute infrastructure.
+* Use of the strongest sandboxing technology applicable (e.g., appropriate [isolation modes](/virtualization/windowscontainers/manage-containers/hyperv-container.md) for container workloads).
+* Risk assessment of the untrusted applications escaping the sandboxing technology, as the next trust and security boundary is the cluster itself.
+* Removal of the untrusted applications' [access to Service Fabric runtime](service-fabric-service-model-schema-complex-types.md#servicefabricruntimeaccesspolicytype-complextype).
+
+### RemoveServiceFabricRuntimeAccess
+Access to Service Fabric runtime can be removed by using the following declaration in the Policies section of the application manifest: 
 
 ```xml
 <ServiceManifestImport>

articles/service-fabric/service-fabric-containers-overview.md

@@ -74,6 +74,9 @@ Service Fabric supports the deployment of Docker containers on Linux, and Window
 > [!NOTE]
 > Containers are not supported on local single node Service Fabric clusters (neither Linux clusters on OneBox, nor Windows clusters on local Service Fabric installations).
 
+> [!NOTE]
+> A Service Fabric cluster is single tenant by design and hosted applications are considered **trusted**. If you are considering hosting **untrusted applications**, please see [Hosting untrusted applications in a Service Fabric cluster](service-fabric-best-practices-security.md#hosting-untrusted-applications-in-a-service-fabric-cluster).
+
 Service Fabric provides an [application model](service-fabric-application-model.md) in which a container represents an application host in which multiple service replicas are placed. Service Fabric also supports a [guest executable scenario](service-fabric-guest-executables-introduction.md) in which you don't use the built-in Service Fabric programming models but instead package an existing application, written using any language or framework, inside a container. This scenario is the common use-case for containers.
 
 You can also run [Service Fabric services inside a container](service-fabric-services-inside-containers.md). Support for running Service Fabric services inside containers is currently limited.

articles/service-fabric/service-fabric-guest-executables-introduction.md

@@ -10,6 +10,9 @@ You can run any type of code, such as Node.js, Java, or C++ in Azure Service Fab
 
 Guest executables are treated by Service Fabric like stateless services. As a result, they are placed on nodes in a cluster, based on availability and other metrics. This article describes how to package and deploy a guest executable to a Service Fabric cluster, by using Visual Studio or a command-line utility.
 
+> [!NOTE]
+> A Service Fabric cluster is single tenant by design and hosted applications are considered **trusted**. If you are considering hosting **untrusted applications**, please see [Hosting untrusted applications in a Service Fabric cluster](service-fabric-best-practices-security.md#hosting-untrusted-applications-in-a-service-fabric-cluster).
+
 ## Benefits of running a guest executable in Service Fabric
 There are several advantages to running a guest executable in a Service Fabric cluster:
 

articles/service-fabric/service-fabric-services-inside-containers.md

@@ -105,14 +105,8 @@ This document provides guidance to get your service running inside a Windows con
    </Policies>
    ```
 
-> [!NOTE] 
-> By default, Service Fabric applications have access to the Service Fabric runtime, in the form of an endpoint accepting application-specific requests. Consider disabling this access when the application hosts untrusted code. For more information, please see [security best practices in Service Fabric](service-fabric-best-practices-security.md#platform-isolation). To disable access to the Service Fabric runtime, add the following setting in the Policies section of the application manifest corresponding to the imported service manifest, as follows:
->
-```xml
-  <Policies>
-      <ServiceFabricRuntimeAccessPolicy RemoveServiceFabricRuntimeAccess="true"/>
-  </Policies>
-```
+> [!NOTE]
+> A Service Fabric cluster is single tenant by design and hosted applications are considered **trusted**. If you are considering hosting **untrusted container applications**, consider deploying them as [guest containers](service-fabric-containers-overview.md#service-fabric-support-for-containers) and please see [Hosting untrusted applications in a Service Fabric cluster](service-fabric-best-practices-security.md#hosting-untrusted-applications-in-a-service-fabric-cluster).
 >
 
 10. To test this application, you need to deploy it to a cluster that is running version 5.7 or higher. For runtime versions 6.1 or lower, you need to edit and update the cluster settings to enable this preview feature. Follow the steps in this [article](service-fabric-cluster-fabric-settings.md) to add the setting shown next.
@@ -134,4 +128,4 @@ You should now have a containerized Service Fabric application running your clus
 
 ## Next steps
 * Learn more about running [containers on Service Fabric](service-fabric-get-started-containers.md).
-* Learn about the Service Fabric [application life-cycle](service-fabric-application-lifecycle.md).
+* Learn about the Service Fabric [application life-cycle](service-fabric-application-lifecycle.md).