Container-based safety management method and device, equipment and medium

Abstract

The invention provides a container-based security management method and device, equipment and a medium, and the method comprises the steps: receiving a resource application request of a client, and obtaining at least two target components corresponding to the resource application request and component mirror images of the target components; determining a topological structure between the at least two target components, and configuring a security rule of each target component; arranging and deploying the component mirror image according to the topological structure and the security rule, and forming a target application in the container cluster; and regularly performing health examination on the target application to determine the health state of the target application in the container cluster. According to the method, through deep combination of software-defined security and containerization technologies, the access authority to resources can be precisely limited, so that potential attack surfaces are remarkably reduced, and unauthorized access and data leakage are effectively prevented.

Description

Technical Field

[0001] The present invention relates to the field of computer and container technology, and in particular to a container-based security management method, device, equipment and medium. Background Art

[0002] As cyberattacks become more complex and diverse, the security threats facing application software systems are also in a continuous and dynamic evolution. Traditional static security strategies and protection mechanisms can no longer meet the security needs of modern software systems, especially as microservice architectures mature and large software systems are broken down into many small and independent microservices. Traditional security strategies and protection mechanisms pose risks of unauthorized access and data leakage.

[0003] At present, container orchestration technologies such as Kubernetes and Docker are becoming more and more mature, and containerized applications are also widely deployed. However, the security risks that come with it are also becoming increasingly prominent. Software-Defined Security (SDS) can optimize and expand container orchestration technology based on the characteristics and security requirements of microservice architecture and combined with containerized deployment. In view of the risks of unauthorized access and data leakage exposed by the above traditional security strategies and protection mechanisms, an effective container-based security management method is urgently needed to solve the above problems. Summary of the invention

[0004] In view of the above problems, the present invention is proposed to provide a container-based security management method, device, equipment and medium that overcome the above problems or at least partially solve the above problems.

[0005] To achieve the above objectives and other related objectives, the present invention provides a container-based security management method, which is applied to a software-defined security system. The method includes:

[0006] Receive a resource application request from a client, and obtain at least two target components and their component images corresponding to the resource application request;

[0007] Determine the topology between the at least two target components, and configure security rules for each target component; wherein the security rules are operable security measures formulated based on identifying specific abnormal behaviors of the at least one target component;

[0008] According to the topology and the security rules, the component images are orchestrated and deployed, and a target application is formed in the container cluster;

[0009] Perform a health check on the target application at regular intervals to determine a health status of the target application in the container cluster.

[0010] Optionally, the obtaining at least two target components and their component images corresponding to the resource application request includes:

[0011] Parsing the resource application request to obtain component deployment parameters of the resource application request; wherein the component deployment parameters are the type and parameters of the security component required by the resource application request;

[0012] According to the component deployment parameters, at least two target components corresponding to the resource application request are screened out from a set of candidate security components, and component images corresponding to the respective target components are acquired from an image repository.

[0013] Optionally, determining the topological structure between the at least two target components includes:

[0014] The topology structure between the at least two target components is determined according to the component type, traffic orientation and defense characteristics of the component in the resource application request.

[0015] Optionally, configuring security rules for each target component includes:

[0016] Determine a specific abnormal behavior pre-configured for each of the target components; wherein the specific abnormal behavior is a behavior that does not conform to a normal operating mode and is identified by the at least one target component when monitoring and protecting the system;

[0017] According to each of the target components and its specific abnormal behavior, corresponding security rules are configured for each of the target components.

[0018] Optionally, orchestrating and deploying the component images according to the topology structure and the security rules, and forming a target application in the container cluster, includes:

[0019] According to the topology structure and the security rules, the component image of each target component is configured and processed, and a deployment file is generated for each target component in the form of a topology diagram, and the deployment file is submitted to the container cluster to build a container application of each target component;

[0020] The container application is deployed to a suitable node in the container cluster using a pre-made scheduling strategy, and when the container application is orchestrated and deployed, health checks and security rules are configured for the container, and a target application isolated according to a namespace is formed through the container cluster.

[0021] Optionally, the periodically performing a health check on the target application to determine a health status of the target application in the container cluster includes:

[0022] Regularly check whether the configuration and operation of each target component of the target application work as expected;

