Merge pull request #251385 from alfpark/alpark/batch2

Update Batch OS security best practices

Author: prmerger-automator[bot]

articles/batch/best-practices.md

@@ -1,7 +1,7 @@
 ---
 title: Best practices
 description: Learn best practices and useful tips for developing your Azure Batch solutions.
-ms.date: 01/18/2023
+ms.date: 09/13/2023
 ms.topic: conceptual
 ---
 
@@ -35,13 +35,14 @@ initiates communication to the compute nodes, and compute nodes also require com
 node communication model, compute nodes initiate communication with the Batch service. Due to the reduced scope of
 inbound/outbound connections required, and not requiring Azure Storage outbound access for baseline operation, the recommendation
 is to use the simplified node communication model. Some future improvements to the Batch service will also require the simplified
-node communication model.
+node communication model. The classic node communication model will be
+[retired on March 31, 2026](batch-pools-to-simplified-compute-node-communication-model-migration-guide.md).
 
 - **Job and task run time considerations:** If you have jobs comprised primarily of short-running tasks, and the expected total task counts are small, so that the overall expected run time of the job isn't long, don't allocate a new pool for each job. The allocation time of the nodes will diminish the run time of the job.
 
 - **Multiple compute nodes:** Individual nodes aren't guaranteed to always be available. While uncommon, hardware failures, operating system updates, and a host of other issues can cause individual nodes to be offline. If your Batch workload requires deterministic, guaranteed progress, you should allocate pools with multiple nodes.
 
-- **Images with impending end-of-life (EOL) dates:** We strongly recommended avoiding images with impending Batch support
+- **Images with impending end-of-life (EOL) dates:** It's strongly recommended to avoid images with impending Batch support
 end of life (EOL) dates. These dates can be discovered via the
 [`ListSupportedImages` API](/rest/api/batchservice/account/listsupportedimages),
 [PowerShell](/powershell/module/az.batch/get-azbatchsupportedimage), or

articles/batch/security-best-practices.md

@@ -1,7 +1,7 @@
 ---
 title: Batch security and compliance best practices
 description: Learn best practices and useful tips for enhancing security with your Azure Batch solutions.
-ms.date: 11/15/2022
+ms.date: 09/13/2023
 ms.topic: conceptual
 ---
 
@@ -27,7 +27,9 @@ Pools can also be configured in one of two node communication modes, classic or
 In the classic node communication model, the Batch service initiates communication to the compute nodes, and compute nodes
 also require communicating to Azure Storage. In the simplified node communication model, compute nodes initiate communication
 with the Batch service. Due to the reduced scope of inbound/outbound connections required, and not requiring Azure Storage
-outbound access for baseline operation, the recommendation is to use the simplified node communication model.
+outbound access for baseline operation, the recommendation is to use the simplified node communication model. The classic
+node communication model will be
+[retired on March 31, 2026](batch-pools-to-simplified-compute-node-communication-model-migration-guide.md).
 
 ### Batch account authentication
 
@@ -60,10 +62,42 @@ In addition to operations specific to a Batch account, [management operations](/
 
 Batch management operations via Azure Resource Manager are encrypted using HTTPS, and each request is authenticated using Azure AD authentication.
 
-### Batch pool nodes
+### Batch pool compute nodes
 
 The Batch service communicates with a Batch node agent that runs on each node in the pool. For example, the service instructs the node agent to run a task, stop a task, or get the files for a task. Communication with the node agent is enabled by one or more load balancers, the number of which depends on the number of nodes in a pool. The load balancer forwards the communication to the desired node, with each node being addressed by a unique port number. By default, load balancers have public IP addresses associated with them. You can also remotely access pool nodes via RDP or SSH (this access is enabled by default, with communication via load balancers).
 
+#### Batch compute node OS
+
+Batch supports both Linux and Windows operating systems. Batch supports Linux with an aligned node agent for a subset of Linux OS
+distributions. It's recommended that the operating system is kept up-to-date with the latest patches provided by the OS
+publisher.
+
+Batch support for images and node agents phase out over time, typically aligned with publisher support timelines. It's
+recommended to avoid using images with impending end-of-life (EOL) dates or images that are past their EOL date.
+It's your responsibility to periodically refresh your view of the EOL dates pertinent to your pools and migrate your workloads
+before the EOL date occurs. If you're using a custom image with a specified node agent, ensure that you follow Batch support
+end-of-life dates for the image for which your custom image is derived or aligned with. An image without a specified
+`batchSupportEndOfLife` date indicates that such a date hasn't been determined yet by the Batch service. Absence of a date
+doesn't indicate that the respective image will be supported indefinitely. An EOL date may be added or updated in the future
+at any time. EOL dates can be discovered via the
+[`ListSupportedImages` API](/rest/api/batchservice/account/listsupportedimages),
+[PowerShell](/powershell/module/az.batch/get-azbatchsupportedimage), or
+[Azure CLI](/cli/azure/batch/pool/supported-images).
+
+#### Windows OS Transport Layer Security (TLS)
+
+The Batch node agent doesn't modify operating system level defaults for SSL/TLS versions or cipher suite ordering. In Windows,
+SSL/TLS versions and cipher suite order is controlled at the operating system level, and therefore the Batch node agent adopts
+the settings set by the image used by each compute node. Although the Batch node agent attempts to utilize the
+most secure settings available when possible, it can still be limited by operating system level settings.  We recommend that
+you review your OS level defaults and set them appropriately for the most secure mode that is amenable for your workflow and
+organizational requirements. For more information, please visit
+[Manage TLS](https://learn.microsoft.com/windows-server/security/tls/manage-tls) for cipher suite order enforcement and
+[TLS registry settings](https://learn.microsoft.com/windows-server/security/tls/tls-registry-settings) for SSL/TLS version
+control for Schannel SSP. Note that some setting changes require a reboot to take effect. Utilizing a newer operating system
+with modern security defaults or a [custom image](batch-sig-images.md) with modified settings is recommended instead of
+application of such settings with a Batch start task.
+
 ### Restricting access to Batch endpoints
 
 Several capabilities are available to limit access to the various Batch endpoints, especially when the solution uses a virtual network.