Merge pull request #115061 from jluk/master

update outboundtype + uptime SLA wording + oss callout on best prac

Author: garycentric

articles/aks/developer-best-practices-pod-security.md

@@ -66,14 +66,17 @@ Work with your cluster operator to determine what security context settings you
 
 To limit the risk of credentials being exposed in your application code, avoid the use of fixed or shared credentials. Credentials or keys shouldn't be included directly in your code. If these credentials are exposed, the application needs to be updated and redeployed. A better approach is to give pods their own identity and way to authenticate themselves, or automatically retrieve credentials from a digital vault.
 
-The following [associated AKS open source projects][aks-associated-projects] let you automatically authenticate pods or request credentials and keys from a digital vault:
+### Use Azure Container Compute Upstream projects
 
-* Managed identities for Azure resources, and
-* [Azure Key Vault Provider for Secrets Store CSI Driver](https://github.com/Azure/secrets-store-csi-driver-provider-azure#usage)
+> [!IMPORTANT]
+> Associated AKS open source projects are not supported by Azure technical support. They are provided for users to self-install into clusters and gather feedback from our community.
 
-Associated AKS open source projects are not supported by Azure technical support. They are provided to gather feedback and bugs from our community. These projects are not recommended for production use.
+The following [associated AKS open source projects][aks-associated-projects] let you automatically authenticate pods or request credentials and keys from a digital vault. These projects are maintained by the Azure Container Compute Upstream team and are part of a [broader list of projects available for use](https://github.com/Azure/container-compute-upstream/blob/master/README.md#support).
 
-### Use pod managed identities
+ * [Azure Active Directory Pod Identity][aad-pod-identity]
+ * [Azure Key Vault Provider for Secrets Store CSI Driver](https://github.com/Azure/secrets-store-csi-driver-provider-azure#usage)
+
+#### Use pod managed identities
 
 A managed identity for Azure resources lets a pod authenticate itself against Azure services that support it, such as Storage or SQL. The pod is assigned an Azure Identity that lets them authenticate to Azure Active Directory and receive a digital token. This digital token can be presented to other Azure services that check if the pod is authorized to access the service and perform the required actions. This approach means that no secrets are required for database connection strings, for example. The simplified workflow for pod managed identity is shown in the following diagram:
 
@@ -83,7 +86,7 @@ With a managed identity, your application code doesn't need to include credentia
 
 For more information about pod identities, see [Configure an AKS cluster to use pod managed identities and with your applications][aad-pod-identity]
 
-### Use Azure Key Vault with Secrets Store CSI Driver
+#### Use Azure Key Vault with Secrets Store CSI Driver
 
 Using the pod identity project enables authentication against supporting Azure services. For your own services or applications without managed identities for Azure resources, you can still authenticate using credentials or keys. A digital vault can be used to store these secret contents.
 

articles/aks/egress-outboundtype.md

@@ -117,9 +117,6 @@ DEVSUBNET_NAME="${PREFIX}dev"
 Next, set subscription IDs.
 
 ```azure-cli
-# Get ARM Access Token and Subscription ID - This will be used for AuthN later.
-
-ACCESS_TOKEN=$(az account get-access-token -o tsv --query 'accessToken')
 
 # NOTE: Update Subscription Name
 # Set Default Azure Subscription to be Used via Subscription ID

articles/aks/uptime-sla.md

@@ -1,25 +1,25 @@
 ---
-title: Azure Kubernetes Service (AKS) high availability with Uptime SLA
-description: Learn about the optional high availability Uptime SLA offering for the Azure Kubernetes Service (AKS) API Server.
+title: Azure Kubernetes Service (AKS) with Uptime SLA
+description: Learn about the optional Uptime SLA offering for the Azure Kubernetes Service (AKS) API Server.
 services: container-service
 ms.topic: conceptual
 ms.date: 05/11/2020
 ---
 
 # Azure Kubernetes Service (AKS) Uptime SLA
 
-Uptime SLA is an optional feature to enable financially backed higher SLA for a cluster. Uptime SLA guarantees 99.95% availability of the Kubernetes API server endpoint for clusters that use [Availability Zone][availability-zones] and 99.9% of availability for clusters that don't use availability zones. AKS uses master node replicas across update and fault domains to ensure SLA requirements are met.
+Uptime SLA is an optional feature to enable a financially backed, higher SLA for a cluster. Uptime SLA guarantees 99.95% availability of the Kubernetes API server endpoint for clusters that use [Availability Zones][availability-zones] and 99.9% of availability for clusters that don't use Availability Zones. AKS uses master node replicas across update and fault domains to ensure SLA requirements are met.
 
-Customers needing SLA for compliance reasons or extending SLA's to their customers should turn on this feature. Customers with critical workloads who need higher availability with an option of SLA benefit from enabling this feature. Enable the feature with Availability Zones to obtain higher availability of the Kubernetes API server.  
+Customers needing an SLA to meet compliance requirements or require extending an SLA to their end-users should enable this feature. Customers with critical workloads that will benefit from a higher uptime SLA may also benefit. Using the Uptime SLA feature with Availability Zones enables a higher availability for the uptime of the Kubernetes API server.  
 
-Customers can create unlimited free clusters with a service level objective (SLO) of 99.5%.
+Customers can still create unlimited free clusters with a service level objective (SLO) of 99.5% and opt for the preferred SLO or SLA Uptime as needed.
 
 > [!Important]
 > For clusters with egress lockdown, see [limit egress traffic](limit-egress-traffic.md) to open appropriate ports for Uptime SLA.
 
 ## SLA terms and conditions
 
-Uptime SLA is a paid feature and enabled per cluster. Uptime SLA pricing is determined by the number of clusters, and not by the size of the clusters. You can view [Uptime SLA pricing details](https://azure.microsoft.com/pricing/details/kubernetes-service/) for more information.
+Uptime SLA is a paid feature and enabled per cluster. Uptime SLA pricing is determined by the number of discrete clusters, and not by the size of the individual clusters. You can view [Uptime SLA pricing details](https://azure.microsoft.com/pricing/details/kubernetes-service/) for more information.
 
 ## Region Availability
 
@@ -59,19 +59,17 @@ After a few minutes, the command completes and returns JSON-formatted informatio
     "name": "Basic",
     "tier": "Paid"
   },
-  "tags": null,
-  "type": "Microsoft.ContainerService/ManagedClusters",
-  "windowsProfile": null
 ```
 
 ## Limitations
 
-* You can't currently add Uptime SLA to existing clusters.
-* Currently, there is no way to remove Uptime SLA from an AKS cluster.  
+* Currently, cannot convert as existing cluster to enable the Uptime SLA.
+* Currently, there is no way to remove Uptime SLA from an AKS cluster after creation with it enabled.  
 
 ## Next steps
 
 Use [Availability Zones][availability-zones] to increase high availability with your AKS cluster workloads.
+Configure your cluster to [limit egress traffic](limit-egress-traffic.md).
 
 <!-- LINKS - External -->
 [azure-support]: https://ms.portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/newsupportrequest