Method, device, and computer-readable recording medium for controlling distribution and execution of container image based on security kernel

Abstract

The present invention comprises: a resource data collection step of collecting resource data of a container workload running on a cloud; an execution operation definition step of defining a list of executable files and processes inside a container on the basis of SBOM; a policy application step of configuring a whitelist-based access control policy for container runtime on the basis of the collected resource data and the defined execution operation, and applying same to a kernel; a distribution step of, if there is an execution request for a specific container from a client account accessing a cloud API, checking whether a container image requested to be executed is in a docker hub and then distributing the container image to a client terminal; and an execution control step of, upon execution of the distributed container, monitoring, by a kernel agent at a kernel level, a system call of a container instance, to thereby control the execution of the container.

Description

Method for controlling the distribution and execution of a container image based on a secure kernel, device, and computer-readable recording medium

[0001] The present invention relates to a method for controlling the distribution and execution of a container image based on a security kernel, and more particularly, to a technology for creating a secure distribution and execution environment for containers by defining authorized files and processes in a CRD and performing access control based thereon in order to control malicious actions of attackers through container runtime vulnerabilities.

[0002] In addition, this application has been filed as a result of a project having the following information: Project Identification Number: 1711193290, Subproject Number: 2020-0-00952-004, Ministry of Science and ICT, Project Management (Specialized) Agency Name: Information and Communications Technology Planning and Evaluation Institute, Research Project Name: ICT Infrastructure-Service Protection Reinforcement, Research Project Name: Development of Edge Security Technology to Ensure 5G+ Service Stability, Contribution Rate: 1 / 1, Project Performing Agency Name: Electronics and Telecommunications Research Institute, Research Period: 2020.04.01.~2023.12.31.

[0003]

[0004] With the technological advancement of computer networks, the existing computing environment that depended on the independent hardware performance of each terminal has evolved into the form of cloud computing that utilizes all computing resources on the network to provide services in a simple and easy manner upon request from user terminals.

[0005] Currently, when building IT infrastructure, cloud computing technology is commonly used in server and system configuration due to its advantages of allowing IT resources to be shared and idle resources to be used efficiently.

[0006] Meanwhile, virtualization technology can be considered a core foundation technology of cloud computing, and open server virtualization technologies widely used in the server field include hypervisor-based technologies such as Xen and KVM.

[0007] As a prior art document related to virtual machine-based server virtualization technology, there is Korean Patent No. 10-2327886 (Virtual machine operating device and method), and the virtual machine-based server virtualization technology can be understood as a method of installing an operating system (host OS) on a physical server as disclosed in the prior art document, dividing resources based on a hypervisor thereon to create a virtual machine, and then installing an operating system (guest OS) again to run a desired application program.

[0008] This method has the advantage of being able to have multiple servers that can operate independently on a single physical system, but there is a problem that there is a lot of waste of resources when the host OS and guest OS are each operating independently. To solve this problem, container technology, a virtualization technology different from virtual machines, has recently been attracting attention.

[0009] Meanwhile, these container-based systems have the advantage of being much lighter and more portable than virtual machine methods because they share the kernel of the operating system, and taking up less memory than booting the entire operating system. However, according to a Sysdick survey last year, 75% of containers had serious security vulnerabilities, and 62% of containers had shells that could be maliciously exploited. As cyberattacks related to container escape vulnerabilities increase, the demand for a secure virtual container environment is growing.

[0010] Accordingly, the purpose of the present invention is to create a safe deployment and execution environment for containers by defining authorized files and processes within a container in a CRD and performing access control based thereon in order to control malicious actions of attackers through container runtime vulnerabilities.

[0011] In addition, the present invention has another purpose of providing enhanced security technology for internal resources by deploying a container execution control tool in a Kubernetes cluster and blocking access by unauthorized clients through Kubernetes role-based access control (RBAC).

[0012] In addition, another purpose of the present invention is to provide a security technology that prevents the host operating system from being affected even if the container is exposed to a problem such as hacking by allowing the container to share the Linux kernel and run the process in an isolated environment using virtualization technology.

