Update inaccurate Batch task user account isolation

Author: alfpark

articles/batch/batch-user-accounts.md

@@ -2,7 +2,7 @@
 title: Run tasks under user accounts
 description: Learn the types of user accounts and how to configure them.
 ms.topic: how-to
-ms.date: 08/27/2024
+ms.date: 02/28/2025
 ms.custom:
 ms.devlang: csharp
 # ms.devlang: csharp, java, python
@@ -13,16 +13,14 @@ ms.devlang: csharp
 > The user accounts discussed in this article are different from user accounts used for Remote Desktop Protocol (RDP) or Secure Shell (SSH), for security reasons.
 >
 > To connect to a node running the Linux virtual machine configuration via SSH, see [Install and configure xrdp to use Remote Desktop with Ubuntu](/azure/virtual-machines/linux/use-remote-desktop). To connect to nodes running Windows via RDP, see [How to connect and sign on to an Azure virtual machine running Windows](/azure/virtual-machines/windows/connect-logon).
->
-> To connect to a node running the  via RDP, see [Enable Remote Desktop Connection for a Role in Azure Cloud Services](../cloud-services/cloud-services-role-enable-remote-desktop-new-portal.md).
 
 A task in Azure Batch always runs under a user account. By default, tasks run under standard user accounts, without administrator permissions. For certain scenarios, you may want to configure the user account under which you want a task to run. This article discusses the types of user accounts and how to configure them for your scenario.
 
 ## Types of user accounts
 
 Azure Batch provides two types of user accounts for running tasks:
 
-- **Auto-user accounts.** Auto-user accounts are built-in user accounts that are created automatically by the Batch service. By default, tasks run under an auto-user account. You can configure the auto-user specification for a task to indicate under which auto-user account a task should run. The auto-user specification allows you to specify the elevation level and scope of the auto-user account that will run the task.
+- **Auto-user accounts.** Auto-user accounts are built-in user accounts that are created automatically by the Batch service. By default, tasks run under an auto-user account. You can configure the auto-user specification for a task to indicate under which auto-user account a task should run. The auto-user specification allows you to specify the elevation level and scope of the auto-user account that runs the task.
 
 - **A named user account.** You can specify one or more named user accounts for a pool when you create the pool. Each user account is created on each node of the pool. In addition to the account name, you specify the user account password, elevation level, and, for Linux pools, the SSH private key. When you add a task, you can specify the named user account under which that task should run.
 
@@ -35,6 +33,12 @@ Both an auto-user account and a named user account have read/write access to the
 
 If a task runs under the same account that was used for running a start task, the task has read-write access to the start task directory. Similarly, if a task runs under the same account that was used for running a job preparation task, the task has read-write access to the job preparation task directory. If a task runs under a different account than the start task or job preparation task, then the task has only read access to the respective directory.
 
