---

MemSQL supports features for user authentication, password policies, fine-grained access controls, and certificate-based network encryption between clients and the database cluster, as well as between individual nodes in the cluster.

By default, you can log into MemSQL with the root user, but must specify a password to connect to the database, or explicitly define an empty password during deployment to connect without specifying a password. This page describes configuration changes and best practices required to secure MemSQL.

Configuring MemSQL user accounts

Securing the initial MemSQL user accounts

Configuring the root password

When MemSQL is installed, the root user is created on each MemSQL node. You are required to set a password when running sdb-admin create-node, but this can be set to a blank password for testing purposes. As a best practice, you should set a secure password for the root user.

Once your cluster is deployed, you can also change the password for the root user with the sdb-admin change-root-password command. This command configures the root password for a single MemSQL node. To configure the password on all nodes in a MemSQL cluster, run:

sdb-admin change-root-password --all --yes --password <secure_password>

Changing the root password is an online operation for both aggregators and leaves and you do not have to perform any additional operations; however, you must ensure your nodes are running before calling the change-root-password command.

While it is convenient to set the root password using a command-line argument, it is often recommended against this practice for security reasons. The command-line argument accepts passwords entered as plain text, which makes them vulnerable to being discovered in the list of processes running on the system during application runtime. The plain text passwords could also be saved and accessed in the history file if your command-line interpreter maintains a history. For example, in Bash, the command history including password inputs is logged at ~/.bash_history. In addition, the root password supplied as a command-line argument is displayed on-screen and is visible to anyone who is reading the user’s screen.

Some of the more secure, alternative methods to set SingleStore DB root password are as follows.

• Set the root password using the MEMSQL_PASSWORD environment variable. This option is best suited for automated applications.
• As of SingleStore DB Toolbox 1.6.4, Toolbox commands can solicit the root password interactively from users. The passwords entered in an interactive prompt are not displayed on-screen and are effectively secured from anyone reading the user’s screen. The interactive prompt is invoked if neither the --password flag nor the MEMSQL_PASSWORD environment variable has been used to set the root password.

Deleting unnecessary default users

In MemSQL 6.0 and later, the only default user created on each MemSQL node during installation is the 'root'@'%' user, which should be configured as described in the previous section.

In MemSQL 5.8 and earlier, several default users are created on each MemSQL node during installation. We recommend deleting all of these default users except for the 'root'@'%' user.

To delete these users, use the DROP USER command. On each MemSQL node (including both aggregators and leaves), log in as the root user or another user with sufficient permissions, and run:

DROP USER ''@'localhost';
DROP USER ''@'127.0.0.1';
DROP USER 'root'@'localhost';
DROP USER 'dashboard'@'%';
DROP USER 'dashboard'@'localhost';

These additional default users are created in MemSQL installations of 5.8 and earlier, but not 6.0 and later. They are not changed during upgrade, so a MemSQL cluster installed on 5.8 or earlier and upgraded to 6.0 or later will still have these user accounts, unless you have deleted them.

Note that since user accounts are configured independently on each node, whenever you add a new MemSQL node, you should also delete any unnecessary default users on it.

Adding a User

To add a user, use the GRANT command. If you have sync_permissions enabled on your cluster, log into the master aggregator as the root user or another user with sufficient permissions, and run:

memsql> GRANT <grant_options> TO '<user>'@'<host>' IDENTIFIED BY '<password>'

For example:

memsql> GRANT SELECT, INSERT ON db.* TO 'username'@'%' IDENTIFIED BY 'password'

See the GRANT documentation for more details.

You can also use Kerberos, SAML, or PAM instead of password-based authentication.

Changing a Password for a User

To change a password for a user, you have the following options:

• Use GRANT as shown in the previous section. You must have SUPER privileges to change another user’s password.

• Use SET PASSWORD to create a password hash and assign it to the user. Users can also change their own password with this command.

  SET PASSWORD FOR 'username'@'host' = PASSWORD('password');
  

Removing a User

To remove a user, use the DROP USER command. Similar to other user management operations, if you have sync_permissions enabled, log into the master aggregator as the root user or another user with sufficient permissions, and run:

memsql> DROP USER '<user>'@'<host>'

If sync_permissions is not enabled, then you must perform this operation on each aggregator in the cluster.

Inspecting Permissions

You can view grants and permissions by querying information_schema.user_privileges.

You can also view grants for a user by running SHOW GRANTS:

memsql> SHOW GRANTS FOR user@domain;

Configuring Host-Based Security

You can use a firewall to restrict which hosts can access MemSQL. For example, if you’re running a MemSQL cluster on Amazon EC2, you can configure security groups to restrict network access by specifying allowed IP addresses or security groups.

You can also set the bind-address variable to restrict the range of IP addresses which are allowed to connect to MemSQL. For example, if you set it to 127.0.0.1, you will only be able to connect to MemSQL locally. See bind_address in the list of engine variables.

Configuring SSL

See SSL Secure Connections.

Setting SECURE_FILE_PRIV

The secure_file_priv global variable controls where users with the FILE READ and FILE WRITE privilege can read or save files. It should be set on all nodes to a directory that is not used by MemSQL or other software. If not set, a user with the FILE READ or FILE WRITE privilege can tamper with the system by reading or creating files in sensitive locations. For information on how to set engine variables, see the engine variables overview.

Encryption at Rest

MemSQL is compatible with at-rest disk-based encryption via LUKS (Linux Unified Key Setup). While LUKS is the recommended encryption technology, MemSQL may be compatible with other solutions. Please contact us if you have questions about using MemSQL with other encryption technologies.

To use MemSQL with LUKS, configure your block device to be encrypted with LUKS, and then simply install MemSQL on the encrypted volume.

For more information about how to implement LUKS with different versions of Linux, see the links in the section below. Note that ‘ecryptfs’ should never be used - only volume or block level encryption.

Example Setup Process

• Prepare block device
• Encrypt block device with LUKS
• Create filesystem (i.e., mkfs.ext4 /dev/mapper/myencryptedvolume)
• Mount filesystem (i.e., mount /dev/mapper/myencryptedvolume /data)
• Install MemSQL normally to encrypted location using the MemSQL management tools or MemSQL Ops

How to Use LUKS With Different Versions of Linux

• Red Hat Enterprise Linux: For an overview on using LUKS with Red Hat, go here.

  • Red Hat Enterprise Linux version 5 (Linux kernel 2.6.18-8)
  • Red Hat Enterprise Linux version 6 (Linux kernel 2.6.32-71)
  • Red Hat Enterprise Linux version 7 (Linux kernel 3.10.0-123)

• SUSE Linux Enterprise Server:

  • SUSE version 10 (Linux kernel 2.6.16.21-0.8)
  • SUSE version 11 (Linux kernel 2.6.27.19-5.1)
  • SUSE version 12 (Linux kernel 3.12.28-4.6)

• Ubuntu: For information about implementing LUKS on Ubuntu, go here.

• openSUSE: For information about implementing LUKS on openSUSE, go here.