JP2022148161A - Access control method and access control program - Google Patents

Abstract

An object of the present invention is to restrict access to a database for each software type. Kind Code: A1 A computer sends an access request to a data table, which originates from a port number temporarily assigned to software running in a first container provided on a managed node, from the managed node. receive. The computer then acquires the software name indicating the software corresponding to the port number from the second container provided on the managed node. Then, the computer decides whether to permit access to the data table in response to the access request based on the obtained software name and permission information in which the permitted software name indicating the permitted software to be permitted to access the data table is set. decide. [Selection drawing] Fig. 8

Description

The present invention relates to an access control method and an access control program.

In an operating environment in which various types of software such as application software are executed, it is very important to appropriately restrict access from each software to data in a database (DB: DataBase). In particular, when dealing with confidential information provided by a third party, if the confidential information is leaked due to negligence, it may develop into a serious problem. Therefore, it is required not only to suppress this by regulations and rules, but also to be able to restrict access by an access control mechanism within the computer system.

Software subject to access control may be executed in a virtual execution environment called a container. Containers that run software are managed using management software called orchestration tools. Orchestration tools often use software to control the network mechanism inside the cluster. As software for controlling the network mechanism, there is a mechanism called a sidecar proxy, for example. A typical example is OSS (Open Source Software) called Envoy.

The sidecar proxy can use the port number of software to perform control such as suppression of access from software to the DB. That is, in the case of accessing the DB via the network, each piece of software is assigned a communication port number. If the software has a fixed port number, it is possible to control access to the DB for that software based on the port number of the access request.

Also in a relational database management system (RDBMS), which is data management software, there is a mechanism for controlling access to data. In the RDBMS, access authority is set for each user, and data access is determined according to the authority. This privilege can be set at many granularities, such as per table, per row, and per column.

As a technique for managing containers, for example, a monitoring system has been proposed that can detect unauthorized behavior using the results of monitoring communications between containers.

JP 2020-115358 A

Among the software running on the container, there is a large amount of software that communicates using port numbers that are not in use at the time of data transmission. In this way, when software with a different port number for each communication accesses the DB via the network, the conventional technology cannot determine the type of software that has sent the access request from the port number. Therefore, it is difficult to restrict access to the DB for each software type.

In one aspect, the object of this case is to be able to restrict access to a DB for each software type.

In one proposal, the following access control method by computer is provided.
When the computer receives from the managed node an access request to the data table whose transmission source is the port number temporarily assigned to the software running in the first container provided on the managed node, the computer A software name indicating software corresponding to the port number is obtained from the second container provided on the target node. Then, the computer decides whether to permit access to the data table in response to the access request based on the obtained software name and permission information in which the permitted software name indicating the permitted software to be permitted to access the data table is set. decide.

According to one aspect, access to the DB can be restricted for each software type.

1 illustrates an example of an access control method according to a first embodiment; FIG. It is a figure which shows an example of the system configuration|structure of 2nd Embodiment. FIG. 3 is a diagram illustrating an example of hardware of a node; FIG. 4 is a diagram illustrating an example of access management to a DB for each application; FIG. 3 is a diagram showing a first example of reference technology regarding access control to a DB; FIG. 10 is a diagram showing a second example of reference technology regarding access control to a DB; 4 is a block diagram showing an example of an access control function for each application; FIG. FIG. 4 is a diagram showing the flow of information when accessing a DB; FIG. 11 is a flowchart showing an example of a procedure for acquiring a file path of an application; FIG. FIG. 5 is a diagram showing an example of Pod list information; It is a figure which shows an example of the acquisition method of a connection destination table name. FIG. 10 is a diagram illustrating an example of permission information acquired from a custom resource; FIG. FIG. 10 is a sequence diagram showing an example of speculative DB access processing; FIG. 11 is a sequence diagram showing an example of speculative DB access processing when query execution takes a long time; FIG. 12 is a block diagram showing an example of an access control function for each application according to the third embodiment; FIG.

Hereinafter, this embodiment will be described with reference to the drawings. It should be noted that each embodiment can be implemented by combining a plurality of embodiments within a consistent range.
[First Embodiment]
First, a first embodiment will be described.

FIG. 1 is a diagram showing an example of an access control method according to the first embodiment. FIG. 1 shows an example in which an information processing apparatus 10 implements an access control method. The information processing apparatus 10 is, for example, a computer, and can implement an access control method by executing an access control program. The information processing device 10 has a storage unit 11 and a processing unit 12 . The storage unit 11 is a memory included in the information processing device 10 or a storage device. The processing unit 12 is, for example, a processor or an arithmetic circuit included in the information processing device 10 .

The information processing device 10 is connected to the managed node 1 via a network. The managed node 1 is a computer that uses data in a DB whose access is controlled by the information processing device 10 . A managed node 1 is provided with a plurality of Pods 2a and 2b. Pod 2a includes a plurality of first containers 3a and 3b. Pod 2 b includes a second container 4 .

The first containers 3a and 3b in the Pod 2a execute software 5a and 5b that use data in the DB managed by the information processing device 10, respectively. The first containers 3a and 3b included in the same Pod 2a have a common address (for example, IP address) in communication via the network. Moreover, no fixed port number is assigned to each of the software 5a and 5b, and a free port number is assigned each time communication via the network occurs during the execution process of the software 5a and 5b. The software name of the software 5a is "sw_1". The software name of the software 5b is "sw_2".

A second container 4 in Pod 2 b runs monitoring software 6 . The second container 4 monitors communications of the first containers 3a and 3b via the network by executing monitoring software 6. FIG. For example, by executing the monitoring software 6, the second container 4 can acquire the software name of the software communicating using the port number. When Pods 2a and 2b share a network namespace with the operating system (OS) of the managed node 1, the second container 4 acquires from the OS a software name indicating software corresponding to the port number. be able to.

