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@proxys 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@proxysysaccount, for example, by running themysql -h127.1 -P2883 -uroot@proxysys -pxxxcommand, use thealter proxyconfig set obproxy_sys_password = 'xxx';statement to set a password. In this statement,xxxindicates the password.If you set a password by using the
-ooption, 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:
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
sourceTypefield must be set toFILE.The
CAfield specifies the storage location of the CA certificate.The
publicKeyfield specifies the storage location of the public key certificate.The
privateKeyfield 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 ssl_config(cluster_name, tenant_name, name, value) values("cluster1", "tenant1", "enable_client_ssl", "true");
replace into ssl_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 V3.x 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. The 8.0 protocol is being improved.
Compression protocol: compresses the content of the MySQL protocol to ensure data transmission correctness.
OB 2.0 protocol: a proprietary protocol that supports more features.
The following two parameters are used to control the use of protocols.
enable_ob_protocol_v2: specifies whether to use the OB 2.0 protocol.enable_compression_protocol: specifies whether to use the compression protocol.
The effective scope of enable_ob_protocol_v2 is larger than that of enable_compression_protocol. If both parameters are set to false, a regular protocol is used. Generally, the compression protocol is used in a private cloud environment and the OB 2.0 protocol is used in a public cloud environment.
Protocol performance
| Parameter | QPS |
|---|---|
| enable_ob_protocol_v2 | 337,000 |
| enable_compression_protocol | 275,000 |
| Regular protocol | 378,000 |
Compared with the OB 2.0 protocol, the regular protocol improves the QPS by (37.8-33.7)/33.7*100%=12.16%. Compared with the compression protocol, the OB 2.0 protocol improves the QPS by (33.7-27.5)/27.5*100%=22.54%.
Data integrity
Both the compression protocol and the OB 2.0 protocol verify data to ensure data correctness. However, data errors still occur. In addition to data verification, the compression protocol can save bandwidth resources at the cost of consuming CPU resources.
Features
New features are developed based on the OB 2.0 protocol, which will become a popular protocol in the future. Format of the OB 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.