Skip to content

Commit

Permalink
Merge branch 'securityupdates' of https://github.com/rwike77/azure-co…
Browse files Browse the repository at this point in the history
…ntent-pr into securityupdates
  • Loading branch information
rwike77 committed Jul 11, 2016
2 parents 592c638 + 48b8bfa commit aaf997c
Show file tree
Hide file tree
Showing 7 changed files with 347 additions and 110 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
ms.topic="article"
ms.tgt_pltfrm="NA"
ms.workload="NA"
ms.date="02/12/2016"
ms.date="07/05/2016"
ms.author="mfussell"/>

# Service Fabric application scenarios
Expand Down

Large diffs are not rendered by default.

42 changes: 35 additions & 7 deletions articles/service-fabric/service-fabric-cluster-security.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,37 +13,65 @@
ms.topic="article"
ms.tgt_pltfrm="na"
ms.workload="na"
ms.date="06/01/2016"
ms.date="07/08/2016"
ms.author="chackdan"/>

# Service Fabric cluster security scenarios

A Service Fabric cluster is a resource that you own. To prevent unauthorized access to the resource, you must secure it, especially when it has production workloads running on it. This article provides an overview of the security scenarios for clusters running on Azure and Windows server and the various technologies used to implement those scenarios. The cluster security scenarios are:
A Service Fabric cluster is a resource that you own. To prevent unauthorized access to the resource, you must secure it, especially when it has production workloads running on it. This article provides an overview of the security scenarios for clusters running on Azure or standalone and the various technologies used to implement those scenarios. The cluster security scenarios are:

- Node-to-node security
- Client-to-node security
- Role based access control (RBAC)

## Node-to-node security
Secures communication between the VMs and computers in the cluster. This ensures that only computers that are authorized to join the cluster can participate in hosting applications and services in the cluster.
Secures communication between the VMs or machines in the cluster. This ensures that only computers that are authorized to join the cluster can participate in hosting applications and services in the cluster.

![Diagram of node-to-node communication][Node-to-Node]