The storage unit 11 stores, for example, a plurality of data tables 11a and 11b forming a DB. The data table name of the data table 11a is "tbl_1". The data table name of the data table 11b is "tbl_2".

Data in each of the data tables 11a and 11b may have a defined purpose. If it is possible to restrict software that can use data for which usage is specified to software that uses the data only for the specified usage, it is possible to prevent the data from being used for unexpected usage. In the example of FIG. 1, it is assumed that the data in the data table 11a can be used by both software 5a and 5b, and the data in the data table 11b can be used only by the software 5b.

The processing unit 12 performs access control for each type of the software 5a, 5b. The types of the software 5a and 5b can be identified by their software names.
For example, the processing unit 12 manages access requests 7a to 7d to the data tables 11a and 11b whose transmission sources are the port numbers temporarily assigned to the software 5a and 5b executed in the first containers 3a and 3b. Receive from target node 1. The access request 7a is a request to access data in the data table 11a generated by the execution of the software 5a by the first container 3a. The access request 7b is a request to access data in the data table 11b generated by the execution of the software 5a by the first container 3a. The access request 7c is a request to access data in the data table 11a generated by the execution of the software 5b by the first container 3b. The access request 7d is a request to access data in the data table 11b generated by the execution of the software 5b by the first container 3b.

When the processing unit 12 receives any of the access requests 7a to 7d, the processing unit 12 sends the software name indicating the software corresponding to the port number of the transmission source of the received access request from the second container 4 provided on the managed node 1. to get The processing unit 12 determines permission or denial of access to the data table in response to the access request based on the obtained software name and permission information 12a. In the permission information 12a, a permitted software name indicating permitted software to be permitted to access each of the data tables 11a and 11b is set. For example, if the software name obtained from the second container 4 matches any of the permitted software names corresponding to the data table of the access destination of the access request, the processing unit 12 determines that the access is permitted. If the software name obtained from the second container 4 does not match any of the permitted software names corresponding to the data table of the access destination of the access request, the processing unit 12 decides to disallow access.

When the processing unit 12 determines to permit access, the processing unit 12 accesses the data table according to the access request. When the processing unit 12 determines to disallow access, the processing unit 12 suppresses access to the data table in response to the access request.

For example, in the permission information 12a, software names "sw_1, sw_2" of the software 5a and 5b are set as permitted software names of software permitted to access the data table 11a. Also, only the software name "sw_2" of the software 5b is set as the permitted software name of the software permitted to access the data table 11b. In this case, access is permitted according to the access requests 7a, 7c, and 7d. On the other hand, the access to the data table 11b generated by the execution of the software 5a is not permitted, and the access is denied.

In this way, the processing unit 12 acquires the software name corresponding to the port number from the second container 4 installed in the same managed node 1 as the first containers 3a and 3b, and temporarily assigned the software name. Recognize software using port numbers. As a result, the port number can be used to restrict access to the data table for each software.

Note that when the Pods 2a and 2b share a network namespace with the OS of the managed node 1, the second container 4 can easily acquire the software name corresponding to the port number from the OS. This enables efficient acquisition processing of the software name corresponding to the port number.

Pods 2 a and 2 b may not share the network namespace with the OS of managed node 1 . In this case, for example, a third container sharing a network address with the first containers 3a and 3b is provided in the Pod 2a. The third container acquires the file identification number within the file system of the executable file of the software 5a, 5b corresponding to the port number. A file identification number is, for example, an inode number. The second container 4 acquires the file identification number from the third container, and acquires the file path of the execution file corresponding to the file identification number from the OS. The second container 4 then transmits the acquired file path to the computer as a software name.

The OS of the managed node 1 normally manages files using one file system. Files used by Pods 2a and 2b operating on the OS are also managed by a common file system of the OS. In the file system, each file is assigned a file identification number, and the file identification number is unique within the managed node 1 . Therefore, if the file identification number of the executable file of the software is known, the file path of the executable file of the software can be acquired. The file path contains the filename of the executable file, which can be used as the software name for the corresponding software. Therefore, by using the file identification number of the software corresponding to the port number, it is possible to acquire the software name corresponding to the port number even if Pods 2a and 2b do not share the network namespace with the OS of the managed node 1. becomes.

In order to restrict access to each of the data tables 11a and 11b in the DB, it is necessary to define whether or not access is permitted for each set of data table and software in the permission information 12a. For example, the permission information 12a includes a plurality of sets of access target data table names indicating the access target data tables 11a and 11b and permission target software names indicating permission target software permitted to access the access target data tables. set. In this case, the processing unit 12 acquires data table names indicating the data tables 11a and 11b to be accessed based on the access requests 7a to 7d. Then, the processing unit 12 determines to permit the access when the set of the access target data table name and the permission target software name corresponding to the obtained set of the data table name and the software name is set in the permission information.

The access requests 7a to 7d contain the data table name of the data table to be accessed. Therefore, it is possible to extract the data table name from the access requests 7a-7d. However, there are various types of data formats for the access requests 7a to 7d, and it may be difficult for the processing unit 12 to analyze the contents of all the access requests 7a to 7d. In that case, the processing unit 12 may acquire execution plans for the access requests 7a to 7d from the DB management system that manages the data tables. The execution plan clearly states the data table name of the data table to be accessed. Therefore, the processing unit 12 acquires the name of the data table, which is the access destination corresponding to the access request, from the execution plan. By obtaining the data table names from the execution plans of the access requests 7a to 7d in this way, the data tables of the data tables 11a and 11b to be accessed can be reliably executed independently of the data format specifications of the access requests 7a to 7d. name can be obtained.

