Security and protocols|V4.3.3| docs|Distributed Database

Security and protocols

Last Updated：2025-03-21 09:20:00 Updated

Security capabilities

Security means to meet the compliance requirements and defend against attacks. From the perspective of the entire system and access link, the concept of security covers platform security, OceanBase Database Proxy (ODP) security, and OceanBase Database security.

ODP security refers to the security of connections, access control, and middleware and the security of ODP itself.

Password protection

ODP has two special accounts: root@proxysys and proxyro@sys. root@proxysys is the administrator account of ODP and proxyro@sys is the account used by ODP to access OceanBase Database. You can change the passwords of the two accounts. The password of the root@proxysys account is specified by the obproxy_sys_password parameter, and that of the proxyro@sys account is specified by the observer_sys_password parameter. The observer_sys_password1 parameter is added in V3.x for the smooth password change for the proxyro account. With this parameter, the new password can directly take effect without a restart.

Notice

If you log on with the root@proxysys account, for example, by running the mysql -h127.1 -P2883 -uroot@proxysys -pxxx command, use the alter proxyconfig set obproxy_sys_password = 'xxx'; statement to set a password. In this statement, xxx indicates the password.

If you set a password by using the -o option, the value is a SHA1-hashed value. This method is not recommended.

SSL

Requirements for using Secure Sockets Layer (SSL):

Certificate system: Customers may have their own key distribution systems. Adaptation is required in this case.
Peripheral products: On the access link, the driver, ODP, and OBServer must all support SSL. For a Multipath TCP (MTCP) link, SSL can be enabled as needed.

From the perspective of full link, a link exists between the client and the ODP, and a link exists between the ODP and the OBServer. ODP supports SSL encryption for the two links. You can determine the link for which SSL is to be enabled based on the overall architecture. For example, in a public cloud scenario, SSL is used as follows:

SSL

Data between VPCs is encrypted by using SSL, and the security within each VPC is ensured by using network isolation. SSL compromises less than 5% the overall performance.

Key settings

To enable the SSL capability of ODP, you must first set the keys. Log on to ODP with the root@proxysys account and set the certificates, a public key, and a private key by using files. Example:

replace into ssl_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "key_info", "xxx");
update proxyconfig.security_config set CONFIG_VAL= '{"sourceType" : "FILE", "CA" : "certs/ca.pem", "publicKey" : "certs/server-cert.pem", "privateKey" : "certs/server-key.pem"}' where APP_NAME = 'obproxy' and VERSION = '1';

In this example:

The sourceType field must be set to FILE.
The CA field specifies the storage location of the CA certificate.
The publicKey field specifies the storage location of the public key certificate.
The privateKey field specifies the storage location of the private key certificate.

SSL parameters

ODP has two SSL parameters. The enable_client_ssl parameter specifies whether to enable SSL for the link between the client and the ODP. The enable_server_ssl parameter specifies whether to enable SSL for the link between the ODP and the OBServer.

The settings are as follows:

# V1.x series
alter proxyconfig set enable_client_ssl = xxx;
alter proxyconfig set enable_server_ssl = xxx;

# Tenant-level settings in the V3.x series
replace into proxy_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "enable_client_ssl", "true");
replace into proxy_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "enable_server_ssl", "false");

View the SSL status

To view the SSL status of the link between the client and the ODP, run the show proxysession command and view the value of the using_ssl field. Query the SSL status of the link between the ODP and the OBServer from the OBServer. In practice, you can flexibly enable SSL for the links.

For ODP, the SSL setting takes effect at the tenant level, cluster level, and global level. The components negotiate whether to enable SSL. To use the SSL capability, you must enable SSL for both the driver and the database.

Whitelist

ODP can control the access whitelist of the client. You can set an access whitelist for each tenant. ODP provides an internal table white_list under the root@proxysys account. This internal table stores the whitelist information. ODP supports IP addresses or IP addresses and network IDs in the whitelist. The whitelist feature has been widely applied in public clouds.

replace into white_list(cluster_name, tenant_name, name, value) values('cluster1', 'tenant1', 'ip_list', '127.0.0.1,168.xxx.0.0/16');

Protocols

ODP supports three protocols.

MySQL protocol: consistent with the native MySQL protocol.
Compression protocol: compresses the content of the MySQL protocol to ensure data transmission correctness.
OceanBase 2.0 protocol: a proprietary protocol that supports more features.

Notice

You must not allowed to disable the OceanBase 2.0 protocol in ODP V4.x and OceanBase database 4.x. Otherwise, some features may not take effect.

The following three parameters are used to control the use of protocols.

enable_ob_protocol_v2: specifies whether to use the OceanBase 2.0 protocol. For more information, see the enable_ob_protocol_v2.
enable_compression_protocol: specifies whether to use the compression protocol. For more information, see the enable_compression_protocol.
compression_algorithm: specifies the compression protocol and compression level of the OceanBase 2.0 protocol. For more information, see the compression_algorithm.

