Merge pull request #106838 from jluk/master

Update hardened OS doc wording & update multi nodepool: subnet per pool

Author: v-shils

articles/aks/security-hardened-vm-host-image.md

@@ -2,37 +2,36 @@
 title: Security hardening in AKS virtual machine hosts 
 description: Learn about the security hardening in AKS VM host OS
 services: container-service
-author: saudas
+author: mlearned
 ms.topic: article
 ms.date: 09/11/2019
-ms.author: saudas
+ms.author: mlearned
 ms.custom: mvc
 ---
 
-# Security hardening in AKS virtual machine hosts 
+# Security hardening for AKS agent node host OS
 
 Azure Kubernetes Service (AKS) is a secure service compliant with SOC, ISO, PCI DSS, and HIPAA standards. This article covers the security hardening applied to AKS virtual machine hosts. For more information about AKS security, see [Security concepts for applications and clusters in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/azure/aks/concepts-security).
 
-AKS clusters are deployed on host virtual machines, which run a security optimized OS. This host OS is currently based on an Ubuntu 16.04.LTS image with a set of additional security hardening steps applied (see Security hardening details).   
+> [!Note]
+> This document is scoped to Linux agents in AKS only.
 
-The goal of the security hardened host OS is to reduce the surface area of attack and allow the deployment of containers in a secure fashion. 
+AKS clusters are deployed on host virtual machines, which run a security optimized OS which is utilized for containers running on AKS. This host OS is based on an **Ubuntu 16.04.LTS** image with additional security hardening and optimizations applied (see Security hardening details).
+
+The goal of the security hardened host OS is to reduce the surface area of attack and optimize for the deployment of containers in a secure manner.
 
 > [!Important]
-> The security hardened OS is NOT CIS benchmarked. While there are overlaps with CIS benchmarks, the goal is not to be CIS-compliant. The goal for host OS hardening is to converge on a level of security consistent with Microsoft’s own internal host security standards. 
+> The security hardened OS is NOT CIS benchmarked. While there are overlaps with CIS benchmarks, the goal is not to be CIS-compliant. The goal for host OS hardening is to converge on a level of security consistent with Microsoft's own internal host security standards.
 
-## Security hardening features 
+## Security hardening features
 