The processing unit 12 may speculatively access the data table according to the access requests 7a to 7d. In this case, the processing unit 12 executes access processing to the data tables 11a and 11b in response to the access requests 7a to 7d in parallel with acquiring the software name. If the processing unit 12 determines to permit access based on the acquired software name, the processing unit 12 transmits the result of the access processing to the source software of the access request. When the processing unit 12 determines not to permit access based on the acquired software name, the processing unit 12 suppresses the transmission of the access request as a result of the access processing to the source software. By performing processing in parallel in this way, it is possible to prevent a decrease in processing efficiency due to access restrictions for each piece of software.

If the access process takes a long time, the processing unit 12 may decide not to permit access before obtaining the result of the access process. In this case, the processing unit 12 may cancel the access process. For example, the processing unit 12 transmits a message indicating cancellation of access processing to the DB system that accesses the data tables 11a and 11b. This makes it possible to suppress an increase in the processing load of access processing caused by speculative processing.

[Second embodiment]
Next, a second embodiment will be described. The system according to the second embodiment speculatively executes DB access management for each application software (hereinafter referred to as an application), thereby suppressing DB access delays associated with access management.

FIG. 2 is a diagram showing an example of a system configuration according to the second embodiment. In the second embodiment, two nodes 100 , 200 and 300 are connected via network 20 . The node 100 uses containers to manage access from applications to DBs. The node 200 executes applications using containers. Node 300 manages containers running on nodes 100 and 200 .

FIG. 3 is a diagram illustrating an example of node hardware. A node 100 is entirely controlled by a processor 101 . A memory 102 and a plurality of peripheral devices are connected to the processor 101 via a bus 109 . Processor 101 may be a multiprocessor. The processor 101 is, for example, a CPU (Central Processing Unit), MPU (Micro Processing Unit), or DSP (Digital Signal Processor). At least part of the functions realized by the processor 101 executing the program may be realized by an electronic circuit such as an ASIC (Application Specific Integrated Circuit) or a PLD (Programmable Logic Device).

Memory 102 is used as the main storage device of node 100 . The memory 102 temporarily stores at least part of an OS program and application programs to be executed by the processor 101 . In addition, the memory 102 stores various data used for processing by the processor 101 . As the memory 102, for example, a volatile semiconductor memory device such as a RAM (Random Access Memory) is used.

Peripheral devices connected to the bus 109 include a storage device 103 , a GPU (Graphics Processing Unit) 104 , an input interface 105 , an optical drive device 106 , a device connection interface 107 and a network interface 108 .

The storage device 103 electrically or magnetically writes data to and reads data from a built-in recording medium. The storage device 103 is used as an auxiliary storage device for the computer. The storage device 103 stores an OS program, application programs, and various data. As the storage device 103, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive) can be used.

The GPU 104 is an arithmetic unit that performs image processing, and is also called a graphic controller. A monitor 21 is connected to the GPU 104 . The GPU 104 displays an image on the screen of the monitor 21 according to instructions from the processor 101 . Examples of the monitor 21 include a display device using an organic EL (Electro Luminescence), a liquid crystal display device, and the like.

A keyboard 22 and a mouse 23 are connected to the input interface 105 . The input interface 105 transmits signals sent from the keyboard 22 and mouse 23 to the processor 101 . Note that the mouse 23 is an example of a pointing device, and other pointing devices can also be used. Other pointing devices include touch panels, tablets, touchpads, trackballs, and the like.

The optical drive device 106 reads data recorded on the optical disc 24 or writes data on the optical disc 24 using laser light or the like. The optical disc 24 is a portable recording medium on which data is recorded so as to be readable by light reflection. The optical disc 24 includes DVD (Digital Versatile Disc), DVD-RAM, CD-ROM (Compact Disc Read Only Memory), CD-R (Recordable)/RW (ReWritable), and the like.

The device connection interface 107 is a communication interface for connecting peripheral devices to the node 100 . For example, the device connection interface 107 can be connected to the memory device 25 and the memory reader/writer 26 . The memory device 25 is a recording medium equipped with a communication function with the device connection interface 107 . The memory reader/writer 26 is a device that writes data to the memory card 27 or reads data from the memory card 27 . The memory card 27 is a card-type recording medium.

Network interface 108 is connected to network 20 . Network interface 108 transmits and receives data to and from other computers or communication devices via network 20 . The network interface 108 is a wired communication interface that is connected by a cable to a wired communication device such as a switch or router. Also, the network interface 108 may be a wireless communication interface that communicates with a wireless communication device such as a base station or an access point via radio waves.

The node 100 can implement the processing functions of the second embodiment with the above hardware. Nodes 200 and 300 can also be realized by hardware similar to node 100 shown in FIG. Note that the information processing apparatus 10 shown in the first embodiment can also be realized by hardware similar to the node 100 shown in FIG.

The node 100 implements the processing functions of the second embodiment, for example, by executing a program recorded on a computer-readable recording medium. A program describing the processing content to be executed by the node 100 can be recorded in various recording media. For example, a program to be executed by the node 100 can be stored in the storage device 103 . The processor 101 loads at least part of the program in the storage device 103 into the memory 102 and executes the program. The program to be executed by the node 100 can also be recorded in a portable recording medium such as the optical disk 24, memory device 25, memory card 27, or the like. A program stored in a portable recording medium can be executed after being installed in the storage device 103 under the control of the processor 101, for example. Alternatively, the processor 101 can read and execute the program directly from the portable recording medium.

Here, the access management to the DB for each application to be realized by the second embodiment will be described.
FIG. 4 is a diagram illustrating an example of DB access management for each application. Node 100 has DB 110 . Confidential information including personal information (address, name) is held in the DB 110 by RDBMS. In the RDBMS, data are divided and stored in a plurality of data tables. Each data table stores data conforming to the data definition defined for each data table. One or more data tables exist in an RDBMS, and each table may have a dependent relationship.

In the example of FIG. 4, the DB 110 has a registrant information table 111 and a purchase information table 112 . The registrant information table 111 has columns of registrant ID, registrant, age, and prefecture, and a plurality of records including data corresponding to each column are registered. The purchase information table 112 has columns of purchase ID, registrant ID, product ID, and date and time, and a plurality of records including data corresponding to each column are registered. The registrant information table 111 and the purchase information table 112 are related to each other via the registrant ID.