[0023] When the target component detects a known security threatening behavior, the known security threatening behavior is processed using the security rule of the target component.

[0024] Optionally, after the step of regularly checking whether the configuration and operation of each target component in the target application work as expected, the step further includes:

[0025] When the target component detects an unknown security threatening behavior, the target application is re-arranged and deployed according to the unknown security threatening behavior.

[0026] In a second aspect, the present invention further provides a container-based security management device, which is applied to a software-defined security system, and the device includes:

[0027] An acquisition module, used to receive a resource application request from a client, and acquire at least two target components and their component images corresponding to the resource application request;

[0028] A determination module, used to determine the topology between the at least two target components, and configure security rules for each target component; wherein the security rules are operable security measures formulated based on identifying specific abnormal behaviors of the at least one target component;

[0029] A deployment module, configured to orchestrate and deploy the component images according to the topology structure and the security rules, and form a target application in a container cluster;

[0030] The checking module is used to periodically perform a health check on the target application to determine the health status of the target application in the container cluster.

[0031] In a third aspect, the present invention provides an electronic device, comprising: a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory, so that the electronic device performs the steps of the container-based security management method as described above.

[0032] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the steps of the container-based security management method as described above.

[0033] The above one or more technical solutions provided by the present invention may have the following advantages or at least achieve the following technical effects:

[0034] The container-based security management method, device, equipment and medium of the present invention can accurately limit access rights to resources through the deep integration of software-defined security and containerization technology, thereby significantly reducing the potential attack surface and effectively preventing unauthorized access and data leakage risks. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 Shown is a schematic diagram of the structure of a software-defined security system in one embodiment of the present invention;

[0036] Figure 2 It is a schematic diagram showing a flow chart of a container-based security management method according to an embodiment of the present invention;

[0037] Figure 3 It is a schematic diagram showing the functional modules of a container-based security management device according to an embodiment of the present invention;

[0038] Figure 4 Shown is a schematic diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0039] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0040] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0041] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it is obvious to those skilled in the art that the embodiments of the present invention can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present invention difficult to understand.

[0042] The terms "first", "second", etc. in the specification and claims of the disclosed embodiments and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchanged where appropriate, so that the embodiments of the disclosed embodiments described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions.

[0043] Unless otherwise stated, the term "plurality" means two or more.

[0044] In the embodiment of the present disclosure, the character " / " indicates that the preceding and following objects are in an "or" relationship. For example, A / B indicates: A or B.

[0045] The term "and / or" is a description of the association relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or, A and B.

[0046] The technical solutions in the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0047] See also Figure 1 , Figure 1 A schematic diagram of the implementation environment of the container-based security management method provided by the present invention (i.e., a structural diagram of a software-defined security system) is provided to implement security functions through software-defined security; the software-defined security system may include an application centralized management platform and a container management center.

[0048] Among them, the application centralized management platform can include a WEB entry interface, application process management, tenant resource management, and security management functions.

[0049] Application process management may include process approval and application management; process approval is used to conduct approval process for user's application resource application; application management is used to perform operations on application resources successfully applied for through process approval, including but not limited to pausing, resuming, stopping, deleting, deploying, enabling, disabling and other operations of the application.

[0050] Tenant resource management can include security component management, alarm status, tenant management, and audit logs.

[0051] Among them, security component management is used to manage security components uploaded by users, including but not limited to operations such as uploading, downloading, deleting, enabling and disabling.

[0052] Alarm situation is used to compile statistics on various security incidents that have occurred and display the latest alarm information.

[0053] Tenant management is used to effectively manage and control users, resources, permissions, etc. of different tenants to ensure data isolation between tenants.

[0054] Audit logs are used to record detailed information about various activities and events for later troubleshooting.

[0055] Security management functions can include containerized security component orchestration, alarm feedback management, and security rule management.

[0056] Among them, containerized security component orchestration is used to quickly schedule and deploy on the container platform based on the topological structure diagram of the security components.

[0057] Alarm feedback management is used to generate alarm information when the security component detects abnormal behavior or potential security threats during the operation of the application container, and promptly feedback the alarm information to the user; and according to the type of alarm, you can use the preset security rules to respond quickly.

[0058] Security rule management is used to manage rules for handling abnormal behaviors of security components.

[0059] The container management center can include a security component pool, container resource management, and third-party interface management.