Both the compression protocol and the OB 2.0 protocol verify data to ensure data correctness. Among them, enable_ob_protocol_v2 has a higher priority than enable_compression_protocol. If both parameters are set to False, a regular protocol is used.

Features

New features are developed based on the OceanBase 2.0 protocol. Format of the OceanBase 2.0 protocol:

OceanBase 2.0 Protocol Format:

   0       1         2           3          4        Byte
   +-----------------+----------------------+
   |    Magic Num    |       Version        |
   +-----------------+----------------------+
   |            Connection Id               |
   +-----------------------------+----------+
   |         Request Id          |   Seq    |
   +-----------------------------+----------+
   |            PayLoad Length              |
   +----------------------------------------+
   |                Flag                    |
   +-----------------+----------------------+
   |    Reserved     |Header Checksum(CRC16)|
   +-----------------+----------------------+
   |        ... PayLoad  Data ...           |----------+
   +----------------------------------------+          |
   |    Tailer PayLoad Checksum (CRC32)     |          |
   +----------------------------------------+          |
                                                       |
                                                       |
                            +--------------------------+
                            |
                            |
                            v
   +-------------------+-------------------+-------------------------------------+
   | Extra Len(4Byte)  |  Extra Info(K/V)  |  Basic Info(Standard MySQL Packet)  |
   +-------------------+-------------------+-------------------------------------+

Header Format:
(1)Magic Num:
The protocol magic number, which is 2 bytes long. The value is 0x20AB. It is used for quick detection and attack defense, and is different from the zlib compression algorithm.

(2)version
The protocol version, which is 1 byte long. At present, the version number is 0x20.

(3)Connection Id:
The server session ID, which is 4 bytes long. It is unique within the cluster. After successful authentication, the server passes this connection ID in an OK packet to the client for
bi-directional verification at the client or server session level. The JAVA client and OBProxy verify
the cluster name when a connection is established. Therefore, this connection ID is unique in multiple clusters.
The following table describes the composition of a server connection ID.

 |<---------------------------------32bit---------------------------->|
 0b   1b                             15b                              16b
 +----+------------------------------+--------------------------------+
 |Mask|          Server Id           |           Local Seq            |
 +----+------------------------------+--------------------------------+

MASK: The value 1 indicates that the connection ID is generated by the server. The value 0 indicates that the connection ID is generated by ODP, but this connection ID is no longer used.
Server Id: In a cluster, the server IDs are allocated by RootService and are unique within the cluster.
Local Seq: the number of connections for a server. The maximum value is INT16_MAX.

(4)Request Id:
The request ID, which is 3 bytes long. The value increments each time the client sends a request. When the server returns a response, the request ID in the response must be the same as that in the request.
The request ID is used for request-level verification. The initial value is random and the request ID starts from 0 again when the maximum value UINT24_MAX is reached.

(5)Packet Seq:
The packet sequence number, which is 1 byte long. The value increments each time the client sends a packet. The sequence number in the response must be the value of Packet Seq plus 1.
It is used for sequence verification among packets inside a request.

(6)Payload Length:
The length of payload data, which is 4 bytes long.

(7)Flag:
The status of the request and response, which is 4 bytes long. Each bit indicates one state.
+---------------+-----------------+---------------------------------------------+
| Flag & 0x0001 | ExtraInfoExist  |    0: doesn't exist; 1: exist               |
+---------------+-----------------+---------------------------------------------+
| Flag & 0x0002 | DataFlowEnd     |    1: data flow end; 0: data flow continue  |
+---------------+-----------------+---------------------------------------------+
|  other bits wait for extrend                                                  |
+-------------------------------------------------------------------------------+

(8)Reserved:
A reserved field, which is 2 bytes long.

(9)Header Checksum(CRC16):
The header checksum, which is 2 bytes long and is used for CRC16 check. It contains 7 bytes of the header of the MySQL compression protocol. Note that the value 0 indicates not to perform a check.

Payload Format:
(1)Extra Info
The extra information, which is used for extension. It takes effect only when ExtraInfoExist is set to 1. Its length is specified by Extra Len. The value is a 2-tuple of
[key, value]. The type of the 2-tuple corresponds to the ObObj type. The serialization and deserialization methods are the same as those of ObObj.
The key in the 2-tuple is fixedly of the type specified by ObVarcharType and is serialized and deserialized based on this type.
The type of the value in the 2-tuple is determined by the type field. The value is serialized and deserialized based on the specified type.
Each 2-tuple is stored in binary format.
Example of Extra Info:
When full-link monitoring is enabled, the JAVA client and ODP can use the Extra Info field to pass the trace ID to the server.

(2)MySQL Protocol Data
The MySQL protocol data, which can be considered as a byte stream. It may contain a part of a MySQL protocol package, or one or multiple protocol packages.

Tailer Format:
(1)Tailer PayLoad Checksum (CRC32)
The checksum of the entire payload. It contains Extra Info (if any) and MySQL Protocol Data and is used for CRC32 check. The value 0 indicates not to perform a check.