[0013] In order to achieve the above-described object, according to an embodiment of the present invention, a method for distributing and controlling execution of a container image based on a secure kernel, which is implemented as a computing device including one or more processors and one or more memories for storing commands executable by the processors, is characterized by including: a resource data collection step for collecting resource data of a container workload running on a cloud; an execution operation definition step for defining a list of executable files and processes within a container based on a Software bill of materials (SBOM); a policy application step for configuring a whitelist-based access control policy at container runtime based on the collected resource data and the defined execution operation, and applying the configured access control policy to the kernel; a distribution step for checking whether the requested container image exists in Docker Hub when an execution request for a specific container exists from a client account connected to a cloud API, and then distributing the container image to a client terminal; and, an execution control step for controlling the execution of a container when the container deployed on the client terminal is executed by a kernel agent at a kernel level to which the access control policy is applied, by monitoring a system call of a container instance.

[0014] At this time, the security area of ​​the container runtime described above includes a kernel agent located at the kernel level as a container execution control tool, a webhook server located at the application level, a container security module, and an access control policy server, and it is preferable that the container execution control tool is an operator deployed in a Kubernetes cluster.

[0015] In addition, it is preferable that the above-described distribution step, before distributing the container image to the client terminal, uses a container security module to analyze the source code of the container image extracted from the Docker Hub using an IaC (Infrastructure of code) scan tool to confirm whether the container image is a trustworthy container image.

[0016] In addition, it is desirable that the execution action definition step described above defines the execution action by creating a CRD (Custom Resource Definition) in which the scope of the list of executable files and processes is differentiated according to the role and authority granted to the client account, and that the webhook server evaluates whether the execution action defined in the CRD is being performed in the client account.

[0017] In addition, it is desirable that the above-described execution control step monitors system calls for commands and file access executed by a client account for containers running under a client account, and, as a result of the monitoring, rejects the invocation of a system call when the execution of a command that violates the access control policy or a system call related to file access is detected.

[0018] In addition, the above-described kernel preferably creates an isolated environment with an independent directory structure for each process authorized to the container by changing the path mounted in the root directory to a point corresponding to the authorized process through the pivot_root system call in order to block execution of processes other than those authorized to the container.

[0019] Meanwhile, according to an embodiment of the present invention, a device for distributing and controlling execution of a container image based on a secure kernel, which is implemented as a computing device including one or more processors and one or more memories for storing commands executable by the processors, is characterized by including: a resource data collection unit for collecting resource data of a container workload running on a cloud; an execution operation definition unit for defining a list of executable files and processes within a container based on a Software bill of materials (SBOM); a policy application unit for configuring a whitelist-based access control policy at container runtime based on the collected resource data and the defined execution operation, and applying the configured access control policy to the kernel; a distribution unit for checking whether the requested execution container image exists in Docker Hub when there is an execution request for a specific container from a client account connected to a cloud API, and then distributing the container image to a client terminal; and, an execution control unit for controlling the execution of a container by having a kernel-level kernel agent to which an access control policy is applied monitor a system call of a container instance when the container deployed to the client terminal is executed.

[0020] On the other hand, in a computer-readable recording medium, the computer-readable recording medium stores instructions that cause a computing device to perform the following steps, wherein the steps include: a resource data collection step of collecting resource data of a container workload running on a cloud; an execution operation definition step of defining a list of executable files and processes within a container based on a Software bill of materials (SBOM); a policy application step of configuring a whitelist-based access control policy in a container runtime based on the collected resource data and the defined execution operation, and applying the configured access control policy to a kernel; a distribution step of verifying whether a container image to which an execution request is made exists in Docker Hub when there is an execution request for a specific container from a client account connected to a cloud API, and then distributing the container image to a client terminal; and, an execution control step of controlling the execution of a container by having a kernel agent at a kernel level to which an access control policy is applied monitor a system call of a container instance when the container deployed to the client terminal is executed.

[0021] According to one embodiment of the present invention, the present invention defines authorized files and processes within a container in a CRD and performs access control based thereon, thereby enabling safe deployment of the container and creating a safe execution environment.