[0060] Among them, the security component pool is a collection of security components, which includes customized container images; these container images are key components for building a secure network architecture in the field of network security; the security component pool can include but is not limited to: firewalls, intrusion detection, intrusion prevention, security gateways, traffic mirroring, traffic auditing, encryption and decryption components and other common security components.

[0061] Container resource management can include network management, storage management, and computing management.

[0062] Among them, network management is used to manage the communication and connection between containers and between containers and external networks. This system uses the network plug-in Calico for integrated management, which can realize network access control and traffic control.

[0063] Storage management is used to manage the storage resources used by containers. This system uses the highly available and high-performance distributed storage system CubeFS to integrate with the container cluster through the CSI plug-in to achieve storage management; the container cluster mainly manages storage resources through PV and PVC objects.

[0064] Computing management is used when computing resources are needed for special applications. Computing resource-related plug-ins can be used to bind resources to containers and allocate computing resources to containers for use.

[0065] As an example, deploy an application centralized management platform on a server. This platform covers functional modules such as WEB portal, application process management, tenant resource management, and security management. Deploy a container image repository on another server, such as the Harbor repository, which is mainly responsible for storing images of the security component pool. Use three servers to build a distributed storage system (CubeFS) with high availability and high performance to provide storage services for the container cluster. Also use three servers to build a highly available Kubernetes cluster, which includes a network management plug-in (Calico) and a storage management plug-in (CSI); if there is a demand for computing resources, further deploy the corresponding computing resource plug-in. At the same time, with the matching component agent, a complete software environment architecture is jointly built.

[0066] See also Figure 2 An embodiment of the present invention provides a container-based security management method, which is applied to a software-defined security system. The method may include the following steps S10 to S40:

[0067] Step S10: receiving a resource application request from a client, and obtaining at least two target components and component images thereof corresponding to the resource application request.

[0068] The resource application request may be a request for security components applied for by the client and a target application to be protected; it includes but is not limited to the required security components, performance requirements of the target application, and expected use.

[0069] Security components can be encapsulated data and methods to provide specific application services, and target applications can be built based on at least one security component. Security components can include, but are not limited to: firewalls, intrusion detection, intrusion prevention, security gateways, traffic mirroring, traffic auditing, and encryption and decryption components.

[0070] The target application may be an application to be created and deployed in response to a resource application request; it may be composed of at least one security component.

[0071] The target component can be a security component that is selected from a security component pool of a container management center (of a software-defined security system) in response to a resource application request to construct at least one security component for building a target application.

[0072] A component image can package a target component into a container image for deployment and use in a containerized environment. It contains all the dependencies and configurations required to run the target component, making it easier and more consistent to deploy and manage the target component in a container cluster.

[0073] In a specific implementation, it is possible to directly receive a resource application request created by a developer in the application process management of the application centralized management platform (software-defined security system), and then determine at least two target components (such as the type and parameters of the target components) required to create the target application based on the target application that needs to be protected by the resource application request; and after determining at least two target components, it is possible to receive the component images corresponding to the target components uploaded by the developer.

[0074] Step S20, determining the topological structure between the at least two target components, and configuring security rules for each target component.

[0075] The topological structure may include the communication and dependency relationship between various target components in the target application; it may include one or more of a series structure, a parallel structure, a hierarchical structure, and a distributed structure.

[0076] As an example, target components (such as firewalls, intrusion detection, Web protection, and service applications) are connected in sequence, and data or traffic passes through each target component in sequence. In a network security protection, traffic first passes through the firewall for access control, then enters the intrusion detection system for suspicious behavior monitoring; the traffic then reaches the Web protection for inspection and filtering; finally, the traffic that has passed all the previous security checks reaches the service application, which processes legitimate business requests and returns responses to users.

[0077] As another example, the target components are distributed in different layers, each with its own specific security functions and responsibilities. In a network architecture, the outermost layer may be a border firewall, the middle layer may be an access control and monitoring component for the internal network, and the innermost layer may be a host security protection component.

[0078] Security rules can be operational security measures developed based on identifying specific abnormal behaviors of at least one target component; different types of security components can be configured with corresponding security rules.

