4.3 Cluster Security
Security is always a two-edged sword.
Adding security always complicates the configuration of your systems
and makes using a cluster more difficult. But if you
don't have adequate security, you run the risk of
losing sensitive data, losing control of your cluster, having it
damaged, or even having to completely rebuild it. Security management
is a balancing act, one of trying to figure out just how little
security you can get by with.
As previously noted, the usual architecture for a cluster is a set of
machines on a dedicated subnet. One machine, the
head node,
connects this network to the outside world, i.e., the
organization's network and the Internet. The only
access to the cluster's dedicated subnet is through
the head node. None of the compute nodes are attached to any other
network. With this model, security typically lies with the head node.
The subnet is usually a trust-based open network.
There are several reasons for this approach. With most clusters, the
communication network is the bottleneck. Adding layers of security to
this network will adversely affect performance. By focusing on the
head node, security administration is localized and thus simpler.
Typically, with most clusters, any sensitive information resides on
the head node, so it is the point where the greatest level of
protection is needed. If the compute nodes are not isolated, each one
will need to be secured from attack.
This approach also simplifies setting up packet filtering, i.e.,
firewalls. Incorrectly configured, packet filters can create havoc
within your cluster. Determining what traffic to allow can be a
formidable challenge when using a number of different applications.
With the isolated network approach, you can configure the internal
interface to allow all traffic and apply the packet filter only to
public interface.
This approach doesn't mean you have a license to be
sloppy within the cluster. You should take all reasonable
precautions. Remember that you need to protect the cluster not just
from external threats but from internal ones as well-whether
intentional or otherwise.
Since a thorough discussion of security could easily add a few
hundred pages to this book, it is necessary to assume that you know
the basics of security. If you are a novice system administrator,
this is almost certainly not the case, and you'll
need to become proficient as quickly as possible. To get started, you
should:
Be sure to apply all appropriate security patches, at least to the
head node, and preferably to all nodes. This is a task you will need
to do routinely, not just when you set up the cluster. Know what is installed on your system. This can be a particular
problem with cluster kits. Audit your systems regularly. Differentiate between what's available inside the
cluster and what is available outside the cluster. For example,
don't run NFS outside the cluster. Block
portmapper on the public interface of the head
node. Don't put too much faith in firewalls, but use one,
at least on the head node's public interface, and
ensure that it is configured correctly. Don't run services
that you don't need. Routinely check which services
are running, both with
netstat
and with a port scanner like
nmap. Your head node should be dedicated to the cluster, if at all
possible. Don't set it up as a general server. Use the root account only when necessary. Don't run
programs as root unless it is absolutely necessary.
There is no easy solution to the security dilemma. While you may be
able to learn enough, you'll never be able to learn
it all.
|