[0022] In addition, according to one embodiment of the present invention, the present invention can provide enhanced security effects for internal resources by deploying a container execution control tool in a Kubernetes cluster and blocking access by clients not authorized by Kubernetes role-based access control (RBAC).

[0023] In addition, according to one embodiment of the present invention, by using virtualization technology, the present invention allows the container to share the Linux kernel and execute the process in an isolated environment, so that even if the container is exposed to a problem such as hacking, the host operating system is not affected, and the scale of damage caused by hacking can be reduced.

[0024] FIG. 1 is a flowchart of a method for controlling distribution and execution of a container image based on a security kernel according to an embodiment of the present invention.

[0025] FIG. 2 is an architecture for a security area of ​​a container runtime according to an embodiment of the present invention.

[0026] Figures 3 and 4 are examples of performing execution control for a container based on an authorized process according to one embodiment of the present invention.

[0027] FIG. 5 is an example of analyzing a system call of a running container instance to control execution of the container according to an embodiment of the present invention.

[0028] FIG. 6 is a configuration diagram of a device for controlling the distribution and execution of a container image based on a security kernel according to an embodiment of the present invention.

[0029] Figure 7 is an example of the internal configuration of a computing device according to one embodiment of the present invention.

[0030] Hereinafter, various embodiments and / or aspects are now disclosed with reference to the drawings. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of one or more aspects. However, it will be apparent to one skilled in the art that such aspects may be practiced without these specific details. The following description and the attached drawings detail specific exemplary aspects of one or more aspects. However, these aspects are exemplary, and it is to be understood that any of the various methods within the principles of the various aspects may be utilized, and the description is intended to encompass all such aspects and their equivalents.

[0031] The terms “embodiment,” “example,” “aspect,” “example,” and the like as used herein may not be construed to imply that any aspect or design described is better or advantageous over other aspects or designs.

[0032] Additionally, it should be understood that the terms “comprises” and / or “comprising” imply the presence of the features and / or components, but do not preclude the presence or addition of one or more other features, components and / or groups thereof.

[0033] Additionally, terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but the components are not limited by the terms. The terms are used solely to distinguish one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. The term and / or includes a combination of a plurality of related described items or any of a plurality of related described items.

[0034] Additionally, in the embodiments of the present invention, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by those of ordinary skill in the art to which the present invention pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined in the embodiments of the present invention.

[0035] The present invention relates to a method for controlling the distribution and execution of a container image based on a security kernel, and more specifically, to control malicious actions of an attacker through a container runtime vulnerability, by defining authorized files and processes in a CRD within a container and performing access control based thereon, thereby creating a safe distribution and execution environment for containers, and another object is to provide enhanced security technology for internal resources by deploying a container execution control tool in a Kubernetes cluster and blocking access by unauthorized clients with Kubernetes role-based access control (RBAC). In addition, the present invention provides a security technology that prevents the host operating system from being affected even if the container is exposed to a problem such as hacking by using virtualization technology to allow the container to share the Linux kernel while executing the process in an isolated environment.

[0036] Hereinafter, a detailed description of the present invention for achieving the above objectives will be described with reference to the attached drawings, and multiple drawings may be referenced simultaneously to describe one or more technical features or components constituting the invention.

[0037] First, referring to FIG. 1, FIG. 1 illustrates a flowchart of a method for controlling distribution and execution of a container image based on a security kernel (50) according to an embodiment of the present invention.

[0038] As illustrated in FIG. 1, in the present invention, a resource data collection step (S10) is performed to collect resource data of a container workload running on a cloud (20).

[0039] Specifically, the S10 step described above can be understood as collecting information on resources running on the cloud (20) to set policies such as file integrity, process integrity, and traffic control, for example, collecting information on clusters, namespaces, PODs, containers, and services.

[0040] Next, after performing the above-described S10 step, an execution operation definition step (S20) is performed to define a list of executable files and processes within the container based on the SBOM (40) (Software bill of materials).

[0041] Specifically, in the S20 step described above, execution behavior can be defined by creating a Custom Resource Definition (CRD) in which the scope of the list of executable files and processes is differentiated according to the role and authority granted to the client account.