[0079] As an example, the authentication component is used to verify the user's identity and ensure that the user is authorized. Common authentication methods include username and password. The configured security rules can be to implement strong password policies, regularly update authentication credentials, and limit the number of login attempts to prevent brute force attacks.

[0080] As another example, the access control component is used to control access rights to system resources. Based on the user's identity and role, the access control component can determine which resources the user can access and which operations they can perform. The configured security rules can be to implement role-based access control to ensure the principle of least privilege, that is, users have the permissions required to complete their tasks.

[0081] In a specific implementation, the topological structure between at least two target components can be determined based on the types and parameters of at least two target components, and then the types and parameters of the components can be used; and corresponding security rules can be configured for each target component based on each target component and its specific abnormal behavior.

[0082] Step S30: orchestrate and deploy the component images according to the topology structure and the security rules, and form a target application in a container cluster.

[0083] In a specific implementation, a deployment file can be generated for each target component in the form of a topology diagram according to the topology structure between at least two target components, and the deployment file can be submitted to a container cluster (such as a Kubernetes cluster); then, according to the deployment file, the container cluster can be used to obtain the corresponding component image, and ensure that the component image is deployed in the order of the topology diagram to generate the corresponding container application, and handle the dependencies between the target components; then, a health check can be configured for the container application to ensure that the container application can self-detect and report its health status at runtime, and according to the security rules of each target component, the corresponding network policy, access control, log collection, etc. can be configured to ensure that the security rules are correctly implemented in the container cluster; then, a namespace can be created in the container cluster to isolate different application environments, and the container application can be deployed to the corresponding namespace to achieve logical isolation and resource management; finally, these container applications can be integrated in the container cluster to form a target application isolated according to the namespace.

[0084] Step S40: regularly perform a health check on the target application to determine a health status of the target application in the container cluster.

[0085] Among them, health check is used to determine the health status of the target application being monitored in the container cluster to verify whether each target component in the target application works as expected.

[0086] As an example, when a running target component detects suspicious activities, intrusions, Trojan viruses and other security threats, the target component will promptly send an alarm feedback to the client for the above-mentioned security threats; wherein the above-mentioned security threats may be known security threats or unknown security threats; and then, by analyzing these security threats, it is possible to verify whether the target application meets expectations (i.e., verify whether the security components requested in the resource application request and the applications to be protected meet expectations).

[0087] The known threatening security behaviors may be security threats that have been identified and classified; the known threatening security behaviors may be processed by using security rules configured by corresponding target components.

[0088] Unknown threat security behaviors may be security threats that have not yet been fully identified or understood; for these unknown threat security behaviors, the corresponding security rules have not yet been configured for each target component; that is, each target component in the target application cannot handle these unknown threat security behaviors, and the target application needs to be re-arranged and deployed or at least one target component needs to be upgraded to enhance the target application's detection and defense capabilities against unknown threat security behaviors.

[0089] In a specific implementation, after each target component in the target application is successfully deployed, a health check of the target application in the container cluster can be initiated to determine the connectivity between the target components in the target application (e.g., checking the status information of all nodes, monitoring the usage of resources such as CPU and memory of the nodes, network connectivity between nodes, etc.) to verify whether the target components of the target application in the container cluster can communicate and collaborate normally.

[0090] Furthermore, in one embodiment, step S10 may include the following sub-steps S101 to S102:

[0091] Sub-step S101, parsing the resource application request to obtain component deployment parameters of the resource application request; wherein the component deployment parameters are the type and parameters of the security component required by the resource application request;

[0092] Sub-step S102, based on the component deployment parameters, at least two target components corresponding to the resource application request are screened out from a set of candidate security components, and component images of the target components are obtained from an image repository.

[0093] The component deployment parameters may be the type and parameters of the security component required by the resource application request, such as the environment in which the target application is deployed (such as a Kubernetes cluster), the type and configuration of the security component, and other parameters.

[0094] In a specific implementation, when a resource application request is received from a client, the resource application request can be parsed to obtain corresponding component deployment parameters; then, based on the component deployment parameters, at least two target components corresponding to the resource application request can be screened out from a set of candidate security components in a security component pool; then, component images of each target component can be obtained from an image repository; thereby, at least two target components and component images of the target application that need to be protected can be determined for the resource application request submitted by the client.

[0095] Further, in one embodiment, step S20 may include the following sub-step S201:

[0096] Sub-step S201, determining the topological structure between the at least two target components according to the component type, traffic orientation and component defense characteristics of the resource application request.

[0097] Among them, traffic steering can be expressed as the flow direction of traffic between various target components.

[0098] Defense characteristics can be expressed as security threats that each target component effectively defends against.

[0099] In a specific implementation, the component type, traffic orientation and component defense characteristics determined by the above resource application request can be used to determine the topological structure between at least two target components (for example, a topological map between each target component can be constructed based on the traffic relationship).

[0100] Furthermore, in one embodiment, step S20 may further include sub-steps S202 to S203:

[0101] Sub-step S202, determining a specific abnormal behavior pre-configured for each target component; wherein the specific abnormal behavior is a behavior that does not conform to a normal operation mode identified by the at least one target component when monitoring and protecting the system;

[0102] Sub-step S203, configuring corresponding security rules for each target component according to each target component and its specific abnormal behavior.

[0103] Among them, specific abnormal behavior can be a behavior that does not conform to the normal operation mode and is identified by a target component when monitoring and protecting the system, such as suspicious activities, intrusion behaviors, and other security threatening behaviors.

[0104] In a specific implementation, the specific abnormal behaviors pre-configured for each target component can be determined; then, corresponding security rules can be configured for each target component based on each target component and its specific abnormal behavior; so that when at least one target component in operation detects the above-mentioned specific abnormal behavior, it can promptly feedback alarm information to the client and use security rules to quickly handle these specific abnormal behaviors.

[0105] In this embodiment, through the deep integration of software-defined security and containerization technology, access rights to resources can be accurately restricted, thereby significantly reducing the potential attack surface and effectively preventing unauthorized access and data leakage risks.

[0106] Based on the above embodiments, a second embodiment of the container-based security management method of the present invention is proposed. In this embodiment, step S30 may include the following sub-steps S301 to S302:

[0107] Sub-step S301, configures and processes the component image according to the topology structure and the security rules, generates deployment files for each target component in the form of a topology diagram, and submits the deployment files to the container cluster to build container applications for each target component.

[0108] The deployment file may be generally written in YAML format, and defines how to deploy and manage component images of various target components; it may include resource requirements, node available resources, and various scheduling strategies.

[0109] In the specific implementation, the component image of each target component is first pushed to the container cluster managed by container resources (such as the Kubernetes cluster); according to the topological structure between each target component, a deployment file can be generated for each target component in the form of a topological diagram and submitted to the container cluster; then, according to the deployment file, the corresponding component image can be configured and processed in the Kubernets cluster to build the container application of each target component.

[0110] Sub-step S302, using a pre-made scheduling strategy, deploys the container application to a suitable node in the container cluster, and when the container application is orchestrated and deployed, configures health checks and security rules for the container application, and forms a target application isolated according to the namespace through the container cluster.

[0111] Among them, the prefabricated scheduling strategy can be a pre-made scheduling strategy based on the resource requirements of the container application and matched with the available resources of the nodes in the container cluster to determine the scheduling strategy that is most suitable for the data node running the container application.

[0112] In the specific implementation, the preset scheduling strategy can be used to match the resource requirements of the container application and the available resources of the nodes in the container cluster to determine the most suitable node for running the container application. Then the container application can be deployed to the appropriate node in the container cluster, that is, the container cluster matches and binds each target component with the data node in the container cluster according to the required storage resources and computing resources; after binding, the container application of each target component can use the storage resources of the data node in these container clusters. When the container application is orchestrated and deployed, the corresponding health check and security rules are configured for each target component container application to ensure the security of the container application; then a namespace is created in the container application to isolate different application environments; and the container application is deployed to the corresponding namespace to achieve logical isolation and resource management, and then the various container applications are integrated to form a target application isolated according to the namespace. Among them, the namespace is a logical isolation mechanism in Kubernetes, which can divide the resources in the container cluster into different groups or projects, thereby realizing the isolation management of resources.

[0113] In this embodiment, resources of each target component are matched and bound through a container cluster, so that the container application corresponding to each target component can be dynamically scheduled to a data node with appropriate resources in the container cluster; at the same time, by configuring health checks and security rules, network isolation and access control can be achieved, thereby ensuring the stable operation and data persistence of the target application in the container cluster, and improving the stability and security of the target application.