-* AKS provides a security optimized host OS by default. There is no current option to select an alternate operating system. 
+* AKS provides a security optimized host OS by default. There is no option to select an alternate operating system.
 
 * Azure applies daily patches (including security patches) to AKS virtual machine hosts. Some of these patches will require a reboot, while others will not. You are responsible for scheduling AKS VM host reboots as needed. For guidance on how to automate AKS patching see [patching AKS nodes](https://docs.microsoft.com/azure/aks/node-updates-kured).
 
-Below is a summary of image hardening work that is implemented in AKS-Engine to produce the security optimized host OS. The work was implemented [in this GitHub project](https://github.com/Azure/aks-engine/projects/7).  
-
-AKS-Engine does not promote or adhere to any specific security standard at this time, but CIS (Center for Internet Security) audit IDs are provided for convenience where applicable. 
-
-## What's configured?
+## What is configured
 
-| CIS  | Audit description| 
+| CIS  | Audit description|
 |---|---|
 | 1.1.1.1 |Ensure mounting of cramfs filesystems is disabled|
 | 1.1.1.2 |Ensure mounting of freevxfs filesystems is disabled|
@@ -73,9 +72,9 @@ AKS-Engine does not promote or adhere to any specific security standard at this
 
 ## Additional notes
 
-* To further reduce the attack surface area, some unnecessary kernel module drivers have been disabled in the OS. 
+* To further reduce the attack surface area, some unnecessary kernel module drivers have been disabled in the OS.
 
-* The security hardened OS is NOT supported outside of the AKS platform. 
+* The security hardened OS is built and maintained specifically for AKS and is NOT supported outside of the AKS platform.
 
 ## Next steps  
 

articles/aks/use-multiple-node-pools.md

@@ -29,8 +29,8 @@ The following limitations apply when you create and manage AKS clusters that sup
 * The AKS cluster must use the Standard SKU load balancer to use multiple node pools, the feature is not supported with Basic SKU load balancers.
 * The AKS cluster must use virtual machine scale sets for the nodes.
 * The name of a node pool may only contain lowercase alphanumeric characters and must begin with a lowercase letter. For Linux node pools the length must be between 1 and 12 characters, for Windows node pools the length must be between 1 and 6 characters.
-* All node pools must reside in the same virtual network and subnet.
-* When creating multiple node pools at cluster create time, all Kubernetes versions used by node pools must match the version set for the control plane. This version can be updated after the cluster has been provisioned by using per node pool operations.
+* All node pools must reside in the same virtual network.
+* When creating multiple node pools at cluster create time, all Kubernetes versions used by node pools must match the version set for the control plane. This can be updated after the cluster has been provisioned by using per node pool operations.
 
 ## Create an AKS cluster
 
@@ -117,6 +117,29 @@ The following example output shows that *mynodepool* has been successfully creat
 > [!TIP]
 > If no *VmSize* is specified when you add a node pool, the default size is *Standard_DS2_v3* for Windows node pools and *Standard_DS2_v2* for Linux node pools. If no *OrchestratorVersion* is specified, it defaults to the same version as the control plane.
 
+### Add a node pool with a unique subnet (preview)
+
+A workload may require splitting a cluster's nodes into separate pools for logical isolation. This isolation can be supported with separate subnets dedicated to each node pool in the cluster. This can address requirements such as having non-contiguous virtual network address space to split across node pools.
+
+#### Limitations
+
+* All subnets assigned to nodepools must belong to the same virtual network.
+* System pods must have access to all nodes in the cluster to provide critical functionality such as DNS resolution via coreDNS.
+* Assignment of a unique subnet per node pool is limited to Azure CNI during preview.
+* Using network policies with a unique subnet per node pool is not supported during preview.
+
+To create a node pool with a dedicated subnet, pass the subnet resource ID as an additional parameter when creating a node pool.
+
+```azurecli-interactive
+az aks nodepool add \
+    --resource-group myResourceGroup \
+    --cluster-name myAKSCluster \
+    --name mynodepool \
+    --node-count 3 \
+    --kubernetes-version 1.15.5
+    --vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>
+```
+
 ## Upgrade a node pool
 
 > [!NOTE]
@@ -691,18 +714,22 @@ az group deployment create \
 
 It may take a few minutes to update your AKS cluster depending on the node pool settings and operations you define in your Resource Manager template.
 
-## Assign a public IP per node in a node pool
+## Assign a public IP per node for a node pool (preview)
 
 > [!WARNING]
 > During the preview of assigning a public IP per node, it cannot be used with the *Standard Load Balancer SKU in AKS* due to possible load balancer rules conflicting with VM provisioning. As a result of this limitation, Windows agent pools are not supported with this preview feature. While in preview you must use the *Basic Load Balancer SKU* if you need to assign a public IP per node.
 
-AKS nodes do not require their own public IP addresses for communication. However, some scenarios may require nodes in a node pool to have their own public IP addresses. An example is gaming, where a console needs to make a direct connection to a cloud virtual machine to minimize hops. This scenario can be achieved by registering for a separate preview feature, Node Public IP (preview).
+AKS nodes do not require their own public IP addresses for communication. However, scenarios may require nodes in a node pool to receive their own dedicated public IP addresses. An common scenario is for gaming workloads, where a console needs to make a direct connection to a cloud virtual machine to minimize hops. This scenario can be achieved on AKS by registering for a preview feature, Node Public IP (preview).
+
+Register for the Node Public IP feature by issuing the following Azure CLI command.
 
 ```azurecli-interactive
 az feature register --name NodePublicIPPreview --namespace Microsoft.ContainerService
 ```
 
-After successful registration, deploy an Azure Resource Manager template following the same instructions as [above](#manage-node-pools-using-a-resource-manager-template) and add the boolean value property `enableNodePublicIP` to agentPoolProfiles. Set the value to `true` as by default it is set as `false` if not specified. This property is a create-time only property and requires a minimum API version of 2019-06-01. This can be applied to both Linux and Windows node pools.
+After successful registration, deploy an Azure Resource Manager template following the same instructions as [above](#manage-node-pools-using-a-resource-manager-template) and add the boolean property `enableNodePublicIP` to agentPoolProfiles. Set the value to `true` as by default it is set as `false` if not specified. 
+
+This property is a create-time only property and requires a minimum API version of 2019-06-01. This can be applied to both Linux and Windows node pools.
 
 ## Clean up resources