[0042] That is, in the present invention, RBAC (Role-based access control) is performed. For example, RBAC-based access control allows only files and processes that are set to be accessible to PR team members to be executed when the role of a client account is PR team members, and prevents execution of files and processes that are set to be accessible to finance team members. Of course, in this case, RBAC-based access control may vary the scope of accessible containers depending on the authority of the client account. In one embodiment, if the authority set to the client account is a special user authority such as a super user, an administrator, or a root authority, more files and processes may be executed than a client account set with general user authority.

[0043] In addition, the SBOM (40) described above in step S20 is meta information about the software's configuration components, and can be understood as a concept of a specification that can identify the software's configuration components. In step S20, by defining a list of executable files and processes within a container based on the SBOM (40), the management efficiency of software components can be increased, and through this, it can contribute to resolving software supply chain threats.

[0044] Next, based on the resource data collected by performing the aforementioned S10 step and the execution operation defined in the S20 step, the present invention configures a whitelist-based access control policy in the container runtime, and a policy application step (S30) is performed to apply the configured access control policy to the kernel (50).

[0045] At this time, the security area of ​​the container runtime described above includes, as shown in the drawing in FIG. 2, a kernel (50) agent located at the kernel (50) level as a container execution control tool, a webhook server located at the application level, a container security module, and an access control policy server, and this container execution control tool can be understood as the concept of an operator deployed in a Kubernetes cluster.

[0046] Meanwhile, the kernel (50) agent described above communicates with the Kubernetes API and performs a function of allowing or denying execution requests for files and processes accessed from client accounts based on security policies. In one embodiment, the kernel (50) agent applies a whitelist-based access control policy, thereby denying the execution of all files and processes other than those authorized. In other words, this has the same effect as blacklisting all actions except for accessing files and executing processes listed on the whitelist, thereby functioning as a security solution that provides enhanced security.

[0047] Additionally, the aforementioned webhook server performs a function of evaluating whether the execution action defined in the CRD is being performed in the client account. In other words, it evaluates whether RBAC-based access control is being performed.

[0048] Accordingly, when a client account makes an execution request for a specific container, the webhook server can determine whether to approve or reject the execution request for the container by checking the roles and permissions granted to the client account and determining whether the access control policy set for the container is satisfied.

[0049] In addition, the container security module described above performs an analysis on a container image requested for distribution from a client account, verifies the source of the container image, etc., thereby verifying whether it is a safe container image, thereby performing a function to ensure that only safe container images are distributed to the client terminal (30).

[0050] To this end, the container security module analyzes the source code of the container image using an IaC (Infrastructure of code) scanning tool to verify whether the container image requested for deployment is a trustworthy container image.

[0051] That is, in the present invention, by declaring infrastructures containerized by virtualization in the form of code and applying the code so that only the corresponding infrastructure is deployed, the present invention can provide the effect of reducing costs by eliminating the need for manual infrastructure management by expressing and executing the infrastructure as code, the effect of accelerating execution speed by automating infrastructure configuration, management, and deployment, the effect of eliminating risks related to human errors during manual configuration, and the effect of increasing management efficiency by making it easy for anyone to read and check code documents written in a standardized format and rules so that when a problem occurs, it is easy to find out in which part the problem occurred.

[0052] In addition, the access control policy server described above is designed to manage predefined access control policies, and to periodically monitor whether new policies are created, modified policies exist, or deleted policies exist, and update them, thereby promptly reflecting the latest policies.

[0053] Returning to Fig. 1 and continuing the explanation, in the present invention, after step S30 is performed, when there is an execution request for a specific container from a client account connected to the cloud (20) API, a distribution step (S40) is performed to check whether the requested container image exists in the Docker Hub (60), and then distribute the container image to the client terminal (30).

[0054] Specifically, in step S40, before distributing the container image to the client terminal (30), a process is performed to check whether the container image is a trustworthy container image using the aforementioned container security module, and it is desirable to enable a secure container image to be distributed to the client terminal (30).

