Managing Compute Cluster Security
Applies To: Windows Compute Cluster Server 2003
Active Directory is a prerequisite to running Windows Compute Cluster Server 2003.
Windows Compute Cluster Server 2003 uses the preexisting Administrator and User groups from the head node to assign administrators and user rights on the cluster. Both user and administrator group memberships are propagated to all compute nodes on a cluster automatically as part of the configuration process.
Compute cluster security
Protection against rogue nodes
Compute Cluster Server 2003 does not allow unapproved computers being added to the cluster as compute nodes. If an attacker could add a computer as a node, the Job Scheduler would send it credentials and jobs which could potentially contain sensitive data.
Any node that is added to a compute cluster has a status of Pending Approval, and remains in that state until the compute cluster administrator approves and resumes the node
Compute cluster network topology considerations
Compute cluster topology scenarios 1 and 3, which isolate the compute nodes from the public network, offer increased security by exposing only a single network interface on the head node to the public network. These topologies offer an excellent way to secure MPI traffic from Denial of Service, Data Tampering, and Information Disclosure threats. For details about both scenarios, see Compute Cluster Network Topology: Scenario 1 and Compute Cluster Network Topology: Scenario 3.
Of course, the most basic level of security is physical; make sure you restrict access to the compute cluster head node to further protect the encrypted user credentials stored in the Scheduler database.
Job Credential Handling
Each job submitted to the compute cluster uses the credentials (user name and password) of the job owner. Since jobs run as the user, compute nodes have access to the same network resources that are available to the user, simplifying both creation of a job and job debugging.
Compute Cluster Server 2003 uses Active Directory and Security Support Provider Interface client services to authenticate and Data Protection API (DPAPI) to encrypt user credentials associated with a job. Authentication is the process of ensuring that the end user is who they claim to be. Encryption is the process of encoding data to prevent unauthorized access, especially during transmission. Encryption is usually based on a key that is essential for decoding.
Compute Cluster Server authenticates a user's computer by utilizing a .NET Remoting network channel to call the Security Support Provider Interface (SSPI) API. SSPI negotiates an appropriate authentication method (Kerberos or if no proxy server is involved or if the user's computer can't use Kerberos, NTLM) and works with Active Directory and the user workstation to authenticate the user.
The sequence in which user credentials are employed by Compute Cluster Server 2003 is as follows:
User credentials are transmitted from the user's workstation to the head node using an authenticated, encrypted .NET Remoting network channel.
On the head node, the credentials are then encrypted using the AES algorithm via Windows’ Data Protection API (DPAPI) and stored on the head node in the job scheduler database.
When a job runs, the job scheduler on the head node decrypts the credentials and sends them to each compute node assigned to the job. This transmission occurs over another authenticated, encrypted .NET Remoting channel.
After receiving the user credentials, the compute cluster node manager service on each compute node creates a primary user logon token, then erases the credentials locally. The user password is not stored in the logon token. The token is then used by all subsequent job processes on the node. When the node completes the assigned job tasks, the token is discarded.
When the job is finished, the job scheduler on the head node erases the encrypted user credentials from the job scheduler database.
An important point is that Compute Cluster Server 2003 transmits user credentials exclusively on encrypted and authenticated channels.
Cluster users can elect to store their credentials locally on their workstation. When a user's credentials are cached in this manner, the user doesn't have to manually type in name and password each time a job is submitted.
User credentials cached locally are encrypted with a key known only to the job scheduler on the head node. The primary benefit is that if the client computer (like a laptop) is lost or stolen, even if the thief knows where to look for the cached network credentials, they cannot be used because the encryption key is not on the missing computer. And if the headnode is lost or stolen, a thief would have to break the administrator's password on the head node to access the encryption key. Good physical security of the head node will mitigate this unlikely threat.
For more information about .NET Remoting, see the following: .NET Remoting Authentication and Authorization Sample - Part I (https://go.microsoft.com/fwlink/?LinkId=64258).
This article is the first in a two-part series describing a security solution for .NET Remoting. This first part describes Microsoft.Samples.Security.SSPI—an assembly implementing a managed wrapper around the Microsoft® Windows® Security Support Provider Interface. This provides the core functionality needed to authenticate a client and server as well as sign and encrypt messages sent between the two.
User level security
Compute Cluster Servers restricts use and administration of the compute cluster to members of the administrators and user groups on the head node. The administrators and user groups are then replicated to the compute nodes.
If you create a file share on the headnode, make sure to limit access to the share to the cluster administrator and cluster user groups.
Note
If the head node is also a domain controller, cluster administrators become domain administrators and cluster users become domain users by default.
Windows Firewall security
It is recommended that you enable the firewall during Compute Cluster Pack setup. When the firewall is enabled, it is enabled for the public network interface of both the head node and any cluster nodes with public network interfaces.
During setup, Compute Cluster Pack setup disables the firewall on all private and MPI network interfaces. The firewall can only be enabled for the public network interfaces of the cluster nodes.
Important
If the head node is also a domain controller, do not enable the firewall. Firewalls are not supported on domain controllers.
For more information about enabling the Windows Firewall in Compute Cluster Server 2003, see Configuring the Firewall.
Disk Quotas
You might consider setting disk quotas on both head node and compute nodes to prevent a user from filling the disk. Running out of disk space on the head node will halt operation of the Job Scheduler. Running out of disk space on a compute node will impact job and task execution. For more information about managing disk quotas, see Managing Disk Quotas in Windows Server 2003 and Windows XP (https://go.microsoft.com/fwlink/?LinkId=64256)
Security Updates
Security updates are critical for protecting cluster servers from malicious users. You should check Microsoft Update on a regular basis and make sure that critical security updates are installed on all compute cluster nodes.
For information about performing updates, see Compute Cluster Administrator Operations.