License verification method and device for private deployment of k8s or docker environment

Abstract

The invention discloses a License verification method and a License verification device for private deployment of a k8s or docker environment. When the method is applied to a client, the method comprises the following steps: firstly, creating a target container by using k8s or Docker, and running target application software; then, obtaining the MAC address of the physical machine; then, according to the token information of the user, the current unique identification code of the container and the MAC address, generating a license application request, and encrypting the license application request; then, the encrypted license application request is sent to a server side to generate an authorization certificate, and the authorization certificate is encrypted; and the client receives the encrypted authorization certificate returned by the server and decrypts the encrypted authorization certificate to obtain the decrypted authorization certificate. And finally, the system verifies the authorization information in the decrypted authorization certificate, and loads a corresponding application software function module in the operation environment of the target container according to a verification result. According to the method, the security and reliability of license verification are remarkably improved, and legal use of software is ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of network data security, and in particular relates to a license verification method and device for privatized deployment in a k8s (Kubernetes, an open source container orchestration platform) or docker (an open source platform) environment. Background Art

[0002] With the acceleration of digitalization and the widespread application of 5G technology, more and more factories and enterprises are actively promoting modernization and transformation, resulting in a rapid increase in demand for software. At the same time, with the continuous improvement of data security awareness, enterprises are paying more attention to data privacy protection, and the demand for private deployment is growing. In order to prevent privately deployed software from being cracked, software providers face higher requirements in license verification and need to consider both offline and online usage scenarios.

[0003] At present, the mainstream license verification methods are mainly divided into online verification and offline verification. Online verification refers to sending the license certificate to the server for remote verification, while offline verification is to parse the license information and verify the machine code, identification code, timestamp and other information locally to determine the validity of the license certificate.

[0004] However, existing license verification methods, whether online or offline, usually rely on the host's MAC address and verify the validity of the timestamp. This method is effective in traditional physical machine environments, but with the development of container technologies such as Docker and Kubernetes, multiple containers can run on the same physical machine, and the MAC addresses obtained by these containers are the same. The existing technology faces an inevitable problem, that is, when multiple Docker containers share the MAC address of the same physical machine, they may use the same license certificate. This phenomenon will cause the existing verification method to become less secure. Summary of the invention

[0005] The technical problem to be solved by the present invention is to solve the above-mentioned deficiencies in the prior art and propose a license verification method and device for private deployment in a k8s or docker environment. The method can not only ensure the security of license verification, but also prevent multiple Docker containers from using the same license certificate when sharing the MAC address of the same physical machine, thereby improving the security and reliability of license verification.

[0006] In a first aspect, the present invention provides a license verification method for privatized deployment in a k8s or docker environment, which is applied to a client and comprises the following steps:

[0007] Step S1: Generate a license application request based on the user token information, the current unique identification code of the target container, and the MAC address of the physical machine running the target container;

[0008] Wherein, the target container is a k8s or docker environment running the target application software;

[0009] Step S2: Encrypt the license application request;

[0010] Step S3: Sending the encrypted license application request to the server, so that the server generates an authorization certificate and encrypts the authorization certificate after decrypting the license application request;

[0011] Step S4: receiving the encrypted authorization certificate returned by the server;

[0012] Step S5: decrypt the encrypted authorization certificate to obtain a decrypted authorization certificate;

[0013] Step S6: Verify the authorization information in the decrypted authorization certificate, and load the functional module of the target application software in the target container operating environment according to the verification result to complete the License verification for the private deployment of the k8s or docker environment.

[0014] Furthermore, before the step S1, the method further includes a step S0;

[0015] Step S0: Using k8s or docker, create a target container and run the target application software; and obtain the MAC address of the physical machine running the target container;

[0016] The target application software is deployed by the user on the client based on k8s or docker.

[0017] Furthermore, the generating of the license application request specifically includes:

[0018] Generate a certificate initial application request, or generate a certificate upgrade application request;

[0019] The encryption of the license application request is specifically as follows:

[0020] Use symmetric encryption to encrypt the license application request.

[0021] Further, the functional module includes a basic functional module and an additional functional module, and the additional functional module includes a first functional module, a second functional module, ..., an Nth functional module; N is a natural number greater than or equal to 1;

[0022] The step of loading the functional module of the target application software in the target container operating environment according to the verification result specifically includes:

[0023] If the verification result is a verification failure, the basic function module is loaded in the target container operating environment;

[0024] If the verification result is successful, the basic function module and the additional function module corresponding to the authorization scope are loaded in the target container operating environment according to the authorization scope.

[0025] Furthermore, the verification of the authorization information in the decrypted authorization certificate specifically includes the following steps:

[0026] Step A1: extract the certificate container identification code, certificate MAC address list, certificate factoryCode, and certificate validity period from the authorization information in the decrypted authorization certificate;