[0055] In performing the aforementioned step S40, the present invention assumes that a container image exists in the Docker Hub (60). At this time, the workflow for creating the container image can be described with reference to the areas indicated by CI and CD in FIG. 2.

[0056] Specifically, when a project is in progress, application developers use the repository of GitHub to store the developed source code (code pull), and GitHub reviews the stored source code and communicates with Jenkins to enable the building of container images. Meanwhile, the container image built by Jenkins is transferred to Docker, an orchestration tool that manages applications composed of multiple containers, and is continuously integrated (CI, Continuous Integration).

[0057] Afterwards, Docker uploads the container image (Image Push) to Docker Hub (60), a cloud (20) service that stores Docker images, and the container image uploaded to Docker Hub (60) is continuously provided (CD, Continuous Deployment) to the client's production environment by linking with Kubernetes API, and is called when there is an execution request in the cloud (20) account to prepare for deployment.

[0058] Accordingly, based on the workflow described above, when step S40 is performed, if the container image requested for execution does not exist in the Docker Hub (60), the process of creating a container image for the container requested for execution may be performed first in the present invention, and the present invention is not limited thereto.

[0059] Meanwhile, the present invention has a feature in that an application developed by a developer is distributed as a container image. When distributing an application as a container image, a separate space is created without a hardware emulation step, so overhead is reduced, and it is small in size, lightweight, and has high mobility, enabling fast and efficient deployment of a large number of microservices and flexible expansion by service unit. In addition, since containers can be run in virtually any environment, such as Linux, Windows, Mac OS, virtual machines, bare metal, developer PCs, data centers, on-premise environments, and public clouds (20), development and distribution can be facilitated.

[0060] In addition, when a container is deployed as a container image to a client terminal (30) by performing the S40 step described above, and the container deployed to the client terminal (30) is executed, in the present invention, an execution control step (S50) can be performed to control the execution of the container by having a kernel (50) agent at the kernel (50) level to which an access control policy is applied monitor the system call of the container instance.

[0061] Referring to FIG. 5, the above-described S50 step can monitor all system calls for commands and file access executed by a client account for a container running in a client account, and when a system call including at least one of execution of a command and file access that violates an access control policy is detected as a result of the monitoring, execution control can be performed to reject the call of the system call that violates the access control policy.

[0062] In addition, in performing step S50, the kernel (50) mentioned in the present invention can create an isolated environment with an independent directory structure for each process authorized to the container by changing the path mounted in the root directory to a point corresponding to the authorized process through the pivot_root system call, as shown in 100 of FIG. 3, in order to block the execution of processes other than those authorized to the container by the client account (i.e., the user account).

[0063] For a more detailed explanation, referring to 110 in Fig. 4, a file system typically has a root directory ( / ). This root directory is a special location that signifies the top level of the file system, and all directories and files exist under the root directory.

[0064] At this time, the present invention uses the pivot_root command (or chroot command) described above to change the mount point to a point corresponding to an authorized process, thereby blocking work actions other than those of an authorized process.

[0065] That is, in 110 of FIG. 4, the actual root directory is the point indicated by p1, but by using the pivot_root command to set a fake root directory to the point (p2) corresponding to the authorized process, access to files located at a point higher than p2 is blocked from the client account, and in the present invention, by using virtualization technology to run the process in an isolated environment while the container shares the Linux kernel (50), even if the container is exposed to a problem such as hacking, it can provide the effect of not affecting the host operating system and greatly reducing the scale of damage caused by hacking.

[0066] Although the embodiments have been described with limited examples and drawings, those skilled in the art will appreciate that various modifications and variations can be made from the above description.

[0067] Meanwhile, referring to FIG. 6, FIG. 6 illustrates a configuration diagram of a distribution and execution control device (10) of a container image based on a security kernel (50) according to an embodiment of the present invention.

[0068] As illustrated in FIG. 6, the device (10) of the present invention preferably includes a resource data collection unit (11), an execution operation definition unit (12), a policy application unit (13), an image distribution unit (14), and an execution control unit (15).

