GaussDB (for Redis) multi-tenancy: the perfect integration of read and write permission control and database isolation

This article is shared from Huawei Cloud Community " GaussDB (for Redis) Enterprise-level Features Demystified Multi-tenant Management ", author: GaussDB database.

HUAWEI CLOUD GaussDB (for Redis) continues to improve the enterprise-level enhanced features, which is worthy of the name "Redis Plus". Among them, the classic enterprise-level feature is the multi-tenant capability , which supports adding read-only accounts, read-write accounts, and can restrict each account Accessible database (DB) range to avoid misoperation of other tenant data. This feature can help enterprises protect the data security of different tenants when sharing Redis instances, and facilitate the development and management of enterprises.

Which users need to use the tenant management function?

Multi-tenancy is a function that database users just need. For example, there are two business departments A and B in an enterprise, and they both need to use Redis to store their own data. If the multi-tenancy permission function is not used, the data of A and B will be Mixed together, there is a risk of data leakage and misuse. Once the multi-tenant management function is used, the data of A and B can be stored in different Redis instances/DBs respectively, and the permissions of these instances/DBs can be controlled to ensure data security and reliability.

In the field of databases, multi-tenant technology often has the following standard attributes: such as read and write permission control, cross-DB authentication isolation, etc.; and GaussDB (for Redis) is a model with complete multi-tenant management technology, which realizes read and write The perfect fusion of the two features of authority control and database (DB) isolation.

Redis 6.0 already has the ACL function, why use the multi-tenant function of GaussDB (for Redis)?

Regarding permission control, although the open source Redis has ACL in the new version 6.0, it can only be set to read-only, read-write, and each account can still see all DBs. This design is rather tasteless and runs counter to the principle of database multi-tenancy. For example, business development Xiao Wang should use DB1, but one day he forgot to SELECT and accidentally cleared Xiao Zhang's DB0, which caused a production accident. The permission isolation of GaussDB (for Redis) solves this problem from the root. For example, if Xiao Wang is set to only have the permission of DB1 but not the permission of DB0, even if he misuses it, it will not affect the data of DB0.

In addition, the multi-tenant function of open source Redis can only be used on a single machine. Once the business needs to be clustered, the multi-DB function will not be available, leaving only one DB0; GaussDB (for Redis) has made multi-DB based on its own natural cluster architecture Enhanced, supports 6w+DB, and can create 200+ ACL sub-accounts at the same time to meet the needs of various business scenarios.

cke_8810.png

Comparison of the authority management capabilities of open source Redis 6.0 and GaussDB (for Redis)

The function sounds very comprehensive, how to use it?

The tenant management function of GaussDB (for Redis) requires users to create accounts on the account management page of the console, and set DB read-only/read-write permissions for each account. The operation is very intuitive and convenient. For example, the account test123 created in the figure below has read and write permissions and can only access DB1 and DB2.

cke_121.png

After the account is created, the user can directly use the "user:pwd" combination string as the password parameter in the program, and configure the target DB number to use the business-specific DB.

The following is a visual example to illustrate how to implement permission isolation between accounts through the multi-tenant management function. Zhuge Kongming, technical director of Shu State, needs to design different DB permissions for users of Shu State and partner Wu State, so as to achieve the two purposes of public information sharing and confidential information protection.

First, he set the read and write permissions of all DBs for Liu Bei; set the read and write permissions of "Taoyuan Jieyi" DB0 and "Huarong Road" DB1 and "Huarong Road" for general Guan Yu and Zhang Fei, and then set "Changbanpo" for secretary Zhao Yun Read-write permission for DB2 and read-only permission for other DBs (except "Taoyuan Jieyi" DB0). As for Wu's partners, Zhou Yu and Huang Gai were granted read and write access to the "Battle of the Red Cliff" DB3, while their lord Sun Quan was given read-only access to the "Battle of the Red Cliff" DB3.

Does it sound complicated and difficult to operate? In fact, the account management page of GaussDB (for Redis) is designed to be flexible and intuitive. Kong Ming can authorize Liu Bei by clicking "Authorize All Databases", select one or more DBs to authorize Guan Yu and Zhang Fei, and select "Unauthorized Databases". "Exempt Zhao Yun from the read-only permission of the "Taoyuan Jieyi" DB, which is very convenient for setting and post-management.

cke_122.png

cke_123.png

cke_124.png

cke_125.png

Summarize

This article introduces the comprehensive multi-tenant management features of GaussDB (for Redis) in detail, and uses several vivid examples as examples to illustrate the shortcomings of open source Redis account management capabilities and how GaussDB (for Redis) solves these shortcomings. In the current era of big data, the enterprise-level features of GaussDB (for Redis) perfectly make up for the shortcomings of open source Redis, and escort the data security of enterprises.

appendix

• The author of this article: Huawei Cloud Database GaussDB (for Redis) team

• Hangzhou/Xi'an/Shenzhen resume delivery: [email protected]

• For more product information, please visit the official blog: bbs.huaweicloud.com/blogs/248875

Click to follow and learn about Huawei Cloud's fresh technologies for the first time~

Guess you like

Origin blog.csdn.net/devcloud/article/details/131944764