Secret-related cluster system and method for utilizing secret-related application security level based container technology

Abstract

The application provides a secret-related cluster system, which is suitable for a Kubernetes cluster system, and a container technology utilization method based on a secret-related application security level of the secret-related cluster system. The system comprises four parts of a management cluster, a business cluster, an image warehouse and a cluster network. The method adapts the security requirements of applying container technology and Kubernetes technology to the secret-related field, and proposes a method of secret-level-based cluster network separation, secret-level-based matching image scheduling, container image isolation and secure container application deployment, so that the existing security risks can be eliminated, and the stability of secret-related application container operation and the security of the operation environment are improved. The kernel, computing resources, storage and network of the application container carried by the secure container are isolated, so that direct access of the application to the host operating system is avoided.

Description

Technical Field

[0001] This invention relates to the field of cloud computing container technology, specifically to a cluster system involving sensitive information, applicable to Kubernetes cluster systems, and a method for utilizing container technology based on the confidentiality level of the sensitive application in the aforementioned cluster system. Background Technology

[0002] Container technology is a lightweight virtualization technology that creates a small, sandbox-like runtime environment by sharing the host operating system kernel. Each container has its own file system, CPU, memory, and process controls. Virtual machines achieve operating system-level isolation, while container technology achieves process-level isolation within the operating system. Containers are very lightweight and start up quickly, achieving sub-second startup times, while virtual machines are larger and take longer to start.

[0003] An image is a core concept in container technology. It's a lightweight, executable, standalone software package that encapsulates an application and all its software dependencies in binary data. An image is actually composed of layers of read-only file systems, each with a unique hash value. These layers are stacked together using a Union File System (UnionFS) and mounted under a single virtual file system containing all underlying files and directories. Multiple images can reuse file system layers with the same hash value. When performing write operations on the container, the image file layers are copied to the container layer for modification, ensuring the image layers remain unchanged.

[0004] Kubernetes is an open-source container orchestration and scheduling framework used to schedule and manage containerized workloads and services. It has become the de facto standard for container orchestration and scheduling in the cloud-native field and is widely used in the industry.

[0005] However, container and Kubernetes technologies pose security risks when applied to sensitive applications. Existing mainstream containers share the operating system kernel, and known vulnerabilities allow malicious users to escape containers and access both the kernel and the shared container. Native Docker technology reuses base images using image layer hash values ​​when running containers. However, multiple container applications sharing a base image also introduces security risks; corruption or attacks on the base image can render large-scale applications unusable.

[0006] Kubernetes is designed for managing container workloads and services in general scenarios, but it cannot achieve isolation between applications with different security levels. When applied to classified areas, the deployment method of Kubernetes clusters and application scheduling methods need to be modified to match the requirements of classified areas. Summary of the Invention

[0007] To address the shortcomings and security risks of existing container technologies when applied to classified fields, this invention proposes a classified cluster system applicable to Kubernetes cluster systems, and a method for utilizing container technology based on the confidentiality level of classified applications in the classified cluster system, achieving cluster network separation, confidentiality level matching image scheduling, container image isolation, and secure container application deployment.

[0008] On the one hand, the present invention proposes a cluster system with high involvement, which is applicable to Kubernetes cluster systems. The system includes four parts: management cluster, business cluster, image repository and cluster network.

[0009] Manage the cluster, deploy the Kubernetes cluster management components, deploy the management nodes in a highly available manner, and manage the business cluster and image repository through the cluster management network;

[0010] Business applications are deployed in business clusters, and these applications are deployed in business clusters that match the application's security level. Business clusters with different security levels are physically isolated from each other. Each node in a business cluster has two network exits: a management network card and a business network card. The management network card is connected to a unified management network, while the business network card is connected to a business network that matches the security level.

[0011] The image repository centrally manages all images of different security levels and accepts unified scheduling of images from the management cluster through the management network.

[0012] The cluster network is divided into two parts: the management network and the business network. The management network is a dedicated network for communication between the management cluster, the business cluster, and the image repository. It mainly transmits management and control data and image data. The business network is divided into unclassified network, confidential network, and secret network according to the level of confidentiality. The networks of different levels are isolated from each other.

[0013] Furthermore, the cluster network divides the Kubernetes cluster network into a management network and a data network. The management cluster manages all business application clusters and image repositories through an encrypted and authenticated management network. Business application clusters and image repositories can only communicate one-to-one with the management cluster and cannot access each other through the management network. Business application clusters with different security levels are physically isolated and connected to isolated and independent corresponding security level data networks.

[0014] Furthermore, the management cluster includes a primary management node and several backup management nodes.

[0015] Furthermore, the image repository includes non-classified application images, classified application images, and secret application images.

[0016] On the other hand, the present invention proposes a method for exploiting container technology based on the security level of classified applications using the above-mentioned system, the method specifically including:

[0017] Step 101: Upload the image to the image repository. When uploading the image, add a confidentiality level label to the image and indicate the confidentiality level of the image.

[0018] Step 102: When creating an application, select the security level image corresponding to the application from the image repository;

[0019] Step 103: Based on the application security level, the scheduler of the management node calculates the business clusters and worker nodes for application deployment using a security level-based orchestration and scheduling algorithm, and notifies the corresponding business clusters and worker nodes.

[0020] Step 104: If this is the first installation, the business cluster and worker nodes calculated in Step 103 will pull the image from the image repository through the management network; otherwise, the image that has already been pulled locally on the node will be used.

[0021] Step 105: In non-classified application clusters, use a regular container runtime image to create the application; in confidential and secret application clusters, use a secure container runtime image to create the application.

[0022] Furthermore, this paper applies container technology and Kubernetes technology to the security requirements of classified fields, and proposes methods such as cluster network separation, image scheduling based on security level matching, container image isolation, and secure container application deployment, which improves the stability of classified application container operation and the security of the operating environment.

[0023] Furthermore, the image scheduling method based on security level matching in step S103 ensures that business applications run on clusters and nodes that meet their security levels. It achieves security level matching scheduling by modifying the Kubernetes container scheduling algorithm. Based on the security level of the created application, the image is scheduled from the image repository to the corresponding security level cluster and node. Application images with mismatched security levels cannot be pulled and started, thus realizing image scheduling based on security level matching.

[0024] Furthermore, regular containers reuse the underlying base image, while secure containers use a separate base image.

[0025] Furthermore, the container image isolation method addresses the risks that may arise from reusing base images by improving the image storage logic based on the container ID. Instead of reusing base images, the required base images are copied to the confidential container application when the container is created, ensuring that the base image of each application container is used independently.

[0026] When creating a secure container, first create a folder based on the secure container ID, copy the required base image to this folder, and then mount the image file in the corresponding container ID folder according to the container ID.

[0027] Step S105 involves deploying and running confidential and secret applications using secure containers. A secure container is essentially a miniature virtual machine with an independent kernel, providing a complete operating system execution environment for container applications and separating application execution from the host operating system. Secure containers offer virtual machine-level security and container-level running speed. Through secure containers, the kernel, computing resources, storage, and network supporting the application container are isolated, preventing the application from directly accessing the host operating system.

[0028] The advantages of this invention over the prior art are:

[0029] This invention proposes a Kubernetes cluster system suitable for classified applications, and a method for utilizing container technology based on the confidentiality level of classified applications. This method achieves cluster network separation, security level-matched image scheduling, container image isolation, and secure container application deployment. Through secure containers, the kernel, computing resources, storage, and network of the application container are isolated, preventing the application from directly accessing the host operating system. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of a Kubernetes cluster deployment in the classified field of this invention;

[0031] Figure 2 This is a schematic diagram of the image management, matching scheduling, and application creation process based on application security levels;

[0032] Figure 3 This is a diagram illustrating the mounting of application container images with different security levels. Detailed Implementation

[0033] like Figure 1 As shown, the present invention provides a cluster system for Kubernetes cluster systems, which includes four parts: management cluster, business cluster, image repository and cluster network.

[0034] The management cluster deploys Kubernetes cluster management components, and the management nodes are deployed in a highly available manner. The business cluster and image repository are managed through the cluster management network.

[0035] Business applications are deployed in business clusters. These applications are deployed within business clusters that match their security level, and business clusters with different security levels are physically isolated from each other. Each node in a business cluster has two network exits: a management network interface card (NIC) and a business NIC. The management NIC connects to a unified management network, while the business NIC connects to a business network matching its security level.

[0036] The image repository centrally manages all images of different security levels and accepts unified scheduling of images from the management cluster through the management network.

[0037] The cluster network is divided into two parts: a management network and a business network. The management network is a dedicated network for communication between the management cluster, business clusters, and the image repository, primarily transmitting management and control data and image data. The business network is divided into unclassified, confidential, and secret networks according to their security levels, with each level of network isolated from the others.

[0038] The cluster network divides the Kubernetes cluster network into a management network and a data network. The management cluster manages all business application clusters and image repositories through an encrypted and authenticated management network. Business application clusters and image repositories can only communicate one-to-one with the management cluster and cannot access each other through the management network. Business application clusters with different security levels are physically isolated and connected to isolated and independent corresponding security level data networks.

[0039] The management cluster includes a primary management node and several backup management nodes.

[0040] The image repository includes non-classified application images, classified application images, and secret application images.