The node 200 accesses the DB 110 using containers 211 and 212 . The containers 211 and 212 are assumed to be managed by a container orchestration tool. The container orchestration tool manages containers on a Pod basis. Containers 211 and 212 are included in user application Pod 210 .

Containers within the same Pod, such as the containers 211 and 212 within the user application Pod 210, have a shared storage access environment/network access environment and use the same network namespace. Therefore, they can easily communicate with each other. Pods are often used with a single container that contains a program that does the main work and several containers that run supporting helper programs (log collectors, proxies, controllers, backups, etc.). be. A container that executes such a helper program is called a sidecar container.

The node 200 has a user application Pod210. A user application Pod 210 is an execution unit for executing an application. A user application Pod 210 has a plurality of containers 211 and 212 . An application 211a is running in the container 211 . An application 212a is running in the container 212 .

For example, the application 212a is assumed to be an application that anonymizes data read from the DB 110 . Since the registrant information table 111 contains the user's personal information, it is appropriate to use the data read out from the registrant information table 111 after performing anonymization processing. Therefore, the node 100 controls access so that the registrant information table 111 can be accessed only from the application 212a. In this case, the application 211a can access data in the registrant information table 111 via the application 212a. Since the purchase information table 112 does not contain personal information, the node 100 controls so that both applications 211a and 212a can access the purchase information table 112. FIG.

In this way, the node 100 performs access control so as to impose different access restrictions for each application on a table-by-table basis. The difficulty of performing access control that imposes different access restrictions for each application will be described below with reference to FIGS. 5 and 6. FIG.

FIG. 5 is a diagram showing a first example of a reference technique regarding access control to a DB. FIG. 5 shows an example of controlling access to the DB 110 by a container orchestration tool using a sidecar container. By inserting the proxy container 900 as a sidecar container, it is possible to perform filtering and store statistical information about communication via the proxy container 900 . For example, the proxy container 900 can perform filtering based on the source IP (Internet Protocol) address and port number of the access request to the DB 110 . The source IP address and port number can be obtained from the header of the packet used to transmit the access request. However, it is assumed that the proxy container 900 shown in FIG. 5 does not have the function of acquiring the identification information (such as the application name) of the applications 211a and 212a corresponding to the port numbers.

When the containers 211 and 212 are managed in Pod units, IP addresses are assigned in Pod units. Therefore, when filtering is performed using the IP address and port number of the transmission source using the proxy container 900, the applications 211a and 212a in the same user application Pod 210 cannot be identified only by the IP address. The source port numbers are assigned separately, but a free port number is used unless the source specifically sets it. That is, the port number used by each of the applications 211a and 212a is dynamically changed, and it is impossible for the proxy container 900 to determine the type of the source application of the access request from the port number of the access request.

Also, in the proxy container 900, the data table to be accessed cannot be grasped only by the IP address and port number. For this reason, it is not sufficient to know the type of application corresponding to the IP address and port number of the transmission source in order to determine whether or not to permit access according to the application for each table in the DB 110 of the proxy container 900 .

FIG. 6 is a diagram showing a second example of a reference technique regarding access control to a DB. FIG. 6 shows an example of enabling access control on a per-application basis using the access control function on a per-user basis in RDBMS.

RDBMS has a mechanism for limiting users who are allowed to access each table. Therefore, the Pod creator 30 executes the applications 211a and 212a with separate user accounts. For example, the application 211a is executed under the user account of "user B", and the application 212a is executed under the user account of "user A".

“User A” is set in the RDBMS as a user who can access data (registrant information) set in the registrant information table 111 . Also, “user A, user B” are set as users who can access data (purchase information) set in the purchase information table 112 . In this way, in the RDBMS, it is possible to define access rights for each table on a user-by-user basis. The RDBMS then allows access to the data from an application running under an accessible user's account.

In the example of FIG. 6, the application 211a running under the account of “user B” can access the purchase information table 112 but cannot access the registrant information table 111 . On the other hand, the application 212 a running under the account of “user A” can access both the registrant information table 111 and the purchase information table 112 . By using access authority management for user accounts in the RDBMS in this way, it is possible to control access for each application by associating user accounts with applications.

However, although the RDBMS can determine the user account of the application requesting access, it cannot ascertain which application is using it. Therefore, if the Pod creator 30 makes a mistake in setting the relationship between the application table in the RDBMS and the user account, there is a possibility that an application that should be denied access will be allowed to access the table.

Moreover, when individual user accounts are assigned to the multiple applications 211a and 212a, one Pod creator 30 manages multiple user accounts for executing the applications 211a and 212a. As the number of applications increases, misconfiguration of association between applications and user accounts is more likely to occur. Furthermore, limiting the user account used for application execution to the account of the Pod creator 30 reduces the flexibility of system operation, and is not a means that can be used for general purposes.

As described above, there is a problem that it is not possible to determine whether access to each table is permitted or not for each application with restrictions based on IP addresses and port numbers by proxies. On the other hand, the access control for each table is not suitable for performing access management by linking RDBMS users to applications because it makes system operation and management difficult.

Therefore, in the system shown in the second embodiment, access control is realized for each application without imposing an excessive burden on the Pod creator 30 . Although the DB 110 is managed by RDBMS in the second embodiment, the structure of DB 110 is not limited to RDBMS. For example, the application-by-application access control shown in the second embodiment can be applied to DBs whose access is controlled by types such as document DBs and graph DBs called NoSQL.

FIG. 7 is a block diagram showing an example of an access control function for each application. Node 100 has DB 110 and Pod 120 . The DB 110 is managed by RDBMS. The DB 110 and the Pods 120 are functions implemented by the processor 101 of the node 100 executing programs.

