Security Considerations for Using Azure Nodes in a Windows HPC Cluster
Updated: January 13, 2014
Applies To: Microsoft HPC Pack 2008 R2, Microsoft HPC Pack 2012, Microsoft HPC Pack 2012 R2, Windows HPC Server 2008 R2
This topic describes security considerations for deploying and running jobs on Windows Azure nodes that have been added to a Windows HPC cluster (a Windows Azure “burst” scenario). This section does not cover the security considerations for using the Windows Azure HPC Scheduler. For more information about the Windows Azure HPC Scheduler, see the MSDN content.
For background information about Windows Azure platform security, see Security Resources for Windows Azure.
In this section:
Firewall ports and protocols
Security model for interaction of on-premises and Windows Azure components
The domain-joined user accounts that are used to submit jobs and tasks to an on-premises HPC cluster are not used to run jobs and tasks on Windows Azure nodes. Each job that is run on a Windows Azure node creates a local user account and password. This helps ensure separation of job processes in Windows Azure.
|A change or expiration of domain credentials for a cluster user does not cause any job queued by that user to fail on Windows Azure nodes, even though the queued jobs will fail on on-premises nodes.|
The firewall ports and protocols that are used to deploy Windows Azure nodes and to run jobs are summarized in Firewall ports used for communication with Windows Azure nodes. For information about the configuration of Windows Firewall in the on-premises cluster that enables internal services to run, see Appendix 1: HPC Cluster Networking.
|Starting with HPC Pack 2008 R2 with SP3, port 443 is used for all Windows Azure node deployment and job scheduling operations. This simplifies the set of ports that are required to use Windows Azure nodes, compared with earlier versions of HPC Pack.|
X.509 v3 certificates are used to help secure the communication between on-premises cluster nodes and Windows Azure nodes. They can be signed by another trusted certificate or they can be self-signed. To deploy Windows Azure nodes to a Windows Azure hosted service and to run jobs on them, both a management certificate and service certificates must be configured. The management certificate generally requires manual configuration. The service certificates are automatically configured by HPC Pack.
A Windows Azure management certificate must be configured in the Windows Azure subscription, on the head node, and on any client computer that is used to connect to the Windows Azure cloud service. The client that connects to the Windows Azure subscription has the private key. For procedures to configure the management certificate, see Scenarios to Configure the Management Certificate.
The management certificate is used to help secure operations including the following:
Create a Windows Azure node template that can be used to deploy Windows Azure nodes
Provision Windows Azure nodes
Upload files to Windows Azure storage (for example, by using the hpcpack command)
|A self-signed management certificate can be used for testing purposes or proof-of-concept deployments. However, it is not recommended for production deployments.|
The following two public-key service certificates are automatically uploaded to the Windows Azure cloud service from HPC Pack when Windows Azure nodes are provisioned. They are used to permit mutual authentication between the on-premises head node and the Windows Azure proxy nodes that are automatically provisioned in every deployment.
- Microsoft HPC Azure Service
- Microsoft HPC Azure Client
These certificates are configured by HPC Pack as follows:
- The on-premises head node is configured with the Microsoft HPC Azure Client certificate (with the private key) and the Microsoft HPC Azure Service certificate
- The proxy nodes in Windows Azure are configured with the Microsoft HPC Azure Service certificate (with the private key) and the Microsoft HPC Azure Client certificate
Operations on a Windows Azure storage account require an account key, which is automatically configured when the account is created. HPC Pack automatically retrieves this key to perform storage operations during the provisioning of Windows Azure nodes.
The following figures provide details on the interactions of on-premises HPC Pack components and those in Windows Azure that are used for running cluster jobs. The figures indicate the ports, protocols, and endpoints that are used for communication in HPC Pack (starting with HPC Pack 2008 R2 with SP3), as well as in HPC Pack 2008 R2 with SP1 or SP2. The on-premises components that are present depend on the configuration of the HPC cluster.
HPC Pack 2008 R2 with at least SP3, or a later version of HPC Pack
HPC Pack 2008 R2 with SP1 or SP2