[0041] The Kubernetes cluster network is divided into a management network and a service network. Management cluster nodes, image repositories, and application cluster nodes of different security levels connect to the management network via management network interface cards (NICs). Nodes joining the management network must register with the management cluster and undergo encrypted authentication before receiving communication messages from other nodes within the management network. Within the management network, application clusters can only communicate with image repositories and management clusters whose security levels match their own; they cannot access each other through the management network. The service network is divided into unsecured, confidential, and secret service networks. Application clusters access the service network corresponding to their security level via service NICs. Application clusters of different security levels are physically isolated; only clusters connected to the same security level network can communicate with each other, while service networks of different security levels cannot communicate with each other.

[0042] The management cluster comprises multiple management nodes, including a primary management node and several backup management nodes. The minimum number of management cluster nodes is three, and it can be expanded to an odd number based on the number of cluster nodes connected to the management network. Each management node runs multiple management components, including an ETCD component, a Scheduler component, an API-Server component, and a Controller component. The ETCD component is responsible for data storage of the entire Kubernetes cluster, storing all cluster status and configuration information. The Scheduler component is responsible for scheduling newly created workloads to appropriate clusters and nodes based on various constraints, such as security rules and hardware resources. The API-Server component provides API services for the Kubernetes cluster, receiving and processing requests from various clients. The Controller component monitors and regulates the cluster status.

[0043] The image repository includes a non-classified application image repository, a confidential application image repository, and a secret application image repository. It stores application images whose security level matches that of the image repository, and receives management information from the management cluster, as well as image pull access requests from application clusters whose security levels match.

[0044] Under the Kubernetes cluster architecture applicable to the aforementioned classified areas, through methods such as Figure 2 The method described eliminates security risks associated with the application of container technology in classified fields. The method for utilizing container technology based on the security level of classified applications specifically includes:

[0045] Step 101: Upload the image to the image repository. When uploading the image, add a confidentiality level label to the image and indicate the confidentiality level of the image.

[0046] Step 102: When creating an application, select the security level image corresponding to the application from the image repository.

[0047] Step 103: Based on the application security level, the scheduler of the management node calculates the business clusters and worker nodes for application deployment using a security level-based orchestration and scheduling algorithm, and notifies the corresponding business clusters and worker nodes.

[0048] Step 104: If this is the first installation, the business cluster and worker nodes calculated in step 103 will pull the image from the image repository through the management network; otherwise, the image that has already been pulled locally on the node will be used.

[0049] Step 105: In non-classified application clusters, create applications using regular container runtime images. In confidential and secret application clusters, create applications using secure container runtime images.

[0050] Furthermore, this paper applies container technology and Kubernetes technology to the security requirements of classified fields, and proposes methods such as cluster network separation, image scheduling based on security level matching, container image isolation, and secure container application deployment, which improves the stability of classified application container operation and the security of the operating environment.

[0051] Furthermore, the image scheduling method based on security level matching in step S103 ensures that business applications run on clusters and nodes that meet their security levels. It achieves security level matching scheduling by modifying the Kubernetes container scheduling algorithm. Based on the security level of the created application, the image is scheduled from the image repository to the corresponding security level cluster and node. Application images with mismatched security levels cannot be pulled and started, thus realizing image scheduling based on security level matching.

[0052] Furthermore, use regular containers to create non-classified applications, and use secure containers to create confidential and secret applications.

[0053] Furthermore, regular containers reuse the underlying base image, while secure containers use a separate base image.

[0054] Furthermore, the container image isolation method addresses the risks associated with reusing base images by improving the image storage logic based on container IDs. Instead of reusing base images, containers for confidential applications copy the required base images to the confidential container application during container creation, ensuring that each application container's base image is used independently. When creating a secure container, a folder is first created based on the secure container ID, and the required base images are copied into this folder. Then, the secure container mounts the image files from the corresponding container ID folder based on the container ID.

[0055] Step S105 involves deploying and running confidential and secret applications using secure containers. A secure container is essentially a miniature virtual machine with an independent kernel, providing a complete operating system execution environment for container applications and separating application execution from the host operating system. Secure containers offer virtual machine-level security and container-level running speed. Through secure containers, the kernel, computing resources, storage, and network supporting the application container are isolated, preventing the application from directly accessing the host operating system.

[0056] In the Kubernetes cluster architecture applicable to the aforementioned classified areas, container isolation is used to eliminate the risks associated with image reuse for confidential and secret applications, such as... Figure 3 As shown.

[0057] like Figure 3As shown, non-secure applications are created and run using ordinary containers, reusing the underlying image. Containers 1 and 2 of the non-secure application reuse the underlying images of CentOS, Apt-getDependencies, and Application Binary. Since underlying images are widely used during application creation and execution, reusing them can save a significant amount of image storage space. However, this method also carries certain risks; if any underlying image is corrupted or unavailable, a large number of applications will fail to function properly.

