Merge pull request #193729 from MicrosoftDocs/main

4/01 AM Publish

Author: huypub

articles/active-directory/saas-apps/atlassian-cloud-provisioning-tutorial.md

@@ -151,8 +151,7 @@ Once you've configured provisioning, use the following resources to monitor your
 3. If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).  
 
 ## Connector Limitations
-
-* Atlassian Cloud allows provisioning of users only from [verified domains](https://confluence.atlassian.com/cloud/organization-administration-938859734.html).
+* Atlassian Cloud only supports provisioning updates for users with verified domains. Changes made to users from a non-verified domain will not be pushed to Atlassian Cloud. Learn more about Atlassian verified domains [here] (https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/).
 * Atlassian Cloud does not support group renames today. This means that any changes to the displayName of a group in Azure AD will not be updated and reflected in Atlassian Cloud.
 * The value of the **mail** user attribute in Azure AD is only populated if the user has a Microsoft Exchange Mailbox. If the user does not have one, it is recommended to map a different desired attribute to the **emails** attribute in Atlassian Cloud.
 
@@ -172,4 +171,4 @@ Once you've configured provisioning, use the following resources to monitor your
 <!--Image references-->
 [1]: ./media/atlassian-cloud-provisioning-tutorial/tutorial-general-01.png
 [2]: ./media/atlassian-cloud-provisioning-tutorial/tutorial-general-02.png
-[3]: ./media/atlassian-cloud-provisioning-tutorial/tutorial-general-03.png
+[3]: ./media/atlassian-cloud-provisioning-tutorial/tutorial-general-03.png

articles/aks/availability-zones.md

@@ -4,7 +4,7 @@ description: Learn how to create a cluster that distributes nodes across availab
 services: container-service
 ms.custom: fasttrack-edit, references_regions, devx-track-azurecli
 ms.topic: article
-ms.date: 12/10/2021
+ms.date: 03/31/2022
 
 ---
 
@@ -39,6 +39,7 @@ AKS clusters can currently be created using availability zones in the following
 * North Europe
 * Norway East
 * Southeast Asia
+* South Africa North
 * South Central US
 * Sweden Central
 * UK South

articles/aks/certificate-rotation.md

@@ -1,16 +1,19 @@
 ---
-title: Rotate certificates in Azure Kubernetes Service (AKS)
-description: Learn how to rotate your certificates in an Azure Kubernetes Service (AKS) cluster.
+title: Certificate Rotation in Azure Kubernetes Service (AKS)
+description: Learn certificate rotation in an Azure Kubernetes Service (AKS) cluster.
 services: container-service
 ms.topic: article
-ms.date: 3/4/2022
+ms.date: 3/29/2022
 ---
 
-# Rotate certificates in Azure Kubernetes Service (AKS)
+# Certificate rotation in Azure Kubernetes Service (AKS)
 
-Azure Kubernetes Service (AKS) uses certificates for authentication with many of its components. Periodically, you may need to rotate those certificates for security or policy reasons. For example, you may have a policy to rotate all your certificates every 90 days.
+Azure Kubernetes Service (AKS) uses certificates for authentication with many of its components. If you have a RBAC-enabled cluster built after March 2022 it is enabled with certificate auto-rotation. Periodically, you may need to rotate those certificates for security or policy reasons. For example, you may have a policy to rotate all your certificates every 90 days.
 
-This article shows you how to rotate the certificates in your AKS cluster.
+> [!NOTE]
+> Certificate auto-rotation will not be enabled by default for non-RBAC enabled AKS clusters.
+
+This article shows you how certificate rotation works in your AKS cluster.
 
 ## Before you begin
 
@@ -28,7 +31,7 @@ AKS generates and uses the following certificates, Certificate Authorities, and
 * The `kubectl` client has a certificate for communicating with the AKS cluster.
 
 > [!NOTE]
-> AKS clusters created prior to May 2019 have certificates that expire after two years. Any cluster created after May 2019 or any cluster that has its certificates rotated have Cluster CA certificates that expire after 30 years. All other AKS certificates, which use the Cluster CA to for signing, will expire after two years and are automatically rotated during AKS version upgrade happened after 8/1/2021. To verify when your cluster was created, use `kubectl get nodes` to see the *Age* of your node pools.
+> AKS clusters created prior to May 2019 have certificates that expire after two years. Any cluster created after May 2019 or any cluster that has its certificates rotated have Cluster CA certificates that expire after 30 years. All other AKS certificates, which use the Cluster CA for signing, will expire after two years and are automatically rotated during an AKS version upgrade which happened after 8/1/2021. To verify when your cluster was created, use `kubectl get nodes` to see the *Age* of your node pools.
 > 
 > Additionally, you can check the expiration date of your cluster's certificate. For example, the following bash command displays the client certificate details for the *myAKSCluster* cluster in resource group *rg*
 > ```console
@@ -45,17 +48,20 @@ curl https://{apiserver-fqdn} -k -v 2>&1 |grep expire
 az vm run-command invoke -g MC_rg_myAKSCluster_region -n vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
 ```
 
-* Check expiration date of certificate on one VMSS agent node
+* Check expiration date of certificate on one virtual machine scale set agent node
 ```azurecli
 az vmss run-command invoke -g MC_rg_myAKSCluster_region -n vmss-name --instance-id 0 --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
 ```
 
 ## Certificate Auto Rotation
 
-Azure Kubernetes Service will automatically rotate non-ca certificates on both the control plane and agent nodes before they expire with no downtime for the cluster.
-
 For AKS to automatically rotate non-CA certificates, the cluster must have [TLS Bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) which has been enabled by default in all Azure regions.
 
+> [!Note]
+> If you have an existing cluster you have to upgrade that cluster to enable Certificate Auto-Rotation.
+
+For any AKS clusters created or upgraded after March 2022 Azure Kubernetes Service will automatically rotate non-ca certificates on both the control plane and agent nodes within 80% of the client certificate valid time, before they expire with no downtime for the cluster.
+
 #### How to check whether current agent node pool is TLS Bootstrapping enabled?
 To verify if TLS Bootstrapping is enabled on your cluster browse to the following paths.  On a Linux node: /var/lib/kubelet/bootstrap-kubeconfig, on a Windows node, it’s c:\k\bootstrap-config.
 
@@ -69,8 +75,7 @@ To verify if TLS Bootstrapping is enabled on your cluster browse to the followin
 
 Auto cert rotation won't be enabled on non-rbac cluster.
 
-
-## Rotate your cluster certificates
+## Manually rotate your cluster certificates
 
 > [!WARNING]
 > Rotating your certificates using `az aks rotate-certs` will recreate all of your nodes and their OS Disks and can cause up to 30 minutes of downtime for your AKS cluster.

articles/aks/concepts-storage.md

@@ -3,7 +3,7 @@ title: Concepts - Storage in Azure Kubernetes Services (AKS)
 description: Learn about storage in Azure Kubernetes Service (AKS), including volumes, persistent volumes, storage classes, and claims
 services: container-service
 ms.topic: conceptual
-ms.date: 03/11/2021
+ms.date: 03/30/2022
 
 ---
 
@@ -30,23 +30,33 @@ This article introduces the core concepts that provide storage to your applicati
 
 Kubernetes typically treats individual pods as ephemeral, disposable resources. Applications have different approaches available to them for using and persisting data. A *volume* represents a way to store, retrieve, and persist data across pods and through the application lifecycle.
 
-Traditional volumes are created as Kubernetes resources backed by Azure Storage. You can manually create data volumes to be assigned to pods directly, or have Kubernetes automatically create them. Data volumes can use Azure Disks or Azure Files.
+Traditional volumes are created as Kubernetes resources backed by Azure Storage. You can manually create data volumes to be assigned to pods directly, or have Kubernetes automatically create them. Data volumes can use: [Azure Disks][disks-types], [Azure Files][storage-files-planning], [Azure NetApp Files][azure-netapp-files-service-levels], or [Azure Blobs][storage-account-overview]. 
 
 ### Azure Disks
 
-Use *Azure Disks* to create a Kubernetes *DataDisk* resource. Disks can use:
-* Azure Premium storage, backed by high-performance SSDs, or 
-* Azure Standard storage, backed by regular HDDs. 
+Use *Azure Disks* to create a Kubernetes *DataDisk* resource. Disks types include: 
+* Ultra Disks
+* Premium SSDs
+* Standard SSDs
+* Standard HDDs
 
 > [!TIP]
->For most production and development workloads, use Premium storage. 
+>For most production and development workloads, use Premium SSD. 
 
 Since Azure Disks are mounted as *ReadWriteOnce*, they're only available to a single pod. For storage volumes that can be accessed by multiple pods simultaneously, use Azure Files.
 
 ### Azure Files
-Use *Azure Files* to mount an SMB 3.0 share backed by an Azure Storage account to pods. Files let you share data across multiple nodes and pods and can use:
-* Azure Premium storage, backed by high-performance SSDs, or 
-* Azure Standard storage backed by regular HDDs.
+Use *Azure Files* to mount an SMB 3.1.1 share or NFS 4.1 share backed by an Azure storage accounts to pods. Files let you share data across multiple nodes and pods and can use:
+* Azure Premium storage backed by high-performance SSDs
+* Azure Standard storage backed by regular HDDs
+
+### Azure NetApp Files
+* Ultra Storage 
+* Premium Storage
+* Standard Storage 
+
+### Azure Blob Storage
+* Block Blobs 
 
 ### Volume types
 Kubernetes volumes represent more than just a traditional disk for storing and retrieving information. Kubernetes volumes can also be used as a way to inject data into a pod for use by the containers. 
@@ -92,15 +102,6 @@ To define different tiers of storage, such as Premium and Standard, you can crea
 
 The StorageClass also defines the *reclaimPolicy*. When you delete the pod and the persistent volume is no longer required, the reclaimPolicy controls the behavior of the underlying Azure storage resource. The underlying storage resource can either be deleted or kept for use with a future pod.
 
-In AKS, four initial `StorageClasses` are created for cluster using the in-tree storage plugins:
-
-| Permission | Reason |
-|---|---|
-| `default` | Uses Azure StandardSSD storage to create a Managed Disk. The reclaim policy ensures that the underlying Azure Disk is deleted when the persistent volume that used it is deleted. |
-| `managed-premium` | Uses Azure Premium storage to create a Managed Disk. The reclaim policy again ensures that the underlying Azure Disk is deleted when the persistent volume that used it is deleted. |
-| `azurefile` | Uses Azure Standard storage to create an Azure File Share. The reclaim policy ensures that the underlying Azure File Share is deleted when the persistent volume that used it is deleted. |
-| `azurefile-premium` | Uses Azure Premium storage to create an Azure File Share. The reclaim policy ensures that the underlying Azure File Share is deleted when the persistent volume that used it is deleted.|
-
 For clusters using the [Container Storage Interface (CSI) drivers][csi-storage-drivers] the following extra `StorageClasses` are created:
 
 | Permission | Reason |
@@ -118,23 +119,24 @@ Unless you specify a StorageClass for a persistent volume, the default StorageCl
 You can create a StorageClass for additional needs using `kubectl`. The following example uses Premium Managed Disks and specifies that the underlying Azure Disk should be *retained* when you delete the pod:
 
 ```yaml
-kind: StorageClass
 apiVersion: storage.k8s.io/v1
+kind: StorageClass
 metadata:
   name: managed-premium-retain
-provisioner: kubernetes.io/azure-disk
-reclaimPolicy: Retain
+provisioner: disk.csi.azure.com
 parameters:
-  storageaccounttype: Premium_LRS
-  kind: Managed
+  skuName: Premium_LRS
+reclaimPolicy: Retain
+volumeBindingMode: WaitForFirstConsumer
+allowVolumeExpansion: true
 ```
 
 > [!NOTE]
 > AKS reconciles the default storage classes and will overwrite any changes you make to those storage classes.
 
 ## Persistent volume claims
 
-A PersistentVolumeClaim requests either Disk or File storage of a particular StorageClass, access mode, and size. The Kubernetes API server can dynamically provision the underlying Azure storage resource if no existing resource can fulfill the claim based on the defined StorageClass. 
+A PersistentVolumeClaim requests storage of a particular StorageClass, access mode, and size. The Kubernetes API server can dynamically provision the underlying Azure storage resource if no existing resource can fulfill the claim based on the defined StorageClass. 
 
 The pod definition includes the volume mount once the volume has been connected to the pod.
 
@@ -152,7 +154,7 @@ metadata:
 spec:
   accessModes:
   - ReadWriteOnce
-  storageClassName: managed-premium
+  storageClassName: managed-premium-retain
   resources:
     requests:
       storage: 5Gi
@@ -198,12 +200,12 @@ For mounting a volume in a Windows container, specify the drive letter and path.
 
 For associated best practices, see [Best practices for storage and backups in AKS][operator-best-practices-storage].
 
-To see how to create dynamic and static volumes that use Azure Disks or Azure Files, see the following how-to articles:
+To see how to use CSI drivers, see the following how-to articles:
 
-- [Create a static volume using Azure Disks][aks-static-disks]
-- [Create a static volume using Azure Files][aks-static-files]
-- [Create a dynamic volume using Azure Disks][aks-dynamic-disks]
-- [Create a dynamic volume using Azure Files][aks-dynamic-files]
+- [Enable Container Storage Interface(CSI) drivers for Azure disks and Azure Files on Azure Kubernetes Service(AKS)][csi-storage-drivers]
+- [Use Azure disk Container Storage Interface(CSI) drivers in Azure Kubernetes Service(AKS)][azure-disk-csi]
+- [Use Azure Files Container Storage Interface(CSI) drivers in Azure Kubernetes Service(AKS)][azure-files-csi]
+- [Integrate Azure NetApp Files with Azure Kubernetes Service][azure-netapp-files] 
 
 For more information on core Kubernetes and AKS concepts, see the following articles:
 
@@ -216,10 +218,14 @@ For more information on core Kubernetes and AKS concepts, see the following arti
 <!-- EXTERNAL LINKS -->
 
 <!-- INTERNAL LINKS -->
-[aks-static-disks]: azure-disk-volume.md
-[aks-static-files]: azure-files-volume.md
-[aks-dynamic-disks]: azure-disks-dynamic-pv.md
-[aks-dynamic-files]: azure-files-dynamic-pv.md
+[disks-types]: ../virtual-machines/disks-types.md
+[storage-files-planning]: ../storage/files/storage-files-planning.md
+[azure-netapp-files-service-levels]: ../azure-netapp-files/azure-netapp-files-service-levels.md
+[storage-account-overview]: ../storage/common/storage-account-overview.md
+[csi-storage-drivers]: csi-storage-drivers.md
+[azure-disk-csi]: azure-disk-csi.md
+[azure-netapp-files]: azure-netapp-files.md
+[azure-files-csi]: azure-files-csi.md
 [aks-concepts-clusters-workloads]: concepts-clusters-workloads.md
 [aks-concepts-identity]: concepts-identity.md
 [aks-concepts-scale]: concepts-scale.md

articles/aks/kubernetes-walkthrough.md

@@ -293,6 +293,8 @@ To learn more about AKS, and walk through a complete code to deployment example,
 > [!div class="nextstepaction"]
 > [AKS tutorial][aks-tutorial]
 
+This quickstart is for introductory purposes. For guidance on a creating full solutions with AKS for production, see [AKS solution guidance][aks-solution-guidance].
+
 <!-- LINKS - external -->
 [azure-vote-app]: https://github.com/Azure-Samples/azure-voting-app-redis.git
 [kubectl]: https://kubernetes.io/docs/user-guide/kubectl/
@@ -317,3 +319,4 @@ To learn more about AKS, and walk through a complete code to deployment example,
 [kubernetes-deployment]: concepts-clusters-workloads.md#deployments-and-yaml-manifests
 [kubernetes-service]: concepts-network.md#services
 [windows-container-cli]: windows-container-cli.md
+[aks-solution-guidance]: /azure/architecture/reference-architectures/containers/aks-start-here?WT.mc_id=AKSDOCSPAGE

articles/aks/managed-aad.md

@@ -190,7 +190,7 @@ When deploying an AKS Cluster, local accounts are enabled by default. Even when
 > On clusters with Azure AD integration enabled, users belonging to a group specified by `aad-admin-group-object-ids` will still be able to gain access via non-admin credentials. On clusters without Azure AD integration enabled and `properties.disableLocalAccounts` set to true, obtaining both user and admin credentials will fail.
 
 > [!NOTE]
-> After disabling local accounts users on an already existing AKS cluster where users might have used local account/s, admin must [rotate the cluster certificates](certificate-rotation.md#rotate-your-cluster-certificates), in order to revoke the certificates those users might have access to.  If this is a new cluster than no action is required.
+> After disabling local accounts users on an already existing AKS cluster where users might have used local account/s, admin must [rotate the cluster certificates](certificate-rotation.md), in order to revoke the certificates those users might have access to.  If this is a new cluster then no action is required.
 
 ### Create a new cluster without local accounts