content_image/805516.jpg content_image/805517.jpg content_image/805518.jpg
behind the hardware firewall, but permits incoming packets to travel beyond the router connecting all cluster hosts to reach the SQL nodes. 

One possible network deployment of an NDB Cluster using hardware and software firewalls in combination is shown here: 

<img src='content_image/805516.jpg'>

In this case, you can set the rules in the hardware firewall to deny any external traffic except to SQL nodes and API nodes, and then permit traffic to them only on the ports required by your application. 

Whatever network configuration you use, remember that your objective from the viewpoint of keeping the cluster secure remains the same—to prevent any unessential traffic from reaching the cluster while ensuring the most efficient communication between the nodes in the cluster. 

Because NDB Cluster requires large numbers of ports to be open for communications between nodes, the recommended option is to use a segregated network. This represents the simplest way to prevent unwanted traffic from reaching the cluster. 

## 23.5.17.2 NDB Cluster and MySQL Privileges 

<img src='content_image/805517.jpg'>

<img src='content_image/805518.jpg'>

## Note 

If you wish to administer an NDB Cluster remotely (that is, from outside the local network), the recommended way to do this is to use ssh  or another secure login shell to access an SQL node host. From this host, you can then run the management client to access the management server safely, from within the cluster’s own local network. 

Even though it is possible to do so in theory, it is not  recommended to use ndb_mgm to manage a Cluster directly from outside the local network on which the Cluster is running. Since neither authentication nor encryption takes place between the management client and the management server, this represents an extremely insecure means of managing the cluster, and is almost certain to be compromised sooner or later. 

