Oracle 5.0 Reference Manual page 1705

• MySQL Cluster and the MySQL privilege system
• MySQL standard security procedures as applicable to MySQL Cluster
17.5.10.1. MySQL Cluster Security and Networking Issues
In this section, we discuss basic network security issues as they relate to MySQL Cluster. It is
extremely important to remember that MySQL Cluster "out of the box" is not secure; you or your
network administrator must take the proper steps to ensure that your cluster cannot be compromised
over the network.
Cluster communication protocols are inherently insecure, and no encryption or similar security
measures are used in communications between nodes in the cluster. Because network speed and
latency have a direct impact on the cluster's efficiency, it is also not advisable to employ SSL or
other encryption to network connections between nodes, as such schemes will effectively slow
communications.
It is also true that no authentication is used for controlling API node access to a MySQL Cluster. As
with encryption, the overhead of imposing authentication requirements would have an adverse impact
on Cluster performance.
In addition, there is no checking of the source IP address for either of the following when accessing the
cluster:
• SQL or API nodes using "free slots" created by empty
config.ini
This means that, if there are any empty
any API nodes (including SQL nodes) that know the management server's host name (or IP address)
and port can connect to the cluster and access its data without restriction. (See
"MySQL Cluster and MySQL
• Any
ndb_mgm
This means that any cluster management client that is given the management server's host name
(or IP address) and port (if not the standard port) can connect to the cluster and execute any
management client command. This includes commands such as
For these reasons, it is necessary to protect the cluster on the network level. The safest network
configuration for Cluster is one which isolates connections between Cluster nodes from any other
network communications. This can be accomplished by any of the following methods:
1. Keeping Cluster nodes on a network that is physically separate from any public networks. This
option is the most dependable; however, it is the most expensive to implement.
We show an example of a MySQL Cluster setup using such a physically segregated network here:
MySQL Cluster Security Issues
file
Privileges", for more information about this and related issues.)
Note
You can exercise some control over SQL and API node access to the
cluster by specifying a
sections in the
config.ini
wish to connect an API node to the cluster from a previously unused host, you
need to add an
[api]
file.
More information is available
parameter. Also see
HostName
Cluster", for configuration examples using
client
[mysqld]
or sections in the
[mysqld] [api]
parameter for all
HostName
file. However, this also means that, should you
section containing its host name to the
elsewhere in this chapter [1583]
Section 17.3.1, "Quick Test Setup of MySQL
HostName
1685
or sections in the
[api]
config.ini
Section 17.5.10.2,
and
[mysqld] [api]
config.ini
about the
with API nodes.
and SHUTDOWN.
ALL STOP
file, then