[0027] Step A2: Determine whether the certificate container identification code is consistent with the current unique identification code of the container, and determine whether to proceed to step A3 based on the determination result;

[0028] Step A3: Determine whether the MAC address is in the certificate MAC address list, and determine whether to proceed to step A4 based on the determination result;

[0029] Step A4: Determine whether the factoryCode in the certificate is consistent with the factoryCode in the user token information, and determine whether to proceed to step A5 based on the determination result;

[0030] Step A5: Determine whether the current time exceeds the validity period of the certificate;

[0031] If the current time exceeds the validity period of the certificate, the verification is determined to have failed and the process ends; if the current time does not exceed the validity period of the certificate, the verification is determined to have succeeded, thereby completing the verification of the authorization information in the decrypted authorization certificate.

[0032] In a second aspect, the present invention provides a license verification method for privatized deployment in a k8s or docker environment, which is applied to a server side, and the method comprises the following steps:

[0033] Receive the encrypted license application request sent by the client;

[0034] The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, and the MAC address is the MAC address of the physical machine running the target container;

[0035] Wherein, the target container is a k8s or docker environment running the target application software;

[0036] Decrypting the encrypted license application request to obtain a license application request;

[0037] Generate an authorization certificate based on the license application request;

[0038] Encrypting the authorization certificate to obtain the encrypted authorization certificate;

[0039] The encrypted authorization certificate is sent to the client, so that the client can decrypt the encrypted authorization certificate, verify the authorization information in the authorization certificate, and load the functional module of the target application software in the target container running environment according to the verification result to complete the license verification for the private deployment of the k8s or docker environment.

[0040] Furthermore, the encryption of the authorization certificate is specifically as follows:

[0041] The authorization certificate is encrypted using an asymmetric encryption method.

[0042] Furthermore, generating an authorization certificate according to the license application request specifically includes:

[0043] Generate a new authorization certificate based on the license application request; or generate an upgraded authorization certificate based on the license application request.

[0044] In a third aspect, the present invention provides a license verification device for privatized deployment in a k8s or docker environment, which is applied to a client and includes:

[0045] The first generating unit is used to generate a license application request according to the user token information, the current unique identification code of the target container, and the MAC address of the physical machine running the target container;

[0046] Wherein, the target container is a k8s or docker environment running the target application software;

[0047] a first encryption unit, connected to the first generation unit, and configured to encrypt the license application request;

[0048] A first sending unit, connected to the first encryption unit, and configured to send the encrypted license application request to the server, so that the server generates an authorization certificate and encrypts the authorization certificate after decrypting the license application request;

[0049] A first receiving unit, connected to the server end sent by the first sending unit, and used to receive the encrypted authorization certificate returned by the server end;

[0050] A first decryption unit, connected to the first receiving unit, for decrypting the encrypted authorization certificate to obtain a decrypted authorization certificate;

[0051] a verification unit, connected to the first decryption unit, and configured to verify the authorization information in the decrypted authorization certificate;

[0052] The loading unit is connected to the verification unit and is used to load the functional module of the target application software in the target container operating environment according to the verification result of the verification unit to complete the license verification for the private deployment of the k8s or docker environment.

[0053] In a fourth aspect, the present invention provides a license verification device for privatized deployment in a k8s or docker environment, which is applied to a server side, and the device includes:

[0054] The second receiving unit is used to receive the encrypted license application request sent by the client;

[0055] The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, where the MAC address is the MAC address of the physical machine running the target container; the target container is the k8s or docker environment running the target application software;

[0056] a second decryption unit, connected to the second receiving unit, and configured to decrypt the encrypted license application request to obtain a license application request;

[0057] A second generating unit, connected to the second decrypting unit, for generating an authorization certificate according to the license application request;

[0058] A second encryption unit, connected to the second generation unit, is used to encrypt the authorization certificate to obtain an encrypted authorization certificate;

[0059] The second sending unit is connected to the second encryption unit, and is used to send the encrypted authorization certificate to the client, so that the client decrypts the encrypted authorization certificate, verifies the authorization information in the authorization certificate, and loads the functional module of the target application software in the target container running environment according to the verification result, so as to complete the License verification for the private deployment of the k8s or docker environment.

[0060] The present invention implements license verification through target containers and dynamic license management mechanisms, which can not only ensure the security of license verification, but also prevent multiple Docker containers from using the same license certificate when sharing the MAC address of the same physical machine, thereby improving the security and reliability of license verification. The specific beneficial effects are as follows:

[0061] 1. Guarantee the uniqueness of the license: The present invention combines the user token, the container unique identification code and the physical machine MAC address to enable each container to apply for a unique license, which greatly reduces the risk of license sharing and abuse.

[0062] 2. Improve data security: The present invention uses encryption technology to protect license application requests and authorization certificates, ensure the security of data during network transmission, and effectively prevent data from being intercepted and tampered with.

