CONTAINER PLATFORM-ORIENTED TRUSTED SOFTWARE AUTHORIZATION AND VERIFICATION SYSTEM AND METHOD

Abstract

Provided are a container platform-oriented trusted software authorization and verification system and a method, the system including a public key infrastructure builder, a container image identity builder, a signature list builder, a container image verifier, a signature list and user certificates loader, and a container program verifier. The method is capable of conveniently authorizing container images and software running in the container, and verifying the container images and programs in the container at the right time, so as to ensure that container images running on the container platform are trusted, and the software running in the container is also trusted, thereby improving the security of the container platform.

Claims

1. A container platform-oriented trusted software authorization and verification system, comprising a public key infrastructure builder, a container image identity builder, a signature list builder, a container image verifier, a signature list and user certificates loader, and a container program verifier, wherein the public key infrastructure builder is configured to build a public key infrastructure, and issue a user certificate-key pair for each user according to different application scenarios; the container image identity builder is configured to generate container images having identities with the same functions based on the original container image using a digital signature algorithm and the user certificate-key pair and push the container images to a container image repository for use, wherein each identity comprises a user certificate and an original container image signature generated by the user's private key and a subsequent container platform will pull the container images from the image repository to start the container; the signature list builder is configured to generate a signature list for the container image using a digital signature algorithm and the user certificate-key pair and upload the signature list to the container platform; the signature list containing programs capable of being run by the container based on the container image; the container image verifier is configured to verify the identity of the container image to ensure the trustworthiness of the container image when the container is created; and suspend the creation process of the container when the verification fails; the signature list and user certificates loader is configured to load the signature list for the container image and a user certificate of an image producer into an operating system kernel as programs inside the container for verification when the container is started; and the container program verifier is configured to verify programs inside the container based on the loaded signature list and user certificate after loading the programs capable of being run by the container based on the container image and before the programs run, and suspend the running of the programs when the verification fails.

2. The container platform-oriented trusted software authorization and verification system of claim 1, wherein in the public key infrastructure builder, the building a public key infrastructure, and issuing a user certificate-key pair for each user comprises: building, according to different application scenarios, different certificate key trees in which a root is a self-signed certificate, and leaf nodes are user certificates; between the root and the leaf nodes, there are a plurality of layers corresponding to different management levels in reality; the certificates of each layer are issued by an upper layer except for the certificates at the root; organizations of different management levels decide to issue and revoke certificates of the next level in the organization to facilitate management.

3. The container platform-oriented trusted software authorization and verification system of claim 1, wherein the container image identity builder is configured to: build an identity of the container image for each container image to complete the authorization of the container image; wherein the identity of the container image comprises signatures for the content of the container image and important configuration by a user using the user's own private keys, and the user's certificate; the important configuration comprises environment variables, ports, startup commands, startup parameters, data volume, working directory, and user ID; the signature contains the integrity information on the container image, and the certificate contains the information on the container image producer; wherein the container image is unchangeable; the container image identity builder is configured to package the original container image, signature and certificate to obtain a new container image in order to bind the identity of the container image to the container image; and put the signature and certificate in a predetermined directory of the new container image, and thus the new container image has the same functions and important configuration as the original container image, and also has image identity information.

4. The container platform-oriented trusted software authorization and verification system of claim 1, wherein the signature list builder is configured to generate a signature list for each container image to complete the authorization of the container program; the signature list contains all the programs capable of being run in the container based on the container image; for each program authorized to be run, the user uses his own private key to calculate the signature of the program file and put the signature into the signature list; each item in the signature list represents a program, and each item comprises program signature, program hash value, and program name.

5. The container platform-oriented trusted software authorization and verification system of claim 1, wherein the container image verifier is configured to verify the container image when the container is created; the verification comprises: verifying whether a certificate carried by the image belongs to the certificate key tree of the container platform; continuing verification when the certificate carried by the image belongs to the certificate key tree of the container platform, or determining that the verification fails when the certificate carried by the image does not belong to the certificate key tree of the container platform; verifying a signature carried by the image using the certificate which belongs to the certificate key tree of the container platform, wherein the content in the predetermined directory is excluded during the verification; and verifying the content in the predetermined directory to ensure that the directory only contains a certificate and a signature file; the verification of the signature and the content verifies the integrity of the container image and ensures that neither the content nor the configuration of the container image have been tampered.