Pod 120 has proxy container 121 and DB container 122 . The proxy container 121 catches inter-container communication in the middle, determines whether or not the communication is permitted based on the source application and the content of the communication (query), and performs access control. The DB container 122 manages data in the DB 110 by RDBMS.

The proxy container 121 has a proxy unit 121a, an application information acquisition unit 121b, a permission information acquisition unit 121c, a connection destination table acquisition unit 121d, and a permission/denial determination unit 121e.

The proxy unit 121a acquires a query, which is an access request to the DB 110 from the applications 211a and 212a. The proxy unit 121a transfers the acquired query to the DB container 122, and in the case of accessing an accessible table, transmits the access result to the application that sent the query.

The application information acquisition unit 121 b acquires the location information of the monitoring container 221 from the API (Application Programming Interface) server 310 in the node 300 . Then, the application information acquisition unit 121b inquires of the monitoring container 221 about the information of the application corresponding to the port number of the transmission source of the query. The application information acquisition unit 121b transmits the acquired application information to the permission/refusal determination unit 121e.

The permission information acquisition unit 121c acquires, from the custom resource 320 in the node 300, permission information indicating the correspondence relationship between the table in the DB 110 to which access is permitted and the application. The permission information acquisition unit 121c transmits the acquired permission information to the permission determination unit 121e.

The connection destination table acquisition unit 121d acquires the name of the data table (connection destination table name) to be accessed according to the query from the DB container 122 . The connection destination table acquisition unit 121d transmits the acquired connection destination table name to the permission determination unit 121e.

The permission/refusal determination unit 121e determines whether or not to permit access according to the query, based on the application information corresponding to the port number of the transmission source of the query, the permission information, and the connection destination table name. The permission/refusal determination unit 121e transmits the determination result to the proxy unit 121a.

In the node 200, a container engine 202 is executed on an OS 201, and a user application Pod 210 and a monitoring Pod 220 are generated by the container engine 202. FIG. The OS 201, the container engine 202, the user application Pod 210, and the monitoring Pod 220 are functions implemented by the processor of the node 200 executing programs. Although omitted in FIG. 7, the Pod 120 is generated by the container engine running on the OS in the node 100 as well.

The monitoring Pod 220 has a monitoring container 221 . The monitoring container 221 has an internal application information acquisition unit 221a. The internal application information acquisition unit 221a acquires, via the OS 201, the file path (the directory path and file name of the program file of the application) of the application using the specific port number. For example, the monitoring container 221 shares a namespace with the OS 201 of the node 200 and is set to have root authority (authorization for all operations within the system for system administrators). The internal application information acquisition unit 221a in the monitoring container 221 uses the lsof command to check the correspondence between port numbers and PIDs (process IDs) for applications that share a namespace. The lsof command is a command to obtain a list of files opened by a process. Then, the internal application information acquisition unit 221a can access the file "/proc/[PID]/exe" indicating the link to the application program and obtain the file path of the application corresponding to the PID.

Node 300 has API server 310 and custom resource 320 . The API server 310 and the custom resource 320 are functions implemented by the processor of the node 300 executing programs.

The API server 310 is an API provided by a container orchestration tool, and manages information such as the location of each container (node executing the container). The custom resource 320 is an extension API of the container orchestration tool, and is an arbitrary function prepared by the Pod creator. For example, the custom resource 320 has permission information indicating a correspondence relationship between a data table and an application permitted to access the data table. Then, the custom resource 320 transmits permission information to the proxy container 121 in response to the permission information acquisition request.

The lines connecting the elements shown in FIG. 7 indicate part of the communication paths, and communication paths other than the illustrated communication paths can be set.
FIG. 8 is a diagram showing the flow of information when accessing a DB. For example, it is assumed that the application 212a within the container 212 outputs a query that refers to data within a table to which the application is permitted to access. The output query is sent to the proxy unit 121a within the proxy container 121. FIG. The proxy unit 121a transmits the IP address and port number of the transmission source of the query to the application information acquisition unit 121b. The proxy unit 121a also transmits a query to the connection destination table acquisition unit 121d.

The application information acquisition unit 121b transmits an inquiry about the location of the monitoring container 221 to the API server 310 . The API server 310 transmits position information indicating the position of the monitoring container 221 to the application information acquisition unit 121b. The application information acquisition unit 121 b transmits the port number of the query transmission source to the monitoring container 221 . The internal application information acquisition unit 221a in the monitoring container 221 acquires the file path of the application corresponding to the port number from the OS 201, and transmits the file path to the application information acquisition unit 121b. The application information acquisition unit 121b transmits the acquired file path to the permission determination unit 121e.

The permission information acquisition unit 121c transmits a permission information inquiry to the custom resource 320 . The custom resource 320 transmits permission information to the permission information acquisition unit 121c. The permission information acquisition unit 121c transmits the acquired permission information to the permission determination unit 121e.

The connection destination table acquisition unit 121d transmits to the DB container 122 the Explain command of the query sent from the proxy unit 121a. The DB container 122 transmits the explain result including the connection destination table name of the query to the connection destination table acquisition unit 121d. The connection destination table acquisition unit 121d transmits information indicating the connection destination table to the permission/refusal determination unit 121e.

The permission/refusal determination unit 121e determines permission/refusal of access based on the query based on the file path, permission information, and connection destination table name, and transmits the determination result (permission or non-permission) to the proxy unit 121a. The proxy unit 121a transmits the query to the DB container 122. FIG. The DB container 122 accesses the DB 110 according to the query using the RDBMS, and transmits the access result to the proxy unit 121a. The proxy unit 121a transmits the obtained access result to the application 212a when it is determined that the access is permitted.

According to the access control function as shown in FIGS. 7 and 8, the query to the DB 110 is caught by the proxy container 121 on the way, and based on the communication content (query) of the application of the transmission source, A connection destination table is specified. If permission information permitting access to the connection destination table from the identified application is set, the result of access to the DB 110 based on the query is transmitted to the application that sent the query.

