Best Practices for TiDB Security Configuration

The security of TiDB is crucial for protecting data integrity and confidentiality. This document provides guidelines for configuring TiDB clusters securely during deployment. By following these best practices, you can effectively reduce potential security risks, prevent data breaches, and ensure the continuous, stable, and reliable operation of your TiDB database system.

Set the initial password for the root user

By default, the root user in a newly created TiDB cluster has no password, which poses a potential security risk. If a password is not set, anyone can attempt to log in to the TiDB database as the root user, potentially gaining access to and modifying data.

To avoid this risk, it is recommended to set a root password during deployment:

• For deployments using TiUP, refer to Deploy TiDB Cluster Using TiUP to generate a random password for the root user.
• For deployments using TiDB Operator, refer to Set initial account and password to set the root password.

Change the default Grafana password

TiDB installation includes the Grafana component by default, and the default username and password are typically admin/admin. If the password is not changed promptly, attackers could exploit this to gain control of the system.

It is recommended to immediately change the Grafana password to a strong one during the TiDB deployment, and regularly update the password to ensure system security. Here are the steps to change the Grafana password:

• Upon first login to Grafana, follow the prompts to change the password.

  

• Access the Grafana personal configuration center to change the password.

  

Enhance TiDB Dashboard security

Use a least privilege user

TiDB Dashboard shares the account system with TiDB SQL users, and TiDB Dashboard authorization is based on TiDB SQL user permissions. TiDB Dashboard requires minimal permissions and can even operate with read-only access.

To enhance security, it is recommended to create a least-privilege SQL user for accessing the TiDB Dashboard and to avoid using high-privilege users.

Restrict access control

By default, TiDB Dashboard is designed for trusted users. The default port includes additional API interfaces besides TiDB Dashboard. If you want to allow access to TiDB Dashboard from external networks or untrusted users, take the following measures to avoid security vulnerabilities:

• Use a firewall or other mechanisms to restrict the default 2379 port to trusted domains, preventing access by external users.

  Note

  TiDB, TiKV, and other components need to communicate with the PD component via the PD client port. Do not block internal network access between components, which will make the cluster unavailable.

• Configure a reverse proxy to securely provide TiDB Dashboard services to external users on a different port.

Protect internal ports

By default, TiDB installation includes several privileged interfaces for inter-component communication. These ports typically do not need to be accessible to users, because they are primarily for internal communication. Exposing these ports on public networks increases the attack surface, violates the principle of least privilege, and raises the risk of security vulnerabilities. The following table lists the default listening ports in a TiDB cluster:

It is recommended to only expose the 4000 port for the database and the 9000 port for the Grafana dashboard to ordinary users, while restricting access to other ports using network security policies or firewalls. The following is an example of using iptables to restrict port access:

# Allow internal port communication from the whitelist of component IP addresses
sudo iptables -A INPUT -s internal IP address range -j ACCEPT

# Only open ports 4000 and 9000 to external users
sudo iptables -A INPUT -p tcp --dport 4000 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9000 -j ACCEPT

# Deny all other traffic by default
sudo iptables -P INPUT DROP

If you need to access TiDB Dashboard, it is recommended to configure a reverse proxy to securely provide services to external networks on a separate port.

Resolving false positives from third-party MySQL vulnerability scanners

Most vulnerability scanners detect MySQL vulnerabilities based on version information. Because TiDB is MySQL protocol-compatible but not MySQL itself, version-based vulnerability scans might lead to false positives. It is recommended to focus vulnerability scans on principle-based assessments. If compliance scanning tools require a specific MySQL version, you can modify the server version number to meet the requirement.

By changing the server version number, you can avoid false positives from vulnerability scanners. The server-version value is used by TiDB nodes to verify the current TiDB version. Before upgrading the TiDB cluster, ensure that the server-version value is either empty or the actual version of TiDB to avoid unexpected behavior.