[0063] 3. Flexible license management: The present invention supports flexible and dynamic management of licenses in a Kubernetes or Docker environment, enabling enterprises to quickly create and destroy containers based on actual needs while maintaining effective control over licenses.

[0064] 4. Automated verification process: The present invention simplifies the license verification process through automatic encryption and decryption mechanisms, reduces manual intervention, improves management efficiency and reduces operational error rates.

[0065] 5. Utilize container unique identifier: The present invention makes full use of the unique characteristics of the container unique identifier (container_id) and the container name (container_name). During the certificate generation process, the container ID and the container name are encrypted into the certificate. When verifying the certificate, these identifiers are verified to ensure that the certificate is specifically applied for the current container. This method effectively solves the problem caused by limiting the MAC address, because multiple identical containers may be running on a physical machine.

[0066] 6. Support application upgrade and prevent version conflicts: The present invention allows to apply for a new certificate during the application upgrade process, and the new certificate will encrypt the old container ID. When loading the certificate, the system will check whether the old container exists, so as to avoid the coexistence of multiple versions of the same application and prevent customers from having multiple sets of applications after purchasing once. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 This is a schematic diagram of a license verification method for privatized deployment in a k8s or docker environment in an embodiment of the present invention;

[0068] Figure 2 This is a license authorization flow chart in an embodiment of the present invention;

[0069] Figure 3 This is a service startup flow chart in an embodiment of the present invention;

[0070] Figure 4 This is a flow chart of applying for a certificate in an embodiment of the present invention;

[0071] Figure 5 This is a flow chart of applying for an upgrade certificate in an embodiment of the present invention;

[0072] Figure 6 is a flow chart of certificate verification in an embodiment of the present invention;

[0073] Figure 7 This is a schematic diagram of a license verification device for privatized deployment in a k8s or docker environment in an embodiment of the present invention;

[0074] Among them, the figure numbers are: 10, first generating unit, 20, first encryption unit, 30, first sending unit, 40, first receiving unit, 50, first decryption unit, 60, verification unit, 70, loading unit. DETAILED DESCRIPTION

[0075] In order to enable those skilled in the art to better understand the technical solution of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0076] It should be understood that the specific embodiments and drawings described herein are only used to explain the present invention rather than to limit the present invention.

[0077] It can be understood that, in the absence of conflict, the various embodiments of the present invention and the various features in the embodiments can be combined with each other.

[0078] It can be understood that, for the convenience of description, the drawings of the present invention only show the parts related to the present invention, while the parts irrelevant to the present invention are not shown in the drawings.

[0079] It can be understood that each unit and module involved in the embodiments of the present invention may correspond to only one physical structure, or may be composed of multiple physical structures, or multiple units and modules may be integrated into one physical structure.

[0080] It can be understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of the present invention may occur in an order different from that marked in the drawings.

[0081] It is understood that the flowcharts and block diagrams of the present invention illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present invention. Each box in the flowchart or block diagram may represent a unit, module, program segment, or code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented by a hardware-based system that implements the specified functions, or may be implemented by a combination of hardware and computer instructions.

[0082] It can be understood that the units and modules involved in the embodiments of the present invention can be implemented by software or hardware. For example, the units and modules can be located in a processor.

[0083] Embodiment 1:

[0084] like Figure 1 and Figure 2 As shown, the present invention provides a license verification method for privatized deployment in a k8s or docker environment, which is applied to a client. The method in this embodiment is applicable to scenarios requiring high security and compliance. In these environments, the method can ensure that each container can only use its legal license to prevent abuse of the license. At the same time, it supports dynamic scaling and offline usage to ensure effective verification when the container is started and stopped. In addition, the method can also be seamlessly integrated with the continuous integration and continuous delivery (CI / CD) process to provide license verification in automated deployment.

[0085] The method is a license verification method for private deployment in Kubernetes (k8s) or Docker environments, which aims to ensure the legal use and deployment of software. The following are the detailed steps and application examples of the method:

[0086] Step by step guide

[0087] 1. Create and run the container:

[0088] Use k8s or Docker to create a target container and run the target application software in it. These applications are deployed by users on the client based on k8s or Docker. The target container is the k8s or docker environment that runs the target application software.

[0089] 2. Get information and generate requests:

[0090] Get the MAC address of the physical machine running the target container. In a Kubernetes (k8s) cluster environment, since multiple physical machines may jointly support running the target container, obtaining the MAC address of the physical machine running the target container may involve the collection of one or more MAC addresses. This is because each physical machine has its own MAC address, and in a cluster environment, containers may be deployed or migrated across multiple machines, so it is necessary to ensure that the MAC addresses of all relevant physical machines are collected to enable accurate license verification.