+> [!IMPORTANT]
+> Distinct task users in Batch aren't a sufficient security boundary for isolation between tasks and its associated task data.
+> In Batch, the security isolation boundary is at the pool level. However improper access control of the Batch
+> API can lead to access of all pools under a Batch account with sufficient permission. Refer to best practices about
+> [pool security](best-practices.md#pool-security).
+
 For more information on accessing files and directories from a task, see [Files and directories](files-and-directories.md).
 
 ## Elevated access for tasks
@@ -57,15 +61,18 @@ There are four possible configurations for the auto-user specification, each of
 - Non-admin access with pool scope
 - Admin access with pool scope
 
-> [!IMPORTANT]
-> Tasks running under task scope do not have de facto access to other tasks on a node. However, a malicious user with access to the account could work around this restriction by submitting a task that runs with administrator privileges and accesses other task directories. A malicious user could also use RDP or SSH to connect to a node. It's important to protect access to your Batch account keys to prevent such a scenario. If you suspect your account may have been compromised, be sure to regenerate your keys.
+> [!NOTE]
+> Auto-user accounts with elevated admin access have direct write access to all other task directories on the compute node executing
+> the task. Consider running your tasks with the least privilege required for successful execution.
 
 ### Run a task as an auto-user with elevated access
 
 You can configure the auto-user specification for administrator privileges when you need to run a task with elevated access. For example, a start task may need elevated access to install software on the node.
 
 > [!NOTE]
-> Use elevated access only when necessary. Best practices recommend granting the minimum privilege necessary to achieve the desired outcome. For example, if a start task installs software for the current user, instead of for all users, you may be able to avoid granting elevated access to tasks. You can configure the auto-user specification for pool scope and non-admin access for all tasks that need to run under the same account, including the start task.
+> Use elevated access only when necessary. A typical use case for using elevated admin access is for a start task that must install
+> software on the compute node before other tasks can be scheduled. For subsequent tasks, you should use the installed software
+> as a task user without elevation.
 
 The following code snippets show how to configure the auto-user specification. The examples set the elevation level to `Admin` and the scope to `Task`.
 
@@ -106,14 +113,12 @@ When a node is provisioned, two pool-wide auto-user accounts are created on each
 
 When you specify pool scope for the auto-user, all tasks that run with administrator access run under the same pool-wide auto-user account. Similarly, tasks that run without administrator permissions also run under a single pool-wide auto-user account.
 
-> [!NOTE]
-> The two pool-wide auto-user accounts are separate accounts. Tasks running under the pool-wide administrative account can't share data with tasks running under the standard account, and vice versa.
-
-The advantage to running under the same auto-user account is that tasks are able to share data with other tasks running on the same node.
+The advantage to running under the same auto-user account is that tasks are able to easily share data with other tasks running
+on the same node. There are also performance benefits to user account reuse.
 
 Sharing secrets between tasks is one scenario where running tasks under one of the two pool-wide auto-user accounts is useful. For example, suppose a start task needs to provision a secret onto the node that other tasks can use. You could use the Windows Data Protection API (DPAPI), but it requires administrator privileges. Instead, you can protect the secret at the user level. Tasks running under the same user account can access the secret without elevated access.
 
-Another scenario where you may want to run tasks under an auto-user account with pool scope is a Message Passing Interface (MPI) file share. An MPI file share is useful when the nodes in the MPI task need to work on the same file data. The head node creates a file share that the child nodes can access if they are running under the same auto-user account.
+Another scenario where you may want to run tasks under an auto-user account with pool scope is a Message Passing Interface (MPI) file share. An MPI file share is useful when the nodes in the MPI task need to work on the same file data. The head node creates a file share that the child nodes can access if they're running under the same auto-user account.
 
 The following code snippet sets the auto-user's scope to pool scope for a task in Batch .NET. The elevation level is omitted, so the task runs under the standard pool-wide auto-user account.
 
@@ -146,13 +151,13 @@ Console.WriteLine("Creating pool [{0}]...", poolId);
 // Create a pool using Virtual Machine Configuration.
 pool = batchClient.PoolOperations.CreatePool(
     poolId: poolId,
-    targetDedicatedComputeNodes: 3,
-    virtualMachineSize: "standard_d1_v2",
+    targetDedicatedComputeNodes: 2,
+    virtualMachineSize: "standard_d2s_v3",
     VirtualMachineConfiguration: new VirtualMachineConfiguration(
     imageReference: new ImageReference(
                         publisher: "MicrosoftWindowsServer",
                         offer: "WindowsServer",
-                        sku: "2019-datacenter-core",
+                        sku: "2022-datacenter-core",
                         version: "latest"),
     nodeAgentSkuId: "batch.node.windows amd64");
 
@@ -177,19 +182,18 @@ List<NodeAgentSku> nodeAgentSkus =
     batchClient.PoolOperations.ListNodeAgentSkus().ToList();
 
 // Define a delegate specifying properties of the VM image to use.
-Func<ImageReference, bool> isUbuntu1804 = imageRef =>
+Func<ImageReference, bool> isUbuntu2404 = imageRef =>
     imageRef.Publisher == "Canonical" &&
-    imageRef.Offer == "UbuntuServer" &&
-    imageRef.Sku.Contains("20.04-LTS");
+    imageRef.Offer == "ubuntu-24_04-lts" &&
+    imageRef.Sku.Contains("server");
 
 // Obtain the first node agent SKU in the collection that matches
-// Ubuntu Server 20.04.
 NodeAgentSku ubuntuAgentSku = nodeAgentSkus.First(sku =>
-    sku.VerifiedImageReferences.Any(isUbuntu2004));
+    sku.VerifiedImageReferences.Any(isUbuntu2404));
 
 // Select an ImageReference from those available for node agent.
 ImageReference imageReference =
-    ubuntuAgentSku.VerifiedImageReferences.First(isUbuntu2004);
+    ubuntuAgentSku.VerifiedImageReferences.First(isUbuntu2404);
 
 // Create the virtual machine configuration to use to create the pool.
 VirtualMachineConfiguration virtualMachineConfiguration =
@@ -200,8 +204,8 @@ Console.WriteLine("Creating pool [{0}]...", poolId);
 // Create the unbound pool.
 pool = batchClient.PoolOperations.CreatePool(
     poolId: poolId,
-    targetDedicatedComputeNodes: 3,
-    virtualMachineSize: "Standard_A1",
+    targetDedicatedComputeNodes: 2,
+    virtualMachineSize: "Standard_d2s_v3",
     virtualMachineConfiguration: virtualMachineConfiguration);
 // Add named user accounts.
 pool.UserAccounts = new List<UserAccount>

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: 06/27/2024
+ms.date: 02/28/2025
 ms.topic: conceptual
 ---
 
@@ -65,6 +65,10 @@ supported indefinitely. An EOL date may be added or updated in the future at any
 
 For the purposes of isolation, if your scenario requires isolating jobs or tasks from each other, do so by having them in separate pools. A pool is the security isolation boundary in Batch, and by default, two pools aren't visible or able to communicate with each other. Avoid using separate Batch accounts as a means of security isolation unless the larger environment from which the Batch account operates in requires isolation.
 
+If desired, proper access control must be applied on the Batch account and APIs to prevent access to all pools under the Batch account.
+It's recommended to disable shared key access and only allow Entra-based authentication to enable
+[role-based access control](batch-role-based-access-control.md).
+
 #### Batch Node Agent updates
 
 Batch node agents aren't automatically upgraded for pools that have nonzero compute nodes. To ensure your Batch pools receive the latest security fixes and updates to the Batch node agent, you need to either resize the pool to zero compute nodes or recreate the pool. It's recommended to monitor the [Batch Node Agent release notes](https://github.com/Azure/Batch/blob/master/changelogs/nodeagent/CHANGELOG.md) to understand changes to new Batch node agent versions. Checking regularly for updates when they were released enables you to plan upgrades to the latest agent version.