Clusters running on Azure or standalone clusters running on Windows can use either [Certificate Security](https://msdn.microsoft.com/library/ff649801.aspx) or [Windows Security](https://msdn.microsoft.com/library/ff649396.aspx). Certificate security is configured while creating the cluster (either through the Azure Portal or through ARM templates) by specifying a primary certificate and an optional secondary certificate. The primary and secondary certificates you specify should be different than the admin client and read-only client certificates you specify for [Client-to-node security](#client-to-node-security). See [Secure a Service Fabric cluster on Azure using certificates](service-fabric-secure-azure-cluster-with-certs.md) or [Set up a cluster by using an ARM template](service-fabric-cluster-creation-via-arm.md) to learn how to configure certificate security in a cluster running on Azure.
Clusters running on Azure or standalone clusters running on Windows can use either [Certificate Security](https://msdn.microsoft.com/library/ff649801.aspx) or [Windows Security](https://msdn.microsoft.com/library/ff649396.aspx) for Windows Server machines.
### Node-to-node certificate security
Service Fabric uses X.509 server certificates that you specify as a part of the node-type configurations when you create a cluster. A quick overview of what these certificates are and how you can acquire or create them is provided at the end of this article.

Certificate security is configured while creating the cluster either through the Azure Portal, ARM templates or a stanalone JSON template. You can specify a primary certificate and an optional secondary certificate which is used for certificate rollovers. The primary and secondary certificates you specify should be different than the admin client and read-only client certificates you specify for [Client-to-node security](#client-to-node-security).

For Azure read [Secure a Service Fabric cluster on Azure using certificates](service-fabric-secure-azure-cluster-with-certs.md) or [Set up a cluster by using an Azure Resource Manager template](service-fabric-cluster-creation-via-arm.md) to learn how to configure certificate security in a cluster.

For standalone Windows Server read [Secure a standalone cluster on Windows using X.509 certificates ](service-fabric-windows-cluster-x509-security.md)

### Node-to-node windows security
For standalone Windows Server read [Secure a standalone cluster on Windows using Windows security](service-fabric-windows-cluster-windows-security.md)

## Client-to-node security
Authenticates clients and secures communication between a client and individual nodes in the cluster. This type of security authenticates and secures client communications, which ensures that only authorized users can access the cluster and the applications deployed on the cluster. Clients are uniquely identified through either their Windows Security credentials or their certificate security credentials.

![Diagram of client-to-node communication][Client-to-Node]

Clusters running on Azure or standalone clusters running on Windows can use either [Certificate Security](https://msdn.microsoft.com/library/ff649801.aspx) or [Windows Security](https://msdn.microsoft.com/library/ff649396.aspx). Client-to-node certificate security is configured while creating the cluster (either through the Azure Portal or through ARM templates) by specifying a admin client certificate and/or a read-only client certificate. The admin client and read-only client certificates you specify should be different than the primary and secondary certificates you specify for [Node-to-node security](#node-to-node-security). Clients connecting to the cluster using the admin certificate or the primary certificate have full access to management capabilities. Clients connecting to the cluster using the read-only client certificate have only read access to management capabilities. See [Secure a Service Fabric cluster on Azure using certificates](service-fabric-secure-azure-cluster-with-certs.md) or [Set up a cluster by using an ARM template](service-fabric-cluster-creation-via-arm.md) to learn how to configure certificate security in a cluster running on Azure.
Clusters running on Azure or standalone clusters running on Windows can use either [Certificate Security](https://msdn.microsoft.com/library/ff649801.aspx) or [Windows Security](https://msdn.microsoft.com/library/ff649396.aspx).

Service Fabric uses X.509 server certificates that you specify as a part of the node-type configurations when you create a cluster. A quick overview of what these certificates are and how you can acquire or create them is provided at the end of this article.
### Client-to-node certificate security
Client-to-node certificate security is configured while creating the cluster either through the Azure Portal, ARM templates or a stanalone JSON template by specifying an admin client certificate and/or a user client certificate. The admin client and user client certificates you specify should be different than the primary and secondary certificates you specify for [Node-to-node security](#node-to-node-security).

Clients connecting to the cluster using the admin certificate have full access to management capabilities. Clients connecting to the cluster using the read-only user client certificate have only read access to management capabilities. In other words these certificates are used for the role bases access control (RBAC) described below.

For Azure read [Secure a Service Fabric cluster on Azure using certificates](service-fabric-secure-azure-cluster-with-certs.md) or [Set up a cluster by using an Azure Resource Manager template](service-fabric-cluster-creation-via-arm.md) to learn how to configure certificate security in a cluster.

For standalone Windows Server read [Secure a standalone cluster on Windows using X.509 certificates ](service-fabric-windows-cluster-x509-security.md)

### Client-to-node Azure Active Directory (AAD) security on Azure
Clusters running on Azure can also secure access to the management endpoints using Azure Active Directory (AAD). See [Create a Service Fabric cluster using Azure Active Directory for client authentication](service-fabric-cluster-security-client-auth-with-aad.md) for information on how to create the necessary AAD artifacts, how to populate them during cluster creation, and how to connect to those clusters afterwards.

## Security Recommendations
For Azure clusters it is recommended that you use AAD security to authenticate clients and certificates for node-to-node security.

For standalone Windows Server clusters it is recommended that you use Windows security with group managed acounts (gMA) if you have Windows Server 2012 R2 and Active Directory. Otherwise still use Windows security with Windows accounts.

## Role based access control (RBAC)
Access control allows the cluster administrator to limit access to certain cluster operations for different groups of users, making the cluster more secure. Two different access control types are supported for clients connecting to a cluster: administrator and user. Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services. You specify the administrator and user client roles at the time of cluster creation by providing separate certificates for each. For more information on the default access control settings and how to change the default settings, see [Role based access control for clients](service-fabric-cluster-security-roles.md).
Access control allows the cluster administrator to limit access to certain cluster operations for different groups of users, making the cluster more secure. Two different access control types are supported for clients connecting to a cluster: Administrator role and User role.

Administrators have full access to management capabilities (including read/write capabilities). Users, by default, have only read access to management capabilities (for example, query capabilities), and the ability to resolve applications and services.

You specify the administrator and user client roles at the time of cluster creation by providing separate identities (certificates, AAD etc) for each. For more information on the default access control settings and how to change the default settings, see [Role based access control for Service Fabric clients](service-fabric-cluster-security-roles.md).


## X.509 certificates and Service Fabric
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,8 @@
ms.topic="article"
ms.tgt_pltfrm="NA"
ms.workload="NA"
ms.date="04/18/2016"
ms.author="mfussell"/>
ms.date="07/05/2016"
ms.author="vturecek"/>

# Connect and communicate with services in Service Fabric
In Service Fabric, a service runs somewhere in a Service Fabric cluster, typically distributed across multiple VMs. It can be moved from one place to another, either by the service owner, or automatically by Service Fabric. Services are not statically tied to a particular machine or address.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
ms.topic="article"
ms.tgt_pltfrm="NA"
ms.workload="NA"
ms.date="03/24/2016"
ms.date="07/05/2016"
ms.author="mfussell"/>

# Why a microservices approach to building applications?
Expand Down Expand Up @@ -151,5 +151,6 @@ The objective of Service Fabric is to reduce the complexities of building applic
* [Overview of Service Fabric](service-fabric-overview.md)
* [Microservices: An application revolution powered by the cloud](https://azure.microsoft.com/en-us/blog/microservices-an-application-revolution-powered-by-the-cloud/)


[Image1]: media/service-fabric-overview-microservices/monolithic-vs-micro.png
[Image2]: media/service-fabric-overview-microservices/statemonolithic-vs-micro.png
4 changes: 2 additions & 2 deletions articles/service-fabric/service-fabric-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@
ms.topic="article"
ms.tgt_pltfrm="NA"
ms.workload="NA"
ms.date="03/24/2016"
ms.date="07/05/2016"
ms.author="mfussell"/>

# Overview of Service Fabric
Expand Down Expand Up @@ -41,7 +41,7 @@ For more on the microservices approach read [Why a microservices approach to bui
## Create Service Fabric clusters anywhere
You can create Service Fabric clusters in many environments to deploy your applications to. This can be in Azure or on premises, on Windows Server or on Linux. In addition the development environment in the SDK is identical to the production environment with no emulators involved. In other words, if it runs on your local development cluster it will deploy to the same cluster in other environments.

For more information read [Deploy anywhere on Windows Server or Linux with Service Fabric](service-fabric-deploy-anywhere.md)
For more information on creating clusters on-premise read [creating a cluster on Windows Server or Linux](service-fabric-deploy-anywhere.md) or for Azure creating a cluster [via the Azure Portal](service-fabric-cluster-creation-via-portal.md).

![Service Fabric platform][Image1]

Expand Down
Loading

0 comments on commit aaf997c

Please sign in to comment.