[0091] The target container has a current unique identifier. In a Kubernetes (k8s) or Docker environment, each target container is assigned a unique identifier to ensure its uniqueness in the entire cluster. This unique identifier consists of two parts: container_id and container_name. Among them, container_id is the unique identification number of the container, usually composed of a string of randomly generated characters, which is used to accurately identify each container instance. Container_name is an easy-to-read name set for the container, which is convenient for users to identify and reference. Together, these two constitute the complete identity information of the container, so that each container can be accurately identified and managed in a complex containerized deployment environment.

[0092] Generate a license application request based on the user's token information, the container's unique identifier, and the MAC address. This request can be a certificate initial application request or a certificate upgrade application request. In a Kubernetes (k8s) or Docker environment, in order to apply for or update a software license, the system generates a license application request based on the token information provided by the user, the container's unique identifier (including container_id and container_name), and the MAC address of the physical machine. This request may be for the first time to obtain a license, that is, a certificate initial application request, or to update an existing license, that is, a certificate upgrade application request. In this way, the system can ensure that each request is targeted at a specific user and container environment, thereby providing precise license management and authorization. This process not only enhances security, but also ensures the compliant use of licenses and adapts to dynamically changing containerized deployment environments.

[0093] Use symmetric encryption to encrypt the license application request. After the license application request is generated, the system encrypts it using symmetric encryption to ensure the security of the request during transmission. Symmetric encryption uses the same key for encryption and decryption, and both the sender and the receiver must hold the key. First, the system generates a secure symmetric key, and then uses the key and encryption algorithm (such as AES) to convert the license application request into ciphertext, ensuring that even if it is intercepted during transmission, unauthorized third parties cannot read the request content. After receiving the encrypted request, the receiver uses the same key to decrypt it, thereby restoring the original request and performing subsequent processing. This method effectively protects sensitive information and prevents data leakage. The encrypted license application request is then sent to the server.

[0094] In this process, the server-side processing steps are as follows: after the server decrypts the request, it generates an authorization certificate and encrypts the authorization certificate.

[0095] In this process, the processing steps on the server side are as follows: First, after receiving the encrypted license application request, the server uses the same symmetric key as the client to decrypt the request to obtain the original application content. After decryption, the server generates a corresponding authorization certificate based on the information in the request, which contains the user's authorization information and usage rights. In order to ensure the security of the authorization certificate during transmission, the server then encrypts the generated authorization certificate using asymmetric encryption. Specifically, the server encrypts the certificate using its private key to ensure that only the client holding the corresponding public key can decrypt and access the contents of the authorization certificate. This approach not only enhances security, but also ensures the confidentiality and integrity of the authorization certificate during transmission, effectively preventing unauthorized access.

[0096] 4. Receive and decrypt the authorization certificate:

[0097] The client receives the encrypted authorization certificate returned by the server, and decrypts the encrypted authorization certificate to obtain the decrypted authorization certificate.

[0098] After the client receives the encrypted authorization certificate returned by the server, it will first decrypt the certificate to obtain its original content. Specifically, the client uses the public key obtained previously to decrypt the encrypted authorization certificate. After successful decryption, the client will obtain the decrypted authorization certificate, which contains the user's authorization information and usage rights. This process ensures that only authorized clients can access and use the contents of the authorization certificate, thereby effectively protecting the security and integrity of the license.

[0099] 5. Verify authorization information:

[0100] Extract the certificate container identification code, certificate MAC address list, certificate factoryCode, certificate validity period and other authorization information from the decrypted authorization certificate.

[0101] Perform a series of checks:

[0102] Check whether the certificate container identification code is consistent with the container's current unique identification code.

[0103] Check whether the MAC address is in the certificate MAC address list.

[0104] Check whether the factoryCode in the certificate is consistent with the factoryCode in the user token information.

[0105] Determine whether the current time exceeds the validity period of the certificate.

[0106] During the verification of authorization information, the system will perform a series of key verification steps to ensure the legitimacy and validity of the authorization. First, the system will check whether the container identification code in the certificate is consistent with the unique identification code of the current container to confirm that the authorization certificate is generated for the correct container. Next, the system will confirm whether the MAC address of the current physical machine is in the MAC address list of the certificate to ensure that the authorization certificate is applicable to the current operating environment. In addition, the system will also check whether the factoryCode in the certificate is consistent with the factoryCode in the user token information to verify the user's identity and authority. Finally, the system will determine whether the current time exceeds the validity period of the certificate to ensure that the authorization certificate is still valid and has not expired. Through these comprehensive checks, the system can effectively ensure the safe use and compliance of the software.

[0107] 5. Load functional modules:

[0108] If the verification fails, only basic function modules can be loaded in the target container runtime environment.

[0109] If the verification is successful, based on the authorization scope, the basic function module and the additional function module corresponding to the authorization scope (such as the first function module, the second function module, etc., until the Nth function module, where N is a natural number greater than or equal to 1) are loaded in the target container operating environment.

[0110] To illustrate: Suppose a company uses Docker to deploy a data analysis software that requires specific data processing modules to be enabled based on different user licenses. The company generates a unique token and container identifier for each customer.