[0058] To address the risks associated with reusing underlying images, secure containers are used to create and run confidential and secret applications with higher security levels, employing an underlying image isolation method. When creating a secure container, a folder is first created based on the secure container ID, and the required underlying images are copied into this folder. Then, the secure container mounts the image files from the corresponding container ID folder based on the container ID. In this way, confidential and secret applications use independent underlying images, and the corruption or unavailability of the underlying image of a single container will not affect the normal operation of other application containers.

[0059] Those skilled in the art will readily understand that the above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A dense cluster system, characterized in that, The aforementioned cluster system is applicable to Kubernetes cluster systems, and the system includes four parts: management cluster, business cluster, image repository, and cluster network. Manage the cluster, deploy the Kubernetes cluster management components, deploy the management nodes in a highly available manner, and manage the business cluster and image repository through the cluster management network; Business clusters are used to deploy business applications. The business applications are deployed in business clusters that match the application security level, and business clusters with different security levels are physically isolated from each other. The image repository centrally manages all images of different security levels and accepts unified scheduling of images from the management cluster through the management network. The cluster network is divided into two parts: the management network and the business network. The management network is a dedicated network for communication between the management cluster, the business cluster, and the image repository. It mainly transmits management and control data and image data. The business network is divided into unclassified network, confidential network, and secret network according to the level of confidentiality. The networks of different levels are isolated from each other.

2. The dense cluster system as described in claim 1, characterized in that, Each node in the service cluster has two network exits: a management network card and a service network card. The management network card is connected to a unified management network, while the service network card is connected to a service network that matches the security level.

3. The dense cluster system as described in claim 1, characterized in that, The cluster network is divided into a management network and a data network. The management cluster manages all business clusters and image repositories through an encrypted and authenticated management network. Business clusters and image repositories can only communicate one-to-one with the management cluster and cannot access each other through the management network. Business clusters with different security levels are physically isolated and connected to isolated and independent corresponding security level data networks.

4. The dense cluster system as described in claim 1, characterized in that, The management cluster includes a primary management node and several backup management nodes.

5. The dense cluster system as described in claim 1, characterized in that, The image repository includes non-classified application images, classified application images, and secret application images.

6. A method for utilizing container technology based on the security level of classified applications, characterized in that, Utilizing the dense cluster system as described in claims 1-5, the method specifically includes: Step 101: Upload the image to the image repository. When uploading the image, add a confidentiality level label to the image and indicate the confidentiality level of the image. Step 102: When creating an application, select the security level image corresponding to the application from the image repository; Step 103: Based on the application security level, the scheduler of the management node calculates the business clusters and worker nodes for application deployment using the security level orchestration and scheduling algorithm, and notifies the corresponding business clusters and worker nodes. Step 104: If this is the first installation, the business cluster and worker nodes calculated in Step 103 will pull the image from the image repository through the management network; otherwise, the image that has already been pulled locally on the node will be used. Step 105: In non-classified application clusters, use a regular container runtime image to create the application; in confidential and secret application clusters, use a secure container runtime image to create the application.

7. The method for utilizing container technology based on the security level of classified applications as described in claim 6, characterized in that, To meet the security requirements of classified fields, this paper proposes a method for cluster network separation, image scheduling based on security level matching, container image isolation, and secure container application deployment, applying container and Kubernetes technologies.

8. The method for utilizing container technology based on the security level of classified applications as described in claim 6, characterized in that, In step 103, the image scheduling method based on security level matching ensures that business applications run on clusters and nodes that meet their security levels. It achieves security level matching scheduling by modifying the Kubernetes container scheduling algorithm. Based on the security level of the created application, the image is scheduled from the image repository to the corresponding security level cluster and node. Application images with mismatched security levels cannot be pulled and started, thus realizing image scheduling based on security level matching.

9. The method for utilizing container technology based on the security level of classified applications as described in claim 6, characterized in that, Regular containers reuse the underlying base image, while secure containers use a separate base image.

10. The method for utilizing container technology based on the security level of classified applications as described in claim 7, characterized in that, The container image isolation method described above improves the image storage logic based on the container ID. Instead of reusing the base image, the required base image is copied to the confidential container application when the container is created, ensuring that the base image of each application container is used independently.

11. The method for utilizing container technology based on the confidentiality level of classified applications as described in claim 6, characterized in that, When creating a secure container, first create a folder based on the secure container ID, copy the required base image to the folder, and then mount the image file in the corresponding container ID folder according to the container ID.

12. The method for utilizing container technology based on the security level of classified applications as described in claim 6, characterized in that, Step 103 involves deploying and running confidential and secret applications using secure containers. Secure containers are essentially miniature virtual machines with independent kernels, providing a complete operating system execution environment for container applications and separating application execution from the host operating system. Secure containers offer virtual machine-level security and container-level running speed. Through secure containers, the kernel, computing resources, storage, and network of the application container are isolated, preventing the application from directly accessing the host operating system.

Images