[0069] At this time, it can be understood that the resource data collection unit (11) described above functions to continuously collect resource data of a container workload running on a cloud (20), and as a result, it can perform all of the functions performed by step S10 of the above-described FIG. 1.

[0070] That is, the resource data collection unit (11) described above in the device (10) of the present invention collects data of resources running on the cloud (20) in order to set policies such as file integrity, process integrity, and traffic control. By performing the function of the resource data collection unit (11), data that serves as the basis for an access control policy for distribution and execution of a container image can be collected.

[0071] Next, the above-described execution operation definition unit (12) performs a function of defining a list of executable files and processes within the container based on the SBOM (40). That is, the above-described execution operation definition unit (12) can be understood as being capable of performing all of the functions performed by step S20 of FIG. 1, and by performing the function of this execution operation definition unit (12), data that serves as the basis for an access control policy for safe distribution and execution of a container image is generated.

[0072] Of course, when performing the function of the above-described execution operation definition section (12), there may be intervention by a security manager in defining the list of executable files and processes within the container, and the present invention is not limited thereto.

[0073] In addition, the policy application unit (13) described below configures a whitelist-based access control policy in the container runtime based on the collected resource data and defined execution behavior, and performs the function of applying the configured access control policy to the kernel (50).

[0074] That is, the above-described policy application unit (13) can be understood as being capable of performing all of the functions performed by step S30 of FIG. 1, and in the present invention, by performing the function of this policy application unit (13), an access control policy is established in which all work actions other than those listed in the whitelist are listed in the blacklist, thereby exerting a strong protection effect on internal resources.

[0075] In addition, the above-described distribution unit (14) performs a function of checking whether the requested container image exists in the Docker Hub (60) when there is an execution request for a specific container from a client account connected to the cloud (20) API, and then distributing the container image to the client terminal (30).

[0076] At this time, the distribution unit (14) may perform an evaluation on whether the source of the container image is clear before distributing the container image to the client terminal (30) using the IaC tool, so that a container image confirmed to be safe may be distributed to the client terminal (30), and as a result, the distribution unit (14) included in the configuration of the device (10) of the present invention may be understood to be capable of performing all of the functions performed by step S40 of FIG. 1.

[0077] In addition, the above-described execution control unit (15) performs a function of controlling the execution of a container by having a kernel (50) agent at the kernel (50) level to which an access control policy is applied monitor the system call of the container instance when a container deployed to a client terminal (30) is executed.

[0078] That is, the above-described execution control unit (15) can be understood as being capable of performing all of the functions performed by step S50 of FIG. 1, and in the present invention, by performing the function of the execution control unit (15), only authorized tasks and processes are executed for the deployed container, thereby providing an effect of fundamentally blocking the occurrence of threatening actions.

[0079] Although the embodiments have been described with limited examples and drawings, those skilled in the art will appreciate that various modifications and variations can be made from the above description.

[0080] On the other hand, referring to FIG. 7, FIG. 7 illustrates an example of the internal configuration of a computing device according to an embodiment of the present invention, and in the following description, descriptions of unnecessary embodiments that overlap with the descriptions of FIGS. 1 to 6 described above will be omitted.

[0081] As illustrated in FIG. 7, the computing device (10000) may include at least one processor (11100), memory (11200), peripheral interface (11300), input / output subsystem (I / O subsystem) (11400), power circuit (11500), and communication circuit (11600). In this case, the computing device (10000) may correspond to a user terminal (A) connected to a tactile interface device or the computing device (B) described above.

[0082] The memory (11200) may include, for example, high-speed random access memory, a magnetic disk, SRAM, DRAM, ROM, flash memory, or non-volatile memory. The memory (11200) may include software modules, instruction sets, or other various data required for the operation of the computing device (10000).

[0083] At this time, access to the memory (11200) from other components such as the processor (11100) or peripheral interface (11300) may be controlled by the processor (11100).

[0084] The peripheral interface (11300) may couple input and / or output peripherals of the computing device (10000) to the processor (11100) and memory (11200). The processor (11100) may execute software modules or instruction sets stored in the memory (11200) to perform various functions for the computing device (10000) and process data.