Note that the IP address of the application that sent the query may change. Therefore, the proxy container 121 acquires the file path of the application corresponding to the port number of the transmission source of the query via the monitoring container 221 in the node 200 of the transmission source of the query. This makes it possible to uniquely identify the source application.

FIG. 9 is a flow chart showing an example of a procedure for acquiring a file path of an application. The processing shown in FIG. 9 will be described below along with the step numbers.
[Step S101] In the proxy container 121, the application information acquisition unit 121b receives the IP address and port number of the query transmission source from the proxy unit 121a.

[Step S<b>102 ] The application information acquisition unit 121 b acquires information on the monitoring Pod 220 from the API server 310 . For example, the application information acquisition unit 121b acquires Pod list information indicating all Pods managed by the API server 310 from the API server 310 . The application information acquisition unit 121b extracts information on the monitoring Pod 220 provided in the same node as the query transmission source from the acquired Pod list information. The extracted information includes the IP address of the monitoring Pod 220 .

FIG. 10 is a diagram illustrating an example of Pod list information. The Pod list information 31 indicates, for example, the IP address (IP) of the Pod, the name (NODE) of the node executing the Pod, etc., in association with the name (NAME) of the Pod. The application information acquisition unit 121b collates the IP address of the transmission source of the query with the IP column of the Pod list information 31 to identify a record with a matching IP address. The Pod list information 31 refers to the NODE column value (node name) of the specified record to recognize the node on which the Pod including the query transmission source application is operating. That is, it is possible to determine which node's monitoring Pod is the monitoring Pod to which the inquiry about the file path corresponding to the port number belongs.

The Pod name shown in the Pod list information 31 is, for example, an arbitrarily specified name on the left side of "-", and a hash value automatically given by the system on the right side of "-". Therefore, if the arbitrarily set name of the monitoring Pod is unified with, for example, "checkapp", the application information acquisition unit 121b determines which Pod is the monitoring Pod among the Pods in each node based on the value of the NAME column. It can be determined whether it is a Pod for use. The application information acquisition unit 121b identifies the monitoring Pod 220 including the target monitoring container 221 from the information in the NAME column and the NODE column of the identified record.

Hereinafter, the explanation will return to FIG.
[Step S<b>103 ] The application information acquisition unit 121 b transmits the source port number to the monitoring container 221 .

[Step S<b>104 ] In the monitoring container 221 , the internal application information acquisition unit 221 a acquires the PID corresponding to the port number from the OS 201 . For example, the internal application information acquisition unit 221a causes the OS 201 to execute the lsof command, and acquires the PID of the process being executed with the port number acquired from the application information acquisition unit 121b.

[Step S105] The internal application information acquisition unit 221a acquires the file path of the program corresponding to the PID. For example, the internal application information acquisition unit 221a accesses the file "/proc/[PID]/exe" ([PID] is the PID acquired in step S104) in the proxy container 121 and acquires information in the file. This file is a symbolic link to the executable file corresponding to the PID and contains the file path of that file.

[Step S<b>106 ] The internal application information acquisition unit 221 a transmits the file path of the application corresponding to the specified port number to the proxy container 121 .
In this way, the file path of the application corresponding to the port number can be obtained. As a result, even if the port number differs each time a query is sent from an application, the proxy container 121 can correctly recognize the application that sent the query.

In order to control access to a table for each application, the proxy container 121 acquires the connection destination table name to be connected for access, in addition to grasping the application that sent the query.

Note that a parser is used to analyze the query in order to extract the correct information from the query in the message. However, queries have various dialects for each DB, and it is difficult to implement a parser corresponding to all these DBs in the proxy container 121, and it may hinder extensibility.

Therefore, the proxy container 121 acquires the table to be accessed using the explain command for the query, which is information that is relatively easy to analyze. Explain syntax for queries is basically easy to retrofit, so you don't have to parse the query. In addition, many RDBMSs can return explain results as semi-structured data such as yaml and JSON (JavaScript Object Notation), and the name of the connection destination table can be easily extracted using the explain command.

FIG. 11 is a diagram illustrating an example of a method of acquiring a connection destination table name. When the application 212 a sends the query 41 to the proxy container 121 , the connection destination table acquisition unit 121 d inside the proxy container 121 generates an explain command 42 including the contents of the query 41 . The explain command 42 describes the contents of the query 41 following the statement "Explain". The connection destination table acquisition unit 121 d transmits the generated Explain command 42 to the DB container 122 .

Upon receiving the explain command 42 , the DB container 122 generates an execution plan for the query 41 indicated in the explain command 42 . The DB container 122 then transmits the execution plan as an explain result 43 to the proxy container 121 .

Shown in FIG. 11 is the explain result 43 in PostgreSQL. This explain result 43 includes the name of the connection destination table ""Relation Name":"t",". The proxy container 121 extracts the description of the name of the connection destination table from the explain result 43 as the connection destination table name.

In this manner, the proxy container 121 can generate the explain command 42 simply by adding the content of the query 41 to the explain command string. That is, when analyzing the query itself, the character string must be interpreted, but the explain command 42 can acquire the execution plan in JSON format as the explain result 43 . Execution plans in JSON format can be parsed by existing JSON libraries. Therefore, the proxy container 121 uses the JSON library to read the value of “Relation Name” in “Plan” in the Explain result 43 . The read value is the name of the connection destination table. By using the explain command 42 in this manner, the connection destination table can be easily determined.

The execution plan output function by the explain command 42 is implemented in many DBs, and MongoDB, which is NoSQL, and Neo4j, which is a graph DB, are no exception. That is, determination of the connection destination table using the explain command 42 is not limited to RDBMS, and can be similarly performed in various other DBs.