6. The container platform-oriented trusted software authorization and verification system of claim 1, wherein the signature list and user certificates loader is configured to: load the signature list and certificate only when the verification of the container image passes before all the programs in the container run when the container is started, wherein the startup of the container occurs after the container is created; load both signature list and certificate from a user space into a kernel space and write through a file system; when data are loaded using the file system, data write points are placed in a directory that only the host may access, thereby avoiding that the signature list or certificate is tampered by a malware in the container; and write the signature list and certificate prior to converting a host file system to a container file system.

7. The container platform-oriented trusted software authorization and verification system of claim 6, wherein in a kernel, a plurality of data structures are used to organize the signature list, and the data structures comprise one or more of a linked list, a doubly linked list, a hash table, a red-black tree, and a radix tree.

8. The container platform-oriented trusted software authorization and verification system of claim 6, wherein when a user certificate is loaded, it is necessary to verify the legality of the user certificate, that is, to verify whether the certificate belongs to the certificate key tree of the container platform, wherein all the certificates at all non-leaf nodes of a certificate key tree of the platform into the kernel are loaded in advance by writing when the kernel is compiled or loading when the system is started; when the user certificate is illegal, the certificate is refused to be loaded, and all subsequent verifications will fail.

9. The container platform-oriented trusted software authorization and verification system of claim 1, wherein the container program verifier is configured to: identify different containers in the operating system kernel in order to verify the program running in the container, and the identification varies depending on the operating system; in a Linux system, the mount namespace id in the kernel is used to identify different containers in the kernel.

10. The container platform-oriented trusted software authorization and verification system of claim 9, wherein the container program is verified after the program file is loaded into the memory and before the program file is performed; for Linux systems, the verification of the container program is performed in a LSM hook comprising mmap_file and bprm_check_security; the verified files comprise executable binary programs, dynamic link libraries, and executable scripts; the verification comprises checking whether the signature of the program file is in the signature list, as well as verifying whether the signature in the signature list is correct.

11. The container platform-oriented trusted software authorization and verification system of claim 9, wherein the results of verification are cached to improve the efficiency of verification, and only the signature for unverified program files or changed program files is verified; wherein each container corresponds to a cache, and a program file on the host is stored the same in caches of different containers, thereby avoiding that files on a host shared by different container images affect the verification of the program in the container.

12. A container platform-oriented trusted software authorization and verification method, comprising: building a public key infrastructure according to application scenarios and issuing a user certificate-key pair for each user; generating container images having identities with the same functions based on the original container image using a digital signature algorithm and the user certificate-key pair, and pushing the container images to a container image repository, wherein each identity comprises a user certificate and an original container image signature generated by the user's private key, and a subsequent container platform pulls the container images from the image repository to start the container; generating a signature list for the container image using a digital signature algorithm and the user certificate-key pair and uploading the signature list to the container platform, wherein the signature list contains programs capable of being run by the container based on the container image; verifying the identity of the container image when the container is created to ensure the trustworthiness of the container image; and suspending the creation process of the container when the verification fails; loading the signature list of the container image and the user certificate in the identity of the container image to an operating system kernel for subsequent verification of programs running in the container when the container is started; and verifying programs in the operating system kernel based on the signature list and user certificate after loading the programs capable of being run by the container based on the container image and before the programs run, and suspending the running of the programs when the verification fails.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0057] FIG. 1 shows a hierarchical model of a container platform;

[0058] FIG. 2 is a diagram showing an overall architecture of a container platform-oriented trusted software authorization and verification system according to the present application;

[0059] FIG. 3 is a flow chart showing a container platform-oriented trusted software authorization and verification method according to the present application;

[0060] FIG. 4 shows an example of a three-layer certificate key tree according to the present application;

[0061] FIG. 5 shows an example of a signature list according to the present application; and

[0062] FIG. 6 shows an example of a cache structure according to the present application.

DETAILED DESCRIPTION

[0063] The present application will be described in detail below in conjunction with the drawings and embodiments.

[0064] As shown in FIGS. 2 and 3, the overall framework of the container platform-oriented trusted software authorization and verification system according to the present application includes: a public key infrastructure builder, a container image identity builder, a signature list builder, a container image verifier, a signature list and user certificates loader, and a container program verifier.

[0065] (1) The public key infrastructure builder is configured to build a public key infrastructure, and issue a user certificate-key pair for each user according to different application scenarios. This is the foundation of the entire system.

[0066] (2) The container image identity builder is configured to generate container images having identities with same functions based on the original container image using a digital signature algorithm and the user certificate-key pair and push the container images to a container image repository for use.

