Chapter 6 covered all the aspects of designing a batch processing solution, excluding some security issues. At that point, you had not been exposed to an Azure key vault, managed identities, Access control (IAM), and RBAC; therefore, it was decided to not include those security aspects until this chapter. Chapter 6 called out three common topics that apply in this context: networking, endpoint security, and backup and recovery. The available networking capabilities for an Azure Batch account are the removal of public access to the public endpoint, for example, <accountName>.batch.azure.com, and the ability to restrict access using CIDR notation. As shown in Figure 8.56, you can access the option to remove public access on the Networking blade for the Azure Batch account.
The default option is All Networks, which means the endpoint is publicly accessible to all clients who have authorization to connect. The Selected Networks option provides the options shown in Figure 8.56, where you can configure IP addresses or IP ranges that are allowed to access the endpoint from the Internet and/or access a node directly. When you select the Disabled option, no access is allowed using the public endpoint; however, you can create a private endpoint. The Private Access tab provides the necessary options to configure a private endpoint for the Azure Batch account. Backups and log files containing results and details about job executions are stored on an Azure storage account chosen during provisioning. Having worked through the design and implementation of access control on ADLS containers, you should know the approaches not only for keeping that data secure but also for managing the permissions correctly so that only those who need access to such data are provided with it. A word of caution: if you have targeted the same storage account to store the backups and job logs as you used for your Azure Synapse Analytics workspace, then individuals who are in the Storage Blob Data Reader role will have read access to the batch data. This is not optimal, so you should consider having separate Azure storage accounts per Azure product.
FIGURE 8.56 Azure Batch networking restrictions
Handle Security and Compliance Requirements
From an Azure Batch security perspective, two areas are of utmost importance: the management console and the batch pools. The way you manage who can perform what activity on an Azure product or feature is through an RBAC role. If a built‐in role does not meet your requirements, you can create a custom role. The most recent list of Azure built‐in roles (https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) does not include a role for Azure Batch with the associated ARM provider of Microsoft.Batch. Therefore, you might consider creating a custom RBAC role similar to the following:
After configuring the custom role, you can upload it using the Azure portal. From the Access Control (IAM) blade for your Azure subscription, click the + Add button, and then select the Add Custom Role menu item. A wizard will walk you through the creation and application of the custom RBAC role, as shown in Figure 8.57.
FIGURE 8.57 Configuring a custom Azure Batch RBAC role using the Azure portal
The other aspect of security regarding Azure Batch is managing the access to the batch pool that contains the nodes. Recall Exercise 6.1, where you provisioned the Azure Batch account and the batch pool. A detail named Identity was left at its default of None. The other option is User Assigned. You created a user‐assigned managed identity in Exercise 8.9. The identity is used to authenticate to cloud services and alleviates the need to store credentials in code or any place else. When you select User Assigned, you are given the option to be used to gain access to your Azure Batch pools and nodes.