[0111] Deployment phase: Deploy the software in the Docker container and obtain the MAC address of the container and its host.

[0112] License application: Generate an encrypted license application based on the provided token, container identifier, and MAC address.

[0113] License authorization: The server generates a corresponding authorization certificate based on the request and sends it back to the client after encryption.

[0114] Function activation: The client decrypts the authorization certificate, verifies the information, and then activates the corresponding data processing module based on the authorization.

[0115] This method ensures the security and validity of software licenses by comprehensively utilizing multiple verification mechanisms such as container identification codes, MAC addresses, and factoryCodes. It is suitable for enterprise environments that require high security and flexible deployment.

[0116] like Figure 2 As shown, this embodiment involves users, clients, and servers. The users here refer to customers, the server is a service provider responsible for generating license certificates, and the client refers to a server that privately installs the service, which is a server on the client side. The overall process includes deploying applications, applying for certificates, generating certificates, importing certificates, and upgrading certificates.

[0117] The premise of the current process is that the docker environment has been installed in the customer server environment. First, the user needs to deploy application A in the container environment. When deploying the container, the environment variables FactoryCode:XX and Aeskey:XX need to be set. These two data will be generated when the user purchases the application and will be verified later during the certificate verification. Application A will load the local certificate when it starts. If there is no certificate or the certificate has expired, only basic system functions can be accessed. If the certificate is valid, the authorized content will be loaded. At this time, the access system can access all authorized content. For details, Figure 3 shown.

[0118] After the service container is deployed, you can obtain the container identifier container_id and the container name container_name. Before applying for a certificate, you also need to obtain the mac address of the physical machine.

[0119] like Figure 4 As shown, if the user has purchased the application and has not applied for a certificate, the process is as follows:

[0120] (1) After the user deploys application A using k8s or docker on the server, obtain the container's unique identifier container_id and container name container_name through the command line. These two parameters are unique in the same container environment and cannot be tampered with. At the same time, container_id is automatically generated and cannot be forged. It will basically not be repeated under different servers and has high uniqueness. The user also needs to obtain the MAC address of the server. If it is a k8s cluster, the mac address of each device, such as M1, M2, and M3, needs to be obtained.

[0121] (2) After the user logs in to the license certificate application system, he enters the container unique identifier C1, container name CN, and MAC address (separated by commas if there are multiple): M1, M2, M3 to apply for a certificate. The client carries the user token to request the server to apply for a certificate interface.

[0122] (3) The server parses the user ID based on the requested token to determine whether the user has purchased the app.

[0123] (4) The user directly reports an error message without purchasing the app.

[0124] (5) If the user has purchased the application, the server obtains the validity period ET, the user's enterprise code FC, and the modules N1, N2, N3, and N4 authorized to the user by querying the database data. When purchasing an application, the purchase is made based on the module, so the authorized modules owned by different users are also different. The authorized modules will also be placed in the license certificate.

[0125] (6) If the user has already applied for a certificate or the application owned by the user has expired, an error message will be reported directly.

[0126] (7) Assemble the information entered by the user on the page and the authorization module and authorization time obtained by the server into a json string M, as follows {"mac":"M1,M2,M3","container_id":"C1","container_name":"CN","expire":"ET","factory":"FC","content":"N1,N2,N3,N4"}.

[0127] (8) The server generates an RSA key pair pubA and priA. The key here is mainly used by the server to sign the certificate with priA, and the application uses pubA to verify the signature.

[0128] (9) The server generates an AES key SA for the certificate, which is used to encrypt the JSON string M mentioned above ME, and signs ME with priA to obtain the signature value SN. ME, SA, priA, and SN are concatenated in sequence with | to generate the string K.

[0129] (10) When a user purchases an application, an AesKey SC is automatically generated. This value is placed in the environment variable when the user deploys the application and is also saved on the server. Here, the string K is encrypted with SC and then encrypted with base64 and output to the file license.key.

[0130] (11) The interface returns the certificate file license.key, which the user can download directly.

[0131] After applying for a certificate, if the user needs to upgrade the system, he needs to apply for the certificate again. When applying for the certificate again, he needs to carry the historical container information to avoid users deploying two new and old systems on one server. The new certificate will contain a new authorization return, and the old application needs to be offline when the new certificate is used, otherwise the new certificate verification will fail. The process of applying for an upgraded certificate is as follows: Figure 5 shown.

[0132] The process of applying for an upgraded certificate is similar to the first application. To apply for an upgraded certificate, the user needs to provide the old certificate. The server will parse the information contained in the old certificate and encrypt the old container ID information in the certificate when the certificate is generated. When verifying the certificate, it will determine whether the old container has been offline. The specific process is as follows:

[0133] (1) The user first takes application A offline, and then uses k8s or docker to deploy application A again. Then, the user obtains the container's unique identifier, container_id, and container name, container_name, through the command line. These two parameters are unique in the same container environment and cannot be tampered with. At the same time, container_id is automatically generated and cannot be forged. It will not be repeated under different servers and has high uniqueness. The server's MAC address will be parsed and obtained from the user's old certificate.

[0134] (2) After the user logs in to the license certificate application system, he enters the container unique identifier C1, container name CN, and old certificate to apply for a certificate. The client carries the user token to request the server to apply for a certificate interface.

[0135] (3) The server parses the user ID based on the requested token to determine whether the user has purchased the application and whether the old certificate was applied for by the user.

[0136] (4) If the user has not purchased the application or the certificate was not applied for by the user, an error message will be displayed directly.

[0137] (5) If the verification is successful, the server queries the database data to obtain the validity period ET purchased by the user, the user's enterprise code FC, and the modules N1, N2, N3, and N4 authorized to the user. The modules here include the modules purchased by the user and the modules that are open for free during the system upgrade process. Then, the server decrypts the certificate file passed in by the user and obtains the user's old container_id C2. The old container C2 is also placed in the license certificate. During the verification, it will determine whether the old container exists.

[0138] (6) If the application owned by the user has expired, an error message will be reported directly.

[0139] (7) Assemble the information entered by the user on the page and the authorization module and authorization time obtained by the server into a json string M, as follows {"mac":"M1,M2,M3","container_id":"C1","container_name":"CN","expire":"ET","factory":"FC","content":"N1,N2,N3,N4","old_container":"C2"}

[0140] (8) The server generates an RSA key pair pubA and priA. The key here is mainly used by the server to sign the certificate with priA, and the application uses pubA to verify the signature.

[0141] (9) The server generates an AES key SA for the certificate, which is used to encrypt the JSON string M mentioned above ME, and signs ME with priA to obtain the signature value SN. ME, SA, priA, and SN are concatenated in sequence with | to generate the string K.

[0142] (10) When a user purchases an application, an AesKey SC is automatically generated. This value is placed in the environment variable when the user deploys the application and is also saved on the server. Here, the string K is encrypted with SC and then encrypted with base64 and output to the file license.key.

[0143] (11) The interface returns the certificate file license.key, which the user can download directly.

[0144] Finally, there is the certificate verification logic. The certificate verification is triggered after the service is started or after the user imports the certificate. Figure 6The following is the process of applying the license certificate verification. The legitimacy of the certificate will be verified when the user imports the certificate or the container starts. The complete steps are as follows:

[0145] (1) First, read the environment variables of the container and obtain factoryCode FC and AesKey SC.

[0146] (2) Read the contents of the certificate and perform base64 decryption. If the decryption fails, an error message will be displayed.

[0147] (3) The above base64 decrypted data is decrypted by AES using the key SC to obtain a string. The string is split using the "|" symbol to obtain the encrypted data ME, encryption key SA, private key priA, and signature SN in sequence.

[0148] (4) Use priA to verify the signature of SN to determine whether the data has been tampered with. If the signature verification fails, an error message will be displayed.

[0149] (5) By reading the files in the container, you can obtain the current container ID and container name, and at the same time obtain the MAC address of the current node physical machine for subsequent judgment of the validity of the certificate.

[0150] (6) Use the decrypted SA to decrypt the encrypted data ME and obtain the json string of the encrypted information.

[0151] (7) This step verifies the legitimacy of the container information. If the verification fails, an error is reported. First, check whether the id and name of the current container are consistent with the certificate, then check whether the physical MAC address of the current node is in the MAC address list of the certificate, then check whether the enterprise information factoryCode is consistent, and then check whether the current time has exceeded the validity period. Finally, use the Docker API interface to determine whether the old container id exists. If it exists, the verification will fail and the old container needs to be taken offline first.

[0152] (8) If verification succeeds, the authorization information is loaded into the cache and the license certificate is saved locally. If the container is restarted later, the certificate will be loaded directly from the local computer for verification.

[0153] The above is the license verification process based on the private deployment of k8s and docker environment containers, including certificate application, certificate upgrade and certificate verification.

[0154] This embodiment makes full use of the non-repeatable characteristics of the container unique identifier (container_id) and the container name (container_name). During the certificate generation process, the system encrypts the container ID and container name into the certificate to ensure that each certificate is specifically applied for a specific container. When verifying the certificate, by verifying these unique identifiers, the system can confirm that the certificate does correspond to the currently running container. This method effectively solves the problems caused by relying solely on the MAC address, because multiple identical containers may be running on the same physical machine. In addition, this embodiment also supports applying for a new certificate during the application upgrade process, and the new certificate will encrypt the old container ID. When loading the certificate, the system checks whether the old container still exists, thereby avoiding multiple versions of the same application running at the same time and preventing customers from having multiple sets of applications after purchasing once. This design not only enhances the security of license management, but also improves the compliance and user experience of the software.

[0155] Embodiment 2:

[0156] This embodiment provides a license verification method for private deployment in a k8s or docker environment, which is applied to a server. The method includes the following steps:

[0157] Receive the encrypted license application request sent by the client;

[0158] The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, and the MAC address is the MAC address of the physical machine running the target container;

[0159] Decrypting the encrypted license application request to obtain a license application request;

[0160] Generate an authorization certificate based on the license application request;

[0161] Encrypting the authorization certificate to obtain the encrypted authorization certificate;

[0162] The encrypted authorization certificate is sent to the client, so that the client can decrypt the encrypted authorization certificate, verify the authorization information in the authorization certificate, and load the functional module of the target application software in the target container running environment according to the verification result to complete the license verification for the private deployment of the k8s or docker environment.

[0163] Furthermore, the encryption of the authorization certificate is specifically as follows:

[0164] The authorization certificate is encrypted using an asymmetric encryption method.

[0165] Furthermore, generating an authorization certificate according to the license application request specifically includes:

[0166] Generate a new authorization certificate based on the license application request; or generate an upgraded authorization certificate based on the license application request.

[0167] Embodiment 3:

[0168] like Figure 7 As shown, this embodiment provides a license verification device for private deployment in a k8s or docker environment, which is applied to a client and includes:

[0169] The first generating unit is used to generate a license application request according to the user token information, the current unique identification code of the target container, and the MAC address of the physical machine running the target container;

[0170] a first encryption unit, connected to the first generation unit, and configured to encrypt the license application request;

[0171] A first sending unit, connected to the first encryption unit, and configured to send the encrypted license application request to the server, so that the server generates an authorization certificate and encrypts the authorization certificate after decrypting the license application request;

[0172] A first receiving unit, connected to the server end sent by the first sending unit, and used to receive the encrypted authorization certificate returned by the server end;

[0173] A first decryption unit, connected to the first receiving unit, for decrypting the encrypted authorization certificate to obtain a decrypted authorization certificate;

[0174] a verification unit, connected to the first decryption unit, and configured to verify the authorization information in the decrypted authorization certificate;

[0175] The loading unit is connected to the verification unit and is used to load the functional module of the target application software in the target container operating environment according to the verification result of the verification unit to complete the license verification for the private deployment of the k8s or docker environment.

[0176] The device in this embodiment can execute the method in embodiment 1.

[0177] Embodiment 4:

[0178] This embodiment provides a license verification device for private deployment in a k8s or docker environment, which is applied to a server side. The device includes:

[0179] The second receiving unit is used to receive the encrypted license application request sent by the client;

[0180] The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, and the MAC address is the MAC address of the physical machine running the target container;

[0181] a second decryption unit, connected to the second receiving unit, and configured to decrypt the encrypted license application request to obtain a license application request;

[0182] A second generating unit, connected to the second decrypting unit, for generating an authorization certificate according to the license application request;

[0183] A second encryption unit, connected to the second generation unit, is used to encrypt the authorization certificate to obtain an encrypted authorization certificate;

[0184] The second sending unit is connected to the second encryption unit, and is used to send the encrypted authorization certificate to the client, so that the client decrypts the encrypted authorization certificate, verifies the authorization information in the authorization certificate, and loads the functional module of the target application software in the target container running environment according to the verification result, so as to complete the License verification for the private deployment of the k8s or docker environment.

[0185] The device in this embodiment can execute the method in Embodiment 2.

[0186] It is to be understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present invention, but the present invention is not limited thereto. For those of ordinary skill in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A license verification method for private deployment in a k8s or docker environment, applied to a client, characterized in that: The method comprises the following steps: Step S1: Generate a license application request based on the user token information, the current unique identification code of the target container, and the MAC address of the physical machine running the target container; Wherein, the target container is a k8s or docker environment running the target application software; Step S2: Encrypt the license application request; Step S3: Sending the encrypted license application request to the server, so that the server generates an authorization certificate and encrypts the authorization certificate after decrypting the license application request; Step S4: receiving the encrypted authorization certificate returned by the server; Step S5: decrypt the encrypted authorization certificate to obtain a decrypted authorization certificate; Step S6: Verify the authorization information in the decrypted authorization certificate, and load the functional module of the target application software in the target container operating environment according to the verification result to complete the License verification for the private deployment of the k8s or docker environment.

2. According to claim 1, the license verification method for privatized deployment in k8s or docker environment is characterized in that: Before step S1, the method further includes step S0; Step S0: Using k8s or docker, create a target container and run the target application software; and obtain the MAC address of the physical machine running the target container; The target application software is deployed by the user on the client based on k8s or docker.

3. The license verification method for privatized deployment in k8s or docker environment according to claim 1 is characterized in that: The generating of the license application request specifically includes: Generate a certificate initial application request, or generate a certificate upgrade application request; The encryption of the license application request is specifically as follows: Use symmetric encryption to encrypt the license application request.