[0114] Based on the above embodiments, a third embodiment of the container-based security management method of the present invention is proposed. In this embodiment, step S40 may include the following sub-steps S401 to S402:

[0115] Sub-step S401, regularly checking whether the configuration and operation of each target component in the target application work as expected.

[0116] In a specific implementation, after all target components of a target application are successfully deployed, a health check of the target application can be initiated to check whether the configuration and operation of each target component in the target application work as expected, so as to ensure the connectivity between the target components.

[0117] Sub-step S402, when the target component detects a known security threat behavior, the known security threat behavior is processed using the security rule of the target component.

[0118] In a specific implementation, when at least one running target component detects known security threats such as suspicious activities, intrusion behaviors, Trojan viruses, etc., the target component can promptly alarm and feedback the above-mentioned known security threats to the client, and respond quickly according to the security rules configured by at least one target component to handle the above-mentioned known security threats.

[0119] Furthermore, in one embodiment, after sub-step S401, the method further includes the following sub-step S403:

[0120] Sub-step S403, when the target component detects an unknown security threat behavior, re-arrange and deploy the target application according to the unknown security threat behavior.

[0121] In a specific implementation, when at least one running target component detects unknown threatening security behaviors such as suspicious activities, intrusion behaviors, Trojan viruses, etc., the target component can promptly alarm and feedback the above unknown threatening security behaviors to the client, and then update the component deployment parameters of the target application according to the above unknown threatening security behaviors (such as updating the type and parameters of at least one new target component of the target application, determining the topology structure and security rules of the new target component), and then use the software-defined security system to re-arrange and deploy the target application, such as re-obtaining the component image of at least one new target component, and quickly orchestrating and deploying it.

[0122] In this embodiment, in the software-defined security system, after the target application is successfully deployed, by regularly performing health checks on the target application in the container cluster, its health status can be effectively monitored and managed, and timely measures can be taken to ensure the stability and reliability of the target application.

[0123] Based on the same inventive concept, the fourth embodiment of the present invention also provides a container-based security management device corresponding to the container-based security management method of the previous embodiment. Since the principle of solving the problem by the device in the fourth embodiment of the present invention is similar to the container-based security management method of the previous embodiment of the present invention, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated. Figure 3 The container-based security management device of the present invention may include:

[0124] The acquisition module 10 is used to receive a resource application request from a client and acquire at least two target components and their component images corresponding to the resource application request;

[0125] A determination module 20, configured to determine the topology between the at least two target components, and configure security rules for each target component; wherein the security rules are operable security measures formulated based on identifying specific abnormal behaviors of the at least one target component;

[0126] A deployment module 30, configured to orchestrate and deploy the component images according to the topology structure and the security rules, and form a target application in a container cluster;

[0127] The checking module 40 is used to periodically perform a health check on the target application to determine the health status of the target application in the container cluster.

[0128] In addition, the present invention also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned container-based security management method is implemented.

[0129] Figure 4 is a schematic block diagram of an electronic device provided in an embodiment of the present application. Figure 4 As shown, the electronic device includes: at least one processor 401, a memory 402, at least one network interface 403 and a user interface 405. The various components in the electronic device are coupled together through a bus system 404. It can be understood that the bus system 404 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 404 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, Figure 4 In the specification, various buses are labeled as bus systems.

[0130] The user interface 405 may include a display, a keyboard, a mouse, a trackball, a click gun, keys, buttons, a touch pad or a touch screen.

[0131] It is understood that the memory 402 can be a volatile memory or a non-volatile memory, and can also include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), synchronous static random access memory (SSRAM). The memory described in the embodiments of the present invention is intended to include but is not limited to these and any other suitable categories of memory.

[0132] The memory 402 in the embodiment of the present invention is used to store various categories of data to support the operation of the electronic device 400. Examples of these data include: any executable program for operating on the electronic device 400, such as an operating system 4021 and an application 4022; the operating system 4021 includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks. The application 4022 may include various applications, such as a media player (Media Player), a browser (Browser), etc., for implementing various application services. The container-based security management method provided by the embodiment of the present invention may be included in the application 4022.

