locked
Azure Batch Security RRS feed

  • Question

  • Azure Batch allows placing pool nodes into a VNet which can be secured by an NSG.  However, port 3389 is required to be open, which is the RDP port.  This is necessary for the Azure Batch Service to communicate with the pool node.  However, this seems like a serious security concern.  Does the Azure Batch Service use a certain set of IP addresses that can be secured in the NSG?  Is there another way to secure the Azure Batch node?

    Friday, April 28, 2017 8:52 PM

Answers

  • Hi Jason,

    When you bring your own VNet with VirtualMachineConfiguration pools (as you are referencing 3389), then certain ports need to be open on the virtual network subnet for the Batch service to talk to the compute nodes for health monitoring, task scheduling, etc. The required ports are 29876 and 29877 for VirtualMachineConfiguration pools. If you are using Windows, 3389 is optionally needed only for RDP access. If you do not require RDP access to your compute nodes, you can block this port on your virtual network.

    Note that as of 2017-May-10, additional security has been applied for new pool allocations with bringing your own VNet for VirtualMachineConfiguration pools where Batch now creates one or more NSGs (depending upon the size of your pool) for the specific ports required and applies it on the network interface level of each VM in the pool. With this addition, you no longer need to open up your custom NSG(s) with manual configuration *if* you follow these two rules:

    1. The subnet in your virtual network for Batch compute nodes is exclusively for Batch compute nodes in your pools and nothing else.
    2. You do not apply any custom NSGs to these aforementioned subnets containing exclusively Batch compute nodes

    As long as you do *not* apply your custom NSG(s) to the subnet that the Batch compute nodes are on, then the Batch-deployed NSGs will sufficiently block inbound IP traffic that does not originate from the Batch service for the necessary control ports mentioned above. However, note that the Batch-deployed NSGs will allow all source IPs on 3389 for Windows or 22 for Linux. You can restrict or disable this behavior by reducing the source address space scope or deleting the inbound rules associated with this port on the Batch deployed NSGs that applies to the network interfaces for the compute nodes if you do not need RDP or SSH, respectively.

    Cheers,

    Fred



    Wednesday, May 10, 2017 3:13 PM

All replies

  • There's no specific IP range for batch, it could be any of the IP's in teh range for your region, you can get a list of the IP's here.

    That said, assuming any accounts you create on your batch machines use complex passwords, this should be less of an issue given the usual short lifetime of batch VM's, but I agree it's not ideal.


    Sam Cogan Microsoft Azure MVP
    Blog | Twitter

    Friday, April 28, 2017 9:56 PM
  • Hi Jason,

    When you bring your own VNet with VirtualMachineConfiguration pools (as you are referencing 3389), then certain ports need to be open on the virtual network subnet for the Batch service to talk to the compute nodes for health monitoring, task scheduling, etc. The required ports are 29876 and 29877 for VirtualMachineConfiguration pools. If you are using Windows, 3389 is optionally needed only for RDP access. If you do not require RDP access to your compute nodes, you can block this port on your virtual network.

    Note that as of 2017-May-10, additional security has been applied for new pool allocations with bringing your own VNet for VirtualMachineConfiguration pools where Batch now creates one or more NSGs (depending upon the size of your pool) for the specific ports required and applies it on the network interface level of each VM in the pool. With this addition, you no longer need to open up your custom NSG(s) with manual configuration *if* you follow these two rules:

    1. The subnet in your virtual network for Batch compute nodes is exclusively for Batch compute nodes in your pools and nothing else.
    2. You do not apply any custom NSGs to these aforementioned subnets containing exclusively Batch compute nodes

    As long as you do *not* apply your custom NSG(s) to the subnet that the Batch compute nodes are on, then the Batch-deployed NSGs will sufficiently block inbound IP traffic that does not originate from the Batch service for the necessary control ports mentioned above. However, note that the Batch-deployed NSGs will allow all source IPs on 3389 for Windows or 22 for Linux. You can restrict or disable this behavior by reducing the source address space scope or deleting the inbound rules associated with this port on the Batch deployed NSGs that applies to the network interfaces for the compute nodes if you do not need RDP or SSH, respectively.

    Cheers,

    Fred



    Wednesday, May 10, 2017 3:13 PM
  • Package deployment is failing. Below is what we did.
    1. We attached AzureBatch created NSG to a subnet in the vNet.
    2. In this subnet we listed Microsoft.Storage as a Service endpoint.
    3. Enabled storage firewall on the AzureBatch attached storage, white listed the subnet.

    After doing above #3 our package deployment is failing with below error 

    AutoStorageKeysInvalid

    The auto storage account keys are invalid, please sync auto storage keys. RequestId:9c4b101c-c4dc-444a-87b8-48d634dccc36 Time:2019-03-13T02:24:11.6132261Z


    Wednesday, March 13, 2019 2:38 AM
  • PorscheMe, Since this issue is being discussed in this MSDN thread, our engineer will be helping you out there.

    Karishma Tiwari - MSFT

    Wednesday, March 13, 2019 4:01 PM