4. The license verification method for privatized deployment in a k8s or docker environment according to claim 1 is characterized in that: The functional modules include basic functional modules and additional functional modules, and the additional functional modules include a first functional module, a second functional module, ..., an Nth functional module; N is a natural number greater than or equal to 1; The step of loading the functional module of the target application software in the target container operating environment according to the verification result specifically includes: If the verification result is a verification failure, the basic function module is loaded in the target container operating environment; If the verification result is successful, the basic function module and the additional function module corresponding to the authorization scope are loaded in the target container operating environment according to the authorization scope.

5. The license verification method for privatized deployment in a k8s or docker environment according to any one of claims 1 to 4, characterized in that: The verification of the authorization information in the decrypted authorization certificate specifically includes the following steps: Step A1: extract the certificate container identification code, certificate MAC address list, certificate factoryCode, and certificate validity period from the authorization information in the decrypted authorization certificate; Step A2: Determine whether the certificate container identification code is consistent with the current unique identification code of the container, and determine whether to proceed to step A3 based on the determination result; Step A3: Determine whether the MAC address is in the certificate MAC address list, and determine whether to proceed to step A4 based on the determination result; Step A4: Determine whether the factoryCode in the certificate is consistent with the factoryCode in the user token information, and determine whether to proceed to step A5 based on the determination result; Step A5: Determine whether the current time exceeds the validity period of the certificate; If the current time exceeds the validity period of the certificate, the verification is determined to have failed and the process ends; if the current time does not exceed the validity period of the certificate, the verification is determined to have succeeded, thereby completing the verification of the authorization information in the decrypted authorization certificate.

6. A license verification method for private deployment in k8s or docker environment, applied to the server side, characterized in that: The method comprises the following steps: Receive the encrypted license application request sent by the client; The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, and the MAC address is the MAC address of the physical machine running the target container; Wherein, the target container is a k8s or docker environment running the target application software; Decrypting the encrypted license application request to obtain a license application request; Generate an authorization certificate based on the license application request; Encrypting the authorization certificate to obtain the encrypted authorization certificate; The encrypted authorization certificate is sent to the client, so that the client can decrypt the encrypted authorization certificate, verify the authorization information in the authorization certificate, and load the functional module of the target application software in the target container running environment according to the verification result to complete the license verification for the private deployment of the k8s or docker environment.

7. The license verification method for privatized deployment in k8s or docker environment according to claim 6 is characterized in that: The encryption of the authorization certificate is specifically as follows: The authorization certificate is encrypted using an asymmetric encryption method.

8. The license verification method for privatized deployment in a k8s or docker environment according to claim 6 or 7, characterized in that: The step of generating an authorization certificate according to the license application request specifically includes: Generate a new authorization certificate based on the license application request; or generate an upgraded authorization certificate based on the license application request.

9. A license verification device for private deployment in a k8s or docker environment, applied to a client, characterized in that: include: The first generating unit is used to generate a license application request according to the user token information, the current unique identification code of the target container, and the MAC address of the physical machine running the target container; Wherein, the target container is a k8s or docker environment running the target application software; a first encryption unit, connected to the first generation unit, and configured to encrypt the license application request; A first sending unit, connected to the first encryption unit, and configured to send the encrypted license application request to the server, so that the server generates an authorization certificate and encrypts the authorization certificate after decrypting the license application request; A first receiving unit, connected to the server end sent by the first sending unit, and used to receive the encrypted authorization certificate returned by the server end; A first decryption unit, connected to the first receiving unit, for decrypting the encrypted authorization certificate to obtain a decrypted authorization certificate; a verification unit, connected to the first decryption unit, and configured to verify the authorization information in the decrypted authorization certificate; The loading unit is connected to the verification unit and is used to load the functional module of the target application software in the target container operating environment according to the verification result of the verification unit to complete the license verification for the private deployment of the k8s or docker environment.

10. A license verification device for private deployment in a k8s or docker environment, applied to a server, characterized in that: include: The second receiving unit is used to receive the encrypted license application request sent by the client; The license application request is generated by the client according to the user token information, the current unique identification code and MAC address of the target container, where the MAC address is the MAC address of the physical machine running the target container; the target container is the k8s or docker environment running the target application software; a second decryption unit, connected to the second receiving unit, and configured to decrypt the encrypted license application request to obtain a license application request; A second generating unit, connected to the second decrypting unit, for generating an authorization certificate according to the license application request; A second encryption unit, connected to the second generation unit, is used to encrypt the authorization certificate to obtain an encrypted authorization certificate; The second sending unit is connected to the second encryption unit, and is used to send the encrypted authorization certificate to the client, so that the client decrypts the encrypted authorization certificate, verifies the authorization information in the authorization certificate, and loads the functional module of the target application software in the target container running environment according to the verification result, so as to complete the License verification for the private deployment of the k8s or docker environment.

Images