Permission information indicating the type of application permitted to access the connection destination table is predefined in the custom resource 320 by the Pod creator 30 . By acquiring permission information from the custom resource 320, the proxy container 121 can recognize applications permitted to access the connection destination table.

FIG. 12 is a diagram illustrating an example of permission information acquired from custom resources. For example, the proxy container 121 obtains permission information 51, 52, . One piece of permission information 51, 52, . . . is created for one RDB to which access is restricted. The permission information 51, 52, .

The proxy container 121 compares the set of the file path of the application that sent the query 41 and the name of the connection destination table with the permission information 51, 52, .

Note that communication with the monitoring container 221 and execution of the explain command 42 for obtaining a table may become overhead that cannot be ignored in the DB access process. Therefore, the proxy container 121 performs communication speculative execution.

FIG. 13 is a sequence diagram illustrating an example of speculative DB access processing. Upon receiving a query to the DB, the proxy container 121 performs, in parallel, application file path acquisition processing, connection destination table name acquisition processing, permission information acquisition processing, and query execution processing for the DB 110 .

The application file path acquisition process is divided into four steps S11 to S14. First, the proxy container 121 sends an inquiry about the location of the monitoring container 221 to the API server 310 (step S11). The API server 310 transmits, for example, Pod list information to the proxy container 121 as a query result (step S12). The proxy container 121 recognizes the location of the monitoring container 221 based on the inquiry result, and inquires of the monitoring container 221 about the application corresponding to the port number of the query transmission source (step S13). The monitoring container 221 transmits the file path of the application to the proxy container 121 (step S14). The above is the processing for acquiring the file path of the application.

The connection destination table name acquisition process is divided into two steps S21 and S22. First, the proxy container 121 transmits an explain command including the content of the query to the DB container 122 (step S21). In response to the explain command, the DB container 122 sends an explain result indicating the query execution plan (including the connection destination table name) to the proxy container 121 (step S22). The above is the connection destination table name acquisition processing.

Permission information acquisition processing is divided into two steps S31 and S32. First, the proxy container 121 requests permission information from the custom resource 320 (step S31). The custom resource 320 sends permission information groups regarding all data tables in the DB 110 to the proxy container 121 (step S32). The above is the acquisition processing of the permission information.

The query execution process is divided into two steps S41 and S42. First, the proxy container 121 requests execution of the query by sending the query to the DB container 122 (step S41). The DB container 122 connects to the data table accessed by the query, executes processing corresponding to the query on the data table, and transmits the execution result to the proxy container 121 (step S42). If the query requires data to be referenced, the execution result will contain the data according to the query. If the query requests data manipulation (update, deletion, etc.) within the DB 110, the execution result includes information indicating whether the manipulation process was successful. The above is the query execution processing.

The proxy container 121 determines whether or not to permit access when the application file path acquisition process, the connection destination table name acquisition process, and the permission information acquisition process are completed. If the proxy container 121 receives a query execution result before judging access permission or denial, the proxy container 121 waits for a response to the application until it becomes possible to judge access permission or denial. Then, when the proxy container 121 determines that the access to the connection destination table based on the query is permitted, the proxy container 121 transmits the execution result of the query to the application that sent the query (step S51). If the proxy container 121 determines that access to the connection destination table based on the query is not permitted, it sends a message indicating an authority error to the application that sent the query (step S52).

The example shown in FIG. 13 assumes that the query can be executed in a short time. If it takes a long time to execute a query, the access permission/denial decision may be obtained before the execution of the query is completed. In this case, if the access is not permitted, it is possible to minimize the occurrence of wasteful processing by canceling query execution.

FIG. 14 is a sequence diagram illustrating an example of speculative DB access processing when query execution takes a long time. Similar to FIG. 13, the application file path acquisition process, the connection destination table name acquisition process, the permission information acquisition process, and the query execution process for the DB 110 are performed in parallel. The contents of the application file path acquisition process, the connection destination table name acquisition process, and the permission information acquisition process are also the same as in FIG. Query execution processing is the same as in FIG. 13 up to the query execution request (step S41).

If the proxy container 121 determines that the access is permitted before the query execution ends, it waits for the execution result from the DB container 122 . After that, the DB container 122 sends the execution result to the proxy container 121 when execution of the query is finished (step S43). Then, the proxy container 121 transmits the execution result of the query to the application that sent the query (step S53).

On the other hand, if the proxy container 121 determines that the access is unauthorized before the query execution ends, the proxy container 121 indicates cancellation of the query execution to the DB container 122 without waiting for the query execution end. A message is transmitted (step S44). The proxy container 121 then sends a message indicating an authority error to the application that sent the query (step S54).

By performing such processing, it is possible to implement access control for each application while minimizing the overhead added to the original communication processing.
As described above, in the system of the second embodiment, the proxy container 121 investigates the PID and the file path of the application based on the information of the query transmission source, and uses the query to the RDBMS to determine the connection destination table name. to obtain. This solves the first problem that "restrictions based on IP addresses and port numbers make it impossible to separate application units and determine transmission destination tables." Furthermore, the proxy container 121 directly checks the permission information indicating the correspondence between the application and the data table, not the correspondence between the user and the data table. This also solves the second problem that access control for each table is not sufficient to link RDBMS users to applications.

[Third Embodiment]
The third embodiment makes it possible to specify an application corresponding to a port number even when the node 200 does not share a namespace between the OS 201 and other Pods. Differences between the third embodiment and the second embodiment will be described below.

In the second embodiment, it is assumed that the namespace (network namespace) of the Pod IP address and port number in the node 200 matches the namespace of the OS 201 . If this premise is satisfied, the PID can be traced by comparing the source port number with the port number list of the OS 201 (search by the lsof command), and the access control according to the procedure shown in the second embodiment can be performed. It becomes possible.

