Distributed database access control method, system, equipment and medium
By adding tags to the distributed database components in the Kubernetes cluster and defining network policies using the Kubernetes tag selector mechanism, the security and reliability problems of traditional access control methods in dynamic changing environments are solved, and fine-grained and dynamic access control is achieved, which improves the security and reliability of distributed databases.
Patent Information
- Application Number
- CN202510623187.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-15
- Publication Date
- 2025-08-26
AI Technical Summary
In Kubernetes environment, traditional network access control methods are difficult to adapt to dynamically changing Pod IP addresses and complex service topology, and cannot achieve fine-grained and dynamic access control of distributed databases, resulting in insufficient security and reliability.
Add specific tags to each component of a distributed database in the Kubernetes cluster, use the Kubernetes tag selector mechanism to define inbound and outbound network policies, and dynamically update network policies through Kubernetes' apiServer to achieve fine-grained and dynamic access control.
It realizes accurate access control of distributed database components, improves data security and system reliability, adapts to complex and changeable business scenarios, dynamically responds to business needs, and improves security and management efficiency in the Kubernetes environment.
Smart Images
Figure CN120541858A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of database technology, and in particular to a distributed database access control method, system, device and medium. Background Art
[0002] With the rapid development of cloud computing and big data technologies, distributed databases have been widely used in enterprise applications due to their high scalability, high performance, and high availability. Kubernetes, as the de facto standard for container orchestration, provides strong support for the deployment and management of distributed databases. In a distributed database environment, different components (such as storage nodes, compute nodes, memory nodes, application services, etc.) need to work together while ensuring data security and integrity. By default, pods in a Kubernetes cluster can communicate freely with each other, which can pose security risks in production environments. For example, unauthorized access may lead to data leakage or corruption. Therefore, how to leverage the characteristics of Kubernetes to achieve fine-grained access control for distributed databases has become a pressing issue.
[0003] Traditional network access control methods are often based on IP addresses and ports, which makes it difficult to adapt to the dynamically changing Pod IP addresses and complex service topology in the Kubernetes environment. They cannot cope with the component relationships and access requirements within distributed databases, and it is difficult to achieve precise access control for specific database operations (such as reading, writing, and management).
[0004] Therefore, how to implement fine-grained and dynamic access control based on the component characteristics and business needs of distributed databases and improve the security and reliability of distributed databases in the Kubernetes environment is a technical problem that needs to be solved urgently. Summary of the Invention
[0005] The technical task of the present invention is to provide a distributed database access control method, system, device and medium to solve the problem of how to achieve fine-grained and dynamic access control based on the component characteristics and business requirements of the distributed database, and improve the security and reliability of the distributed database in the Kubernetes environment.
[0006] The technical task of the present invention is achieved in the following manner: a distributed database access control method, the method is as follows:
[0007] Add specific labels to the pods of each component of the distributed database in the Kubernetes cluster. Specific labels include component type labels and operation type labels.
[0008] Based on component type labels and operation type labels, Kubernetes' label selector mechanism is used to define inbound network policies to control external access to distributed database components.
[0009] Based on component type labels and operation type labels, Kubernetes' label selector mechanism is used to define outbound network policies to control external access to distributed database components.
[0010] When the business requirements of the distributed database change, the network policy is dynamically updated through the Kubernetes API Server.
[0011] Preferably, the component type label includes the label "component=database-storage" added to the storage node Pod, the label "component=database-compute" added to the computing node Pod, and the label "component=database-admin" added to the management node Pod;
[0012] Operation type labels include adding "operation=read" for Pods related to read operations, adding "operation=write" for Pods related to write operations, and adding "operation=read-write" for Pods related to read and write operations.
[0013] As a preference, use Kubernetes' label selector mechanism to define the inbound network policy as follows:
[0014] Configure "podSelector" to select the target database component Pod, specify the source Pod label to be accessed through the "from" field, and specify the ports to be accessed through the "ports" field, that is, "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"from":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}" to control external access to distributed database components.
[0015] Create an inbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically, for access to database components, only compute node Pods with the "component=database-compute" label and the "operation=read" label are allowed to access the read data port of the storage node Pod with the "component=database-storage" label; for management operations, only management node Pods with the "component=database-admin" label are allowed to access the management ports of storage nodes and compute nodes.
[0016] As a preference, use Kubernetes' label selector mechanism to define the outbound network policy as follows:
[0017] Configure "podSelector" to select the target database component Pod, use the "to" field to specify the target Pod label that is allowed to be accessed, and use the "ports" field to specify the allowed ports. For example, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}" to control external access to the distributed database component.
[0018] Create an outbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically: For compute node Pods, use the outbound network policy NetworkPolicy to limit the outbound traffic of compute node Pods, allowing only compute node Pods with the "component=database-compute" label to access the specific port of the log service Pod with the "component=logging-service" label; for storage node Pods, restrict the storage node Pods to only communicate with compute node Pods and management node Pods on specific ports, preventing the storage node Pods from transmitting data to unauthorized external nodes.
[0019] More optimally, when the business requirements of a distributed database change, the network policy can be dynamically updated through the Kubernetes API Server as follows:
[0020] When adding a new database operation type or adjusting the access relationship between components, add component type tags and operation type tags;
[0021] Create inbound network policies or outbound network policies based on specific services to dynamically update network policies.
[0022] A distributed database access control system, the system includes a tag adding module, an inbound policy definition module, an outbound policy definition module and a policy update module;
[0023] The label adding module is used to add specific labels to the Pods of each component of the distributed database in the Kubernetes cluster. Specific labels include component type labels and operation type labels.
[0024] The inbound policy definition module is used to define inbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components.
[0025] The outbound policy definition module is used to define outbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components.
[0026] The policy update module is used to dynamically update network policies through Kubernetes' API Server when the business requirements of the distributed database change;
[0027] Preferably, the component type label includes the label "component=database-storage" added to the storage node Pod, the label "component=database-compute" added to the computing node Pod, and the label "component=database-admin" added to the management node Pod;
[0028] Operation type tags include "operation=read", "operation=write", and "operation=read-write".
[0029] More optimally, the inbound network policy definition module selects the target database component Pod by configuring "podSelector", specifies the source Pod label allowed to be accessed through the "from" field, and specifies the port allowed to be accessed through the "ports" field, that is, "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"from":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", controls external access to distributed database components; and creates an inbound network policy NetworkPolicy through the Kubernetes apiServer, specifically: for access to the database component, only those with "component=database" are allowed. Compute node Pods with the "base-compute" label and the "operation=read" label access the read data port of the storage node Pod with the "component=database-storage" label; for management operations, only management node Pods with the "component=database-admin" label are allowed to access the management ports of storage nodes and compute nodes;
[0030] The outbound network policy definition selects the target database component Pod by configuring "podSelector", specifies the target Pod label allowed to be accessed through the "to" field, and specifies the allowed ports through the "ports" field, that is, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", which controls the external access of distributed database components. Access; and create an outbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically: for compute node Pods, the outbound network policy NetworkPolicy is used to limit the outbound traffic of compute node Pods, allowing only compute node Pods with the "component=database-compute" label to access the specific port of the log service Pod with the "component=logging-service" label; for storage node Pods, the storage node Pods are restricted to communicate only with compute node Pods and management node Pods on specific ports, preventing storage node Pods from transmitting data to unauthorized external nodes.
[0031] An electronic device comprising: a memory and at least one processor;
[0032] Wherein, the memory stores a computer program;
[0033] The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the above-mentioned distributed database access control method.
[0034] A computer-readable storage medium stores a computer program, and the computer program can be executed by a processor to implement the above-mentioned distributed database access control method.
[0035] The distributed database access control method, system, device, and medium of the present invention have the following advantages:
[0036] (1) When the present invention uses Kubernetes cluster to deploy distributed databases, specific labels containing component type and operation type identifiers are assigned to each component Pod, such as storage nodes, computing nodes, and control nodes, to clearly define the functions and operation permissions of each component. Based on these labels, Kubernetes network policies are used to build precise inbound and outbound network policies to accurately control external access to database components and external access of components. Only node Pods with specific labels are allowed to access the read and write data ports of node Pods with corresponding labels, strictly limiting data access paths to prevent illegal access. This solves the access control problems faced by distributed databases in the Kubernetes environment and improves data security and system reliability.
[0037] (2) Compared with traditional IP address-based access control technology, this invention breaks through the limitations of dynamic IP address changes and deeply integrates Kubernetes labels and API Server features. The advantages are as follows: ① It achieves refined configuration in policy construction and can adapt to complex and changing business scenarios; ② The dynamic update mechanism can respond to business needs in real time; ③ It significantly improves the security, reliability and management efficiency of distributed databases in the Kubernetes environment;
[0038] (3) The present invention can implement fine-grained, dynamic access control based on the component characteristics and business requirements of the distributed database, thereby improving the security and reliability of the distributed database in the Kubernetes environment;
[0039] (4) Through label-based resource identification and detailed network policy definition, the present invention can accurately control access between different components of a distributed database and external access to database components, achieving fine-grained access control for different operation types and different components, greatly improving database security;
[0040] (5) The present invention utilizes the dynamic characteristics of Kubernetes and its own API Server to easily update and adjust network policies to adapt to changes in business needs during the operation of the distributed database, ensuring the flexibility and scalability of the system;
[0041] (6) Compared with the traditional access control method based on IP address and port, the access control based on Kubernetes network policy of the present invention is more in line with the concept of service orchestration and management in the Kubernetes environment, and simplifies the network security management of distributed databases in the Kubernetes cluster. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] The present invention will be further described below with reference to the accompanying drawings.
[0043] Attachment Figure 1 It is a schematic diagram of the structure of a distributed database access control system;
[0044] Attachment Figure 2 A schematic diagram of cluster network policy relationships. DETAILED DESCRIPTION
[0045] The distributed database access control method, system, device and medium of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.
[0046] Example 1:
[0047] This embodiment provides a distributed database access control method, which is specifically as follows:
[0048] S1. Add specific labels to the pods of each component of the distributed database in the Kubernetes cluster. The specific labels include component type labels and operation type labels.
[0049] S2. Based on the component type label and operation type label, use Kubernetes' label selector mechanism to define inbound network policies to control external access to distributed database components.
[0050] S3. Based on the component type label and operation type label, use the Kubernetes label selector mechanism to define outbound network policies to control external access to distributed database components.
[0051] S4. When the business requirements of the distributed database change, the network policy is dynamically updated through the Kubernetes API Server.
[0052] The component type labels in step S1 of this embodiment include the label "component=database-storage" added to the storage node Pod, the label "component=database-compute" added to the computing node Pod, and the label "component=database-admin" added to the management node Pod.
[0053] The operation type label in step S1 of this embodiment includes adding "operation=read" for Pods related to read operations, adding "operation=write" for Pods related to write operations, and adding "operation=read-write" for Pods related to read and write operations.
[0054] In step S2 of this embodiment, the inbound network policy is defined using the Kubernetes label selector mechanism as follows:
[0055] S201. Select the target database component Pod by configuring "podSelector", specify the source Pod label allowed to be accessed through the "from" field, and specify the port allowed to be accessed through the "ports" field, that is, "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"from":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", to control external access to the distributed database component;
[0056] S202. Create an inbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically, for access to database components, only the compute node Pod with the "component=database-compute" label and the "operation=read" label is allowed to access the read data port of the storage node Pod with the "component=database-storage" label; for management operations, only the management node Pod with the "component=database-admin" label is allowed to access the management ports of the storage node and compute node.
[0057] In step S3 of this embodiment, the outbound network policy is defined using the Kubernetes label selector mechanism as follows:
[0058] S301. Select the target database component Pod by configuring "podSelector", specify the target Pod label allowed to be accessed through the "to" field, and specify the allowed ports through the "ports" field, that is, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}" to control external access to the distributed database component;
[0059] S302. Create an outbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically: for the compute node Pod, limit the outbound traffic of the compute node Pod through the outbound network policy NetworkPolicy, and only allow the compute node Pod with the "component=database-compute" label to access the specific port of the log service Pod with the "component=logging-service" label; for the storage node Pod, limit the storage node Pod to communicate only with the compute node Pod and the management node Pod on specific ports, and prevent the storage node Pod from transmitting data with unauthorized external nodes.
[0060] In step S4 of this embodiment, when the business requirements of the distributed database change, the network policy is dynamically updated through the Kubernetes API Server as follows:
[0061] S401. When a new database operation type is added or the access relationship between components needs to be adjusted, a component type tag and an operation type tag are added;
[0062] S402: Create an inbound network policy or an outbound network policy according to specific services to dynamically update the network policy.
[0063] Example 2:
[0064] As attached Figure 1 and 2 As shown, this embodiment provides a distributed database access control system, which includes a label adding module, an inbound policy definition module, an outbound policy definition module, a policy update module, and a Kubernetes network policy management module that comes with the Kubernetes cluster;
[0065] The label adding module is used to add specific labels to the Pods of each component of the distributed database in the Kubernetes cluster. Specific labels include component type labels and operation type labels.
[0066] The inbound policy definition module is used to define inbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components.
[0067] The outbound policy definition module is used to define outbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components.
[0068] The policy update module is used to dynamically update network policies through Kubernetes' API Server when the business requirements of the distributed database change;
[0069] The Kubernetes network policy management module is used to manage inbound network policies, outbound network policies, call the API Server to dynamically update network policies, and apply the corresponding network policies to the Pod, a distributed database component in the Kubernetes cluster.
[0070] The component type labels in this embodiment include the label "component=database-storage" added to the storage node Pod, the label "component=database-compute" added to the compute node Pod, and the label "component=database-admin" added to the management node Pod;
[0071] At the same time, according to the database operation type, operation type labels are added to Pods related to different operations; among them, operation type labels include "operation=read", "operation=write", and "operation=read-write".
[0072] Leveraging K8s' label selector mechanism, you can precisely locate the set of pods requiring access control by defining component type labels. For example, using "podSelector:{matchLabels:{component:database-storage}}" selects all storage node pods.
[0073] The inbound network policy definition module in this embodiment selects the target database component Pod by configuring "podSelector", specifies the source Pod label allowed to be accessed through the "from" field, and specifies the ports allowed to be accessed through the "ports" field, that is, "{"podSelector":{"matchLabels":{"componen t":"-"}},"egress":[{"from":[{"podSelector":{"matchLabels":{"componen t":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", controls external access to distributed database components; and creates an inbound network policy NetworkPolicy through Kubernetes's apiServer. Specifically, for access to database components, only compute node Pods with the "component=database-compute" label and the "operation=read" label are allowed to access the read data port of the storage node Pod with the "component=database-storage" label; for management operations, only management node Pods with the "component=database-admin" label are allowed to access the management ports of storage nodes and compute nodes.
[0074] The outbound network policy definition in this embodiment selects the target database component Pod by configuring "podSelector", specifies the target Pod label allowed to be accessed through the "to" field, and specifies the allowed ports through the "ports" field, that is, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"compon ent":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", controls the external access of the distributed database component; and creates an outbound network policy NetworkPolicy through the Kubernetes apiServer, specifically: for the computing node Pod, the outbound network policy NetworkPolicy is used. cy restricts the outbound traffic of compute node Pods, allowing only compute node Pods with the "component=database-compute" label to access the specific port of the log service Pod with the "component=logging-service" label; for storage node Pods, it restricts storage node Pods to communicate only with compute node Pods and management node Pods through specific ports, preventing storage node Pods from transmitting data to unauthorized external nodes.
[0075] The policy update module in this embodiment is used to call the label adding module to add component type labels and operation type labels when the business requirements of the distributed database change, such as when a new database operation type is added, or when the access relationship between certain components needs to be adjusted. It calls the inbound policy definition module to create an inbound network policy or calls the outbound policy definition module to create an outbound network policy according to specific business needs to dynamically update the network policy.
[0076] Example 3:
[0077] This embodiment also provides an electronic device, including: a memory and a processor;
[0078] wherein the memory stores computer-executable instructions;
[0079] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the distributed database access control method in any embodiment of the present invention.
[0080] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor may be a microprocessor or any conventional processor, etc.
[0081] The memory can be used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area. The program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, the memory can also include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart card (SMC), a secure digital (SD) card, a flash memory card, at least one disk storage period, a flash memory device, or other volatile solid-state memory devices.
[0082] Example 4:
[0083] This embodiment further provides a computer-readable storage medium storing a plurality of instructions, which are loaded by a processor to cause the processor to execute the distributed database access control method according to any embodiment of the present invention. Specifically, a system or device equipped with a storage medium can be provided, wherein the storage medium stores software program code that implements the functions of any of the above-described embodiments, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.
[0084] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute part of the present invention.
[0085] Examples of storage media for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RYMs, DVD-RWs, DVD+RWs), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer via a communications network.
[0086] In addition, it should be clear that the functions of any of the above embodiments can be achieved not only by executing the program code read by the computer, but also by enabling the operating system operating on the computer to complete part or all of the actual operations based on the instructions of the program code.
[0087] In addition, it can be understood that the program code read from the storage medium is written into the memory provided in the expansion board inserted into the computer or into the memory provided in the expansion unit connected to the computer, and then based on the instructions of the program code, the CPU installed on the expansion board or expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above embodiments.
[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.
Claims
1. A distributed database access control method, characterized in that: The method is as follows: Add specific labels to the pods of each component of the distributed database in the Kubernetes cluster. Specific labels include component type labels and operation type labels. Based on component type labels and operation type labels, Kubernetes' label selector mechanism is used to define inbound network policies to control external access to distributed database components. Based on component type labels and operation type labels, Kubernetes' label selector mechanism is used to define outbound network policies to control external access to distributed database components. When the business requirements of the distributed database change, the network policy is dynamically updated through the Kubernetes API Server.
2. The distributed database access control method according to claim 1, characterized in that: Component type labels include the label "component=database-storage" added to storage node pods, the label "component=database-compute" added to compute node pods, and the label "component=database-admin" added to management node pods. Operation type labels include adding "operation=read" for Pods related to read operations, adding "operation=write" for Pods related to write operations, and adding "operation=read-write" for Pods related to read and write operations.
3. The distributed database access control method according to claim 1, characterized in that: The inbound network policy is defined using the Kubernetes label selector mechanism as follows: Select the target database component Pod by configuring "podSelector", specify the source Pod label allowed to be accessed through the "from" field, and specify the allowed ports through the "ports" field, that is, "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"from":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", to control external access to distributed database components; Create an inbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically, for access to database components, only compute node Pods with the "component=database-compute" label and the "operation=read" label are allowed to access the read data port of the storage node Pod with the "component=database-storage" label. For management operations, only management node Pods with the "component=database-admin" label are allowed to access the management ports of storage nodes and compute nodes.
4. The distributed database access control method according to claim 1, characterized in that: The outbound network policy is defined using the Kubernetes label selector mechanism as follows: Select the target database component Pod by configuring "podSelector", specify the target Pod label allowed to be accessed through the "to" field, and specify the allowed ports through the "ports" field. For example, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}" to control external access to the distributed database component. Create an outbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically: For compute node pods, use the outbound network policy NetworkPolicy to restrict the outbound traffic of compute node pods, allowing only compute node pods with the "component=database-compute" label to access the specific port of the logging service pod with the "component=logging-service" label; for storage node pods, restrict storage node pods to only communicate with compute node pods and management node pods on specific ports, preventing storage node pods from transmitting data to unauthorized external nodes.
5. The distributed database access control method according to any one of claims 1 to 4, characterized in that: When the business requirements of a distributed database change, the network policy is dynamically updated through the Kubernetes API Server as follows: When adding a new database operation type or adjusting the access relationship between components, add component type tags and operation type tags; Create inbound network policies or outbound network policies based on specific services to dynamically update network policies.
6. A distributed database access control system, characterized in that: The system includes a label adding module, an inbound policy definition module, an outbound policy definition module and a policy updating module; The label adding module is used to add specific labels to the Pods of each component of the distributed database in the Kubernetes cluster. Specific labels include component type labels and operation type labels. The inbound policy definition module is used to define inbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components. The outbound policy definition module is used to define outbound network policies based on component type labels and operation type labels using Kubernetes' label selector mechanism to control external access to distributed database components. The policy update module is used to dynamically update network policies through Kubernetes's API Server when the business requirements of the distributed database change.
7. The distributed database access control system according to claim 6, characterized in that: Component type labels include the label "component=database-storage" added to storage node pods, the label "component=database-compute" added to compute node pods, and the label "component=database-admin" added to management node pods. Operation type tags include "operation=read", "operation=write", and "operation=read-write".
8. The distributed database access control system according to claim 6 or 7, characterized in that: The inbound network policy definition module selects the target database component Pod by configuring "podSelector", specifies the source Pod label allowed to be accessed through the "from" field, and specifies the port allowed to be accessed through the "ports" field, that is, "{"podSelector":{"matchLabels":{"component":"-"}},"egre ss":[{"from":[{"podSelector":{"matchLabels":{"component":"-"}},"port s":[{"protocol":"TCP","port":"-"}]}]}]}", controls external access to distributed database components; and creates an inbound network policy NetworkPolicy through the Kubernetes apiServer, specifically: for access to database components, only computing node Pods with the "component=database-compute" label and the "operation=read" label are allowed to access the Pod with the "component=database-compute" label. The data read port of the storage node Pod with the "component=database-storage" label. For management operations, only the management node Pod with the "component=database-admin" label is allowed to access the management ports of the storage nodes and compute nodes. The outbound network policy definition selects the target database component Pod by configuring "podSelector", specifies the target Pod label allowed to be accessed through the "to" field, and specifies the allowed ports through the "ports" field, that is, configure "{"podSelector":{"matchLabels":{"component":"-"}},"egress":[{"to":[{"podSelector":{"matchLabels":{"component":"-"}},"ports":[{"protocol":"TCP","port":"-"}]}]}]}", controls the external access of distributed database components Access; and create an outbound network policy NetworkPolicy through the Kubernetes apiServer. Specifically: for compute node Pods, the outbound network policy NetworkPolicy is used to limit the outbound traffic of compute node Pods, allowing only compute node Pods with the "component=database-compute" label to access the specific port of the log service Pod with the "component=logging-service" label; for storage node Pods, the storage node Pods are restricted to communicate only with compute node Pods and management node Pods on specific ports, preventing storage node Pods from transmitting data to unauthorized external nodes.
9. An electronic device, characterized in that: include: memory and at least one processor; Wherein, the memory stores a computer program; The at least one processor executes the computer program stored in the memory, so that the at least one processor performs the distributed database access control method according to any one of claims 1 to 5.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which can be executed by a processor to implement the distributed database access control method according to any one of claims 1 to 5.