How is security arranged for a large-scale cluster?

Print Friendly, PDF & Email

Any popular computing platforms eventually becomes the target of nefarious activity. Hackers may try to break into a cluster to cause havoc or to launch denial-of-service attacks against other users in cyberspace. One of the major benefits of a cluster over a grid is that clusters can be tightly controlled by administrators, which means that a number of simple steps will greatly ease the security burden.

Firstly, the machine must be located in a secure room. Since clusters are usually placed in a special room anyway for energy and heat requirements, one need only install a strong lock on the front door to prevent physical access from unauthorized individuals. Other common sense measures such as firewall and password policies will aid in thwarting remote access.

But what if a hacker has managed to get through the head node through cracking a user’s password? Putting policies in place early on will provide the best damage control for these cases. For one thing, do not allow non-root users to ever log onto a compute node. This means that users may only submit parallel jobs via a queue on the head node. A batch-only setup has the added benefit in that users will not experience a noticeable interruption in service while compute nodes are rebooted (for kernel patches, etc) because submitted jobs will simply accumulate on the head node until sufficient resources are available.

Another step is to provide only the software that is absolutely necessary. Assuming that users are unlikely to require web access, the absence of tools like wget and lynx will deter a hacker from downloading his software from the Internet should he manage to gain access to the head node. A policy of minimal software, however, should only be implemented after polling the user community first.

In all, security for a cluster is fairly straightforward with a simple plan. Happy computing.