[0067] (3) The signature list builder is configured to generate a signature list for the container image using a digital signature algorithm and a user certificate-key pair and upload the signature list to the container platform. The signature list contains programs capable of being run by the container based on the container image.

[0068] (4) The container image verifier is configured to verify the identity of the container image to ensure that the container image is trusted when the container is created. The creation process of the container is suspended when the verification fails.

[0069] (5) The signature list and user certificates loader is configured to when the container is started, load the signature list for the container image and a user certificate of a container image producer into a kernel.

[0070] (6) The container program verifier is configured to verify programs inside the operating system based on the loaded signature list and user certificate after loading the programs in the container and before the programs run. The running of the programs is suspended when the verification fails.

[0071] The six modules of the system will be described in detail below.

[0072] (1) Public Key Infrastructure Builder

[0073] A container service provider needs to build a public key infrastructure, thereby generating a certificate-key pair for each user of the container platform. According to different application scenarios, different certificate key trees need to be built. In the certificate key tree, the root is a self-signed certificate, and the leaf nodes are user certificates; between the root and the leaf nodes, there are a plurality of layers corresponding to different management levels in reality; except for those at the root, the certificates of each layer are issued by an upper layer; organizations of different management levels decide to issue and revoke certificates of the next level in the organization to facilitate management. FIG. 4 shows a three-layer certificate key tree. The three layers in the certificate key tree are a root, a department layer, and a user layer. The root is a self-signed certificate. The certificate of the department layer is issued by the root and the certificate of the user layer is signed and issued by the department. All the private keys in the certificate key tree of the public key infrastructure built by this public key infrastructure builder are offline to ensure the security of the private keys.

[0074] (2) Container Image Identity Builder

[0075] The container image identity builder is configured to build an identity for each container image to complete the authorization of the container image. The identity for the container image includes two parts. One part is signature for the content of the container image and important configuration made by a user using his own private key and important configuration including, but not limited to, environment variables, ports, startup commands, startup parameters, data volume, working directory, user ID and the like. The other part is user's certificate. The signature contains the integrity information on the container image, and the certificate contains the information on the container image producer. The two parts together constitute the identity of the container image.

[0076] The container image is unchangeable. In order to bind the identity of the container image to the container image, the original container image, signature and certificate need to be packaged to obtain a new container image, while a directory must be predetermined in advance, such as /etc/identity/, and the signature and certificate are put in the directory of the new container image and thus the new container image has the same functions and important configuration as the original container image, and also has image identity information. This method is applicable to both layered images (such as Docker images) and non-layered images (such as rkt images), and is universal.

[0077] After the container images having identities is built, the user needs to push these images to a container image repository, and the subsequent container platform will pull the container image from the image repository to start the container.

[0078] (3) Signature List Builder

[0079] For each container image, a signature list is generated to complete the authorization of the container program. The signature list contains all programs capable of being run by the container based on the container image. For each program authorized to be run, the user uses his own private key to calculate the signature of the program file and put the signature into the signature list. Each item in the signature list represents a program, and each item includes but is not limited to the program signature, program hash value, and program name. In addition, the program signature may be represented using a variety of representation methods including binary, base64 encoding, and hexadecimal character strings. FIG. 5 shows an example of a signature list. The signature list contains a plurality of signature items. Each signature item contains three parts, which are program hash value, program name, and program signature. The program hash value is represented by hexadecimal strings, and the program signature is represented by base64 encoding. After the signature list is generated, the user needs to upload the signature list to the container platform. When the container is started, the list and the corresponding user certificate will be together loaded into the kernel for subsequent verification of running programs in the container.

[0080] (4) Container Image Verifier

[0081] The verification of the container image is performed when the container is created. The verification process includes three steps: a first step, verifying whether a certificate carried by the image belongs to the certificate key tree of the container platform, continuing to a second step of verification when the certificate carried by the image belongs to the certificate key tree of the container platform, and determining that the verification fails when the certificate carried by the image does not belong to the certificate key tree of the container platform, which ensures that the source of the container image is legal. A second step, verifying a signature carried by the image using the certificate on which the verification passes in the first step, wherein the content in the predetermined directory (such as /etc/identity/) needs to be excluded during this step of verification. A third step, verifying the content in the predetermined directory to ensure that the directory (such as /etc/identity/) only contains two files, namely a certificate and a signature file. Above two steps are used for verifying the integrity of the container image and ensure that the content and configuration of the container image have not been tampered.