In order to satisfy the premise that the network namespaces match, the Pod creator 30 uses the option of sharing the network namespace with the OS 201 in the options when creating the container. For example, in the case of kubernetes, it is possible to match the network namespace by adding an option "HostNetwork" when creating a Pod (a group of containers grouped by function). However, sharing network namespaces increases the security risk, so this setting may not be possible.

In the second embodiment, the monitoring container 221 identifies the application from the port number. This is because the port number of the source application is used only in the network namespace within the user application Pod 210 and cannot be seen from the network namespace of the OS 201, which is the host OS.

Therefore, in the third embodiment, an information acquisition container is added in the user application Pod 210, and the file path of the application corresponding to the port number can be acquired via the information acquisition container.

FIG. 15 is a block diagram showing an example of an access control function for each application according to the third embodiment. The third embodiment differs from the second embodiment in that an information acquisition container 213 is added within the user application Pod 210 . Processing other than obtaining the file path of the application corresponding to the port number is the same as in the second embodiment. The process of acquiring the file path of the application corresponding to the port number in the third embodiment will be described below.

When the proxy container 121 obtains a query from the application 212a, it obtains the IP address and port number from the packet containing the query. Then, the proxy container 121 transmits an application query corresponding to the port number of the query transmission source to the information acquisition container 213 in the user application Pod 210 having the acquired IP address. The packet reception port number of the information acquisition container 213 is fixed, and the packet reception port number of the information acquisition container 213 is registered in the proxy container 121 in advance.

Based on the port number specified by the application inquiry, the information acquisition container 213 acquires the inode number corresponding to the port number. The inode number is an identification number of information (inode) regarding each of the files and directories managed by the file system. A port number has a file (for example, a received data buffer) used for communication using that port number, and an inode number is assigned to the file. An inode number is unique within a node 200 regardless of namespace.

The information acquisition container 213 inquires of the internal application information acquisition unit 221a in the monitoring container 221 about the application corresponding to the inode. The internal application information acquisition unit 221a searches the /proc directory for the designated inode number, and acquires the correspondence between the inode number and the file path of the application. The internal application information acquisition unit 221 a transmits the acquired file path of the application to the information acquisition container 213 . The information acquisition container 213 transmits the received file path of the application to the proxy container 121 .

In this way, the proxy container 121 can acquire the file path of the application corresponding to the port number even when the Pod in the node 200 and the OS 201 do not share the network namespace. .

Also, in the example of FIG. 15, the port number for data reception of the information acquisition container 213 is determined in advance. Therefore, the proxy container 121 can establish communication with the information acquisition container 213 without querying the API server. Also, the information acquisition container 213 can access the monitoring container 221 within the same node 200 using a UNIX (registered trademark) domain socket, which is a communication format used for connection within the same host. As described above, communication to the API server is unnecessary.

[Other embodiments]
In the second embodiment, an inquiry about the location of the monitoring container 221 is made each time a query is received. You can This makes it possible to omit the inquiry of the location of the monitoring container 221 to the API server 310 when subsequent queries are received.

In addition, in the second embodiment, the permission information acquisition process is performed each time a query is received, but once the permission information is acquired, the permission information may be held as a cache. As a result, when subsequent queries are received, the process of obtaining permission information from the custom resource 320 can be omitted.

Although the embodiment has been illustrated above, the configuration of each unit shown in the embodiment can be replaced with another one having the same function. Also, any other components or steps may be added. Furthermore, any two or more configurations (features) of the above-described embodiments may be combined.

1 managed node 2a, 2b Pod
3a, 3b first container 4 second container 5a, 5b software 6 monitoring software 7a-7d access request 10 information processing device 11 storage unit 11a, 11b data table 12 processing unit 12a permission information

Claims (8)

the computer
When a data table access request originating from a port number temporarily assigned to software running in a first container provided on a managed node is received from the managed node, Acquiring a software name indicating the software corresponding to the port number from a second container provided on the node;
Permission or denial of access to the data table in response to the access request is determined based on the obtained software name and permission information in which the permitted software name indicating the permitted software to be permitted to access the data table is set. decide,
Access control method. The second container acquires the software name indicating the software corresponding to the port number from the operating system of the managed node, and transmits the acquired software name to the computer.
The access control method according to claim 1. A third container sharing a network address with the first container obtains a file identification number within a file system of the software executable file corresponding to the port number;
The second container obtains the file identification number from the third container, obtains the file path of the executable file corresponding to the file identification number from the operating system, and uses the obtained file path as the software name. transmit to said computer;
3. The access control method according to claim 1 or 2. obtaining a data table name indicating the data table to be accessed based on the access request;
The permission information includes a set of an access target data table name indicating an access target data table contained in a database and the permission target software name indicating permission target software permitted to access the access target data table. and
In determining whether or not to permit access, if a set of the access target data table name and the permission target software name corresponding to the acquired set of the data table name and the software name is set in the permission information, access is permitted. decide to allow
4. The access control method according to any one of claims 1 to 3. Acquiring the data table name includes acquiring an execution plan for the access request from a database management system managing the data table, and acquiring the data table name from the execution plan.
5. The access control method according to claim 4. In parallel with acquiring the software name, executing access processing to the data table according to the access request,
if it is determined to permit access based on the acquired software name, sending the result of the access processing to the software that sent the access request;
when it is determined that access is not permitted based on the obtained software name, suppressing transmission of the result of the access process to the software that is the source of the access request;
6. The access control method according to any one of claims 1 to 5. canceling the access process if it is determined that the access is not permitted before obtaining the result of the access process;
7. The access control method according to claim 6. to the computer,
When a data table access request originating from a port number temporarily assigned to software running in a first container provided on a managed node is received from the managed node, Acquiring a software name indicating the software corresponding to the port number from a second container provided on the node;
Permission or denial of access to the data table in response to the access request is determined based on the obtained software name and permission information in which the permitted software name indicating the permitted software to be permitted to access the data table is set. decide,
The access control program that causes the action to take place.

Images