[0133] The method disclosed in the above embodiment of the present invention can be applied to the processor 401, or implemented by the processor 401. The processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 401 or the instruction in the form of software. The above processor 401 may be a general processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The processor 401 can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present invention. The general processor 401 can be a microprocessor or any conventional processor, etc. In combination with the steps of the container-based security management method provided in the embodiment of the present invention, it can be directly embodied as a hardware decoding processor to execute, or it can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium, which is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0134] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application specific integrated circuits (ASIC), DSP, programmable logic device (PLD), complex programmable logic device (CPLD) to execute the aforementioned method.

[0135] In summary, the present invention can accurately limit access rights to resources through the deep combination of software-defined security and containerization technology, thereby significantly reducing the potential attack surface and effectively preventing unauthorized access and data leakage risks.

[0136] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by a person of ordinary skill in the art without departing from the spirit and technical concept disclosed by the present invention shall still be covered by the claims of the present invention.

Claims

1. A container-based security management method, characterized in that: Applied to a software-defined security system, the method comprises: Receive a resource application request from a client, and obtain at least two target components and their component images corresponding to the resource application request; Determine the topology between the at least two target components, and configure security rules for each target component; wherein the security rules are operational security measures formulated based on identifying specific abnormal behaviors of each target component; According to the topology and the security rules, the component images are orchestrated and deployed, and a target application is formed in a container cluster; Perform a health check on the target application at regular intervals to determine a health status of the target application in the container cluster.

2. The method according to claim 1, characterized in that: The obtaining of at least two target components and their component images corresponding to the resource application request includes: Parsing the resource application request to obtain component deployment parameters of the resource application request; wherein the component deployment parameters are the type and parameters of the security component required by the resource application request; According to the component deployment parameters, at least two target components corresponding to the resource application request are screened out from a set of candidate security components, and component images corresponding to the respective target components are acquired from an image repository.

3. The method according to claim 1 or 2, characterized in that: The determining of the topological structure between the at least two target components comprises: The topology structure between the at least two target components is determined according to the component type, traffic orientation and defense characteristics of the component in the resource application request.

4. The method according to claim 1, characterized in that: The configuration of security rules for each target component includes: Determine the specific abnormal behavior pre-configured for each of the target components; wherein the specific abnormal behavior is the behavior that does not conform to the normal operation mode identified by each of the target components when monitoring and protecting the system; According to each of the target components and its specific abnormal behavior, corresponding security rules are configured for each of the target components.

5. The method according to claim 1, characterized in that The orchestrating and deploying the component images according to the topology structure and the security rules, and forming a target application in a container cluster, includes: According to the topology structure and the security rules, the component image of each target component is configured and processed, and a deployment file is generated for each target component in the form of a topology diagram, and the deployment file is submitted to the container cluster to build a container application of each target component; The container application is deployed to a suitable node in the container cluster using a pre-made scheduling strategy, and when the container application is orchestrated and deployed, health checks and security rules are configured for the container application, and a target application isolated according to a namespace is formed through the container cluster.

6. The method according to claim 1, characterized in that The periodically performing a health check on the target application to determine a health status of the target application in the container cluster includes: Regularly check whether the configuration and operation of each target component in the target application work as expected; When the target component detects a known security threatening behavior, the known security threatening behavior is processed using the security rule of the target component.

7. The method according to claim 6, characterized in that After the step of regularly checking whether the configuration and operation of each target component in the target application work as expected, the method further includes: When the target component detects an unknown security threatening behavior, the target application is re-arranged and deployed according to the unknown security threatening behavior.

8. A container-based security management device, characterized in that: Applied to a software-defined security system, the device comprises: An acquisition module, used to receive a resource application request from a client, and acquire at least two target components and their component images corresponding to the resource application request; A determination module, used to determine the topology between the at least two target components, and configure security rules for each target component; wherein the security rules are operable security measures formulated based on identifying specific abnormal behaviors of the at least one target component; A deployment module, configured to orchestrate and deploy the component images according to the topology structure and the security rules, and form a target application in a container cluster; The checking module is used to periodically perform a health check on the target application to determine the health status of the target application in the container cluster.

9. An electronic device, characterized in that: The electronic device comprises: a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device performs the steps of the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program, and when the program is run, it is used to implement the steps of the method described in any one of claims 1 to 7.

Images