[0082] To speed up the verification of the container image, the hash value maintained by the container engine, such as the sha256 value of each layer of the image maintained by Docker may be used in this step. However, it is unnecessary to use the hash value.

[0083] (5) Signature List and User Certificates Loader

[0084] The loading of the signature list and certificate is performed only when the verification of the container image passes before all the programs in the container run when the container is started, wherein the startup of the container occurs after the container is created.

[0085] Both signature list and certificate are loaded from a user space into a kernel space and written through a file system, for example, a security file system of Linux; but other methods can also be employed. The file systems used by the container are parts of the host file system, and the container accesses different file systems. Taking Linux systems as an example, they use different mount namespaces and root file systems. Therefore, when data are loaded using the file system, data write points should be placed in a directory that only the host may access, thereby preventing the signature list or certificate from being tampered by malware in the container. The writing of the signature list and certificate should be prior to conversion of a host file system to a container file system.

[0086] In a kernel, a plurality of data structures are used to organize the signature list, and include a linked list, a doubly linked list, a hash table, a red-black tree, and a radix tree.

[0087] When a user certificate is loaded, it is necessary to verify the legality of the user certificate, that is, to verify whether the certificate belongs to the certificate key tree of the container platform. Therefore, it is necessary to load all the certificates at all non-leaf nodes of a certificate key tree of the platform into the kernel in advance. The certificates are written when the kernel is compiled or loaded when the system is started. When the user certificate is illegal, the certificate is refused to be loaded, and all subsequent verifications will fail.

[0088] (6) Container Program Verifier

[0089] In order to verify the program running in the container, it is necessary to identify different containers in the operating system kernel, and the identification process varies depending on the operating system. In a Linux system, the mount namespace id in the kernel may be used to identify different containers in the kernel; when the signature list and user certificate are loaded, the kernel is notified of the mount namespace id corresponding to the container when the container is running.

[0090] The verifying of the container program is after the program file is loaded into the memory and before the performance of the program file starts. For Linux systems, the verification of the container program is performed in a LSM hook used including mmap_file and bprm_check_security. The verified files include executable binary programs, dynamic link libraries, executable scripts and the like. For Linux systems, the binary programs and dynamic link libraries may be verified in the LSM hook mmap_file and the executable scripts may be verified in the mmap_file bprm_check_security. The verification includes checking whether the signature of the program file is in the signature list, as well as verifying whether the signature in the signature list is correct.

[0091] In order to improve the efficiency of verification, it is necessary to cache the results of verification, and only verify the signature for unverified program files or changed program files. Each container corresponds to a cache, and the same program file on the host may be stored separately in the caches of different containers, thereby avoiding that files on a host shared by different container images affect the verification of the program in the container. FIG. 6 shows an example of a cache structure. The cache structure creates three types of caches for each container in the kernel, which are a file cache, a signature cache, and a namespace cache. For each program to be run in the container, a file cache which contains an inode of a file, a version of the file, hash values of the file, and verification results of the file is created; the version of the file is configured to identify whether the file has been modified, and the verification results of the file are configured to record results of verifying the file at the last time; and all files are cached to form a red-black tree, wherein the root is in the namespace cache, and the key is the inode of the file. For each signature item in the signature list, a signature cache which contains hash values of programs, signatures of programs, and verification results of the signature is created; the verification results of the signature are configured to record whether the signatures are valid, avoiding repeated verification of the signatures; and a signature cache for a signature file forms a red-black tree, wherein the root is in the namespace cache, and the key is the program hash value. For each container, a namespace cache which contains a mount namespace id, user certificate of the container, and the root of the file cache and signature cache red-black tree is created; all namespace caches in the kernel form a radix tree, wherein the root is a global variable, and the key is mount namespace id. With the cache structure, the data used by the container program may be effectively organized and verified, and the executable program in the container may be verified securely and efficiently.

[0092] In short, software running on the container platform, specifically including container images and programs running in the container is authorized; the source and integrity of the container images and programs running in the container are verified at good time; trustless software is further prevented from running on the platform, which ensures that both container images running on the container platform and the programs running in the container are trusted, thereby improving the security of the container platform.

[0093] The above-mentioned embodiments are provided only for the purpose of describing the present application, but are not intended to limit the scope of the present application. The scope of the present application is defined by the appended claims. Various equivalent substitutions and modifications made without departing from the principle of the present application should all fall within the scope of the present application.