[0085] The input / output subsystem (11400) can couple various input / output peripheral devices to the peripheral interface (11300). For example, the input / output subsystem (11400) can include a controller for coupling peripheral devices such as a monitor, a keyboard, a mouse, a printer, or, as needed, a touchscreen or sensor to the peripheral interface (11300). In another aspect, the input / output peripheral devices can be coupled to the peripheral interface (11300) without going through the input / output subsystem (11400).

[0086] The power circuit (11500) may supply power to all or part of the components of the terminal. For example, the power circuit (11500) may include a power management system, one or more power sources such as a battery or alternating current (AC), a charging system, a power failure detection circuit, a power converter or inverter, a power status indicator, or any other components for power generation, management, and distribution.

[0087] The communication circuit (11600) may enable communication with another computing device using at least one external port.

[0088] Alternatively, as described above, the communication circuit (11600) may enable communication with other computing devices by transmitting and receiving RF signals, also known as electromagnetic signals, including RF circuits, as needed.

[0089] The embodiment of FIG. 7 is only an example of a computing device (10000), and the computing device (11000) may have some of the components illustrated in FIG. 7 omitted, may further include additional components not illustrated in FIG. 7, or may have a configuration or arrangement that combines two or more components. For example, a computing device for a communication terminal in a mobile environment may further include a touchscreen or a sensor, in addition to the components illustrated in FIG. 7, and may include a circuit for RF communication of various communication methods (WiFi, 3G, LTE, Bluetooth, NFC, Zigbee, etc.) in the communication circuit (1160). Components that can be included in the computing device (10000) may be implemented as hardware including one or more signal processing or application-specific integrated circuits, software, or a combination of both hardware and software.

[0090] Methods according to embodiments of the present invention may be implemented in the form of program instructions that can be executed through various computing devices and recorded on a computer-readable medium. In particular, the program according to the present embodiment may be configured as a PC-based program or an application exclusively for mobile terminals. An application to which the present invention is applied may be installed on a user terminal through a file provided by a file distribution system. For example, the file distribution system may include a file transmission unit (not shown) that transmits the file at the request of the user terminal.

[0091] The devices described above may be implemented as hardware components, software components, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments may be implemented using one or more general-purpose computers or special-purpose computers, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing instructions and responding. The processing device may execute an operating system (OS) and one or more software applications running on the operating system.

[0092] Additionally, the processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, the processing device is sometimes described as being used alone; however, those skilled in the art will appreciate that the processing device may include multiple processing elements and / or multiple types of processing elements. For example, the processing device may include multiple processors, or a processor and a controller. Other processing configurations, such as parallel processors, are also possible.

[0093] Software may include computer programs, codes, instructions, or a combination of one or more of these, which may configure a processing device to perform a desired operation or may, independently or collectively, command the processing device. The software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium, or device for interpretation by the processing device or for providing instructions or data to the processing device. The software may also be distributed across network-connected computing devices and stored or executed in a distributed manner. The software and data may be stored on one or more computer-readable recording media.

[0094] The method according to the embodiment may be implemented in the form of program commands that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program commands, data files, data structures, etc., alone or in combination. The program commands recorded on the medium may be those specially designed and configured for the embodiment or may be those known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and hardware devices specially configured to store and execute program commands such as ROMs, RAMs, and flash memories.

[0095] Examples of program instructions include not only machine language code, such as that generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter, etc. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

[0096] Although the embodiments have been described with limited examples and drawings, those skilled in the art will recognize that various modifications and variations can be made based on the above teachings. For example, appropriate results can be achieved even if the described techniques are performed in a different order than described, and / or components of the described systems, structures, devices, circuits, etc. are combined or combined in a different manner than described, or are replaced or substituted with other components or equivalents. Therefore, other implementations, other embodiments, and equivalents of the claims also fall within the scope of the following claims.

Claims

1. A method for controlling the distribution and execution of a container image based on a security kernel implemented as a computing device including one or more processors and one or more memories storing instructions executable by the processors, Resource data collection step that collects resource data of container workloads running on the cloud; An execution behavior definition step that defines the list of executable files and processes within a container based on the SBOM (Software bill of materials); A policy application step that configures a whitelist-based access control policy at container runtime based on collected resource data and defined execution behavior, and applies the configured access control policy to the kernel; When there is an execution request for a specific container from a client account connected to the cloud API, a deployment step for checking whether the requested container image exists in Docker Hub and then deploying the container image to the client terminal; and, A method for distributing and controlling execution of a container image based on a secure kernel, characterized in that it includes an execution control step in which, when a container deployed on the client terminal is executed, a kernel agent at the kernel level to which the access control policy is applied monitors the system call of the container instance, thereby controlling the execution of the container.

2. In paragraph 1, The security area of ​​the above container runtime includes: A method for distributing and controlling execution of a container image based on a security kernel, characterized in that the execution control tool of the container comprises a kernel agent located at the kernel level, a webhook server located at the application level, a container security module, and an access control policy server, and the execution control tool of the container is an operator deployed in a Kubernetes cluster.

3. In paragraph 2, The above distribution steps are: A method for controlling the distribution and execution of a container image based on a security kernel, characterized in that, prior to distributing the container image to the client terminal, the container security module is used to analyze the source code of the container image extracted from the Docker Hub using an IaC (Infrastructure of code) scan tool, thereby confirming whether the container image is a trustworthy container image.

4. In paragraph 2, The above execution action definition step is: Define execution behavior by creating a Custom Resource Definition (CRD) that differentiates the scope of the list of executable files and processes based on the roles and permissions granted to the client account. A method for controlling the distribution and execution of a container image based on a security kernel, characterized in that the webhook server evaluates whether the execution operation defined in the CRD is being performed in the client account.

5. In paragraph 1, The above execution control step is, For containers running under the client account, monitor system calls for commands and file access executed by the client account. A method for controlling the distribution and execution of a container image based on a security kernel, characterized in that when the execution of a command that violates the access control policy and a system call related to file access are detected as a result of monitoring, the calling of the system call is denied.

6. In paragraph 1, The above kernel is, A method for controlling the distribution and execution of a container image based on a security kernel, characterized in that the method creates an isolated environment with an independent directory structure for each process authorized to the container by changing a path mounted in the root directory to a point corresponding to an authorized process through the pivot_root system call in order to block execution of processes other than those authorized for the container.

7. A device for controlling the deployment and execution of a container image based on a security kernel implemented as a computing device including one or more processors and one or more memories storing instructions executable by the processors, Resource data collection unit that collects resource data of container workloads running on the cloud; The execution behavior definition section defines the list of executable files and processes within the container based on the SBOM (Software bill of materials); A policy application unit that configures a whitelist-based access control policy at container runtime based on collected resource data and defined execution behavior, and applies the configured access control policy to the kernel; When there is an execution request for a specific container from a client account connected to the cloud API, a container image distribution unit that checks whether the requested container image exists in Docker Hub and then distributes the container image to the client terminal; and, A container image distribution and execution control device based on a secure kernel, characterized in that it includes an execution control unit that controls the execution of the container by having a kernel agent at the kernel level to which the access control policy is applied monitor the system call of the container instance when the container deployed on the client terminal is executed.

8. In a computer-readable recording medium, The above computer-readable recording medium stores instructions that cause a computing device to perform the following steps, the steps being: Resource data collection step that collects resource data of container workloads running on the cloud; An execution behavior definition step that defines the list of executable files and processes within a container based on the SBOM (Software bill of materials); A policy application step that configures a whitelist-based access control policy at container runtime based on collected resource data and defined execution behavior, and applies the configured access control policy to the kernel; When there is an execution request for a specific container from a client account connected to the cloud API, a container image distribution step for checking whether the requested container image exists in Docker Hub and then distributing the container image to the client terminal; and, A computer-readable recording medium characterized by including an execution control step in which, when a container deployed on the client terminal is executed, a kernel agent at the kernel level to which the access control policy is applied monitors the system call of the container instance, thereby controlling the execution of the container.

Images