Automatic decryption method and device for encryption configuration of cloud container cluster service, computer equipment and storage medium

Abstract

The invention discloses a cloud container cluster service encryption configuration automatic decryption method and device, computer equipment and a storage medium, the method comprises the following steps: loading configuration information of a target application from a configuration center, the configuration information comprising at least one encryption configuration field; identifying a target field with a (at) Decrypt annotation in the configuration information, wherein the (at) Decrypt annotation is used for marking a field needing to be decrypted; decrypting the encrypted configuration field based on a preset decryption rule to obtain a decrypted configuration value; and injecting the configuration value into the target field to complete configuration loading of the target application. By implementing the method, the development process can be simplified, code repetition is reduced, and the development efficiency is improved; in addition, different items can share the same decryption logic, code redundancy is reduced, the code reuse rate is improved, and the technical scheme can be applied to the fields of finance and medical health.

Description

Technical Field

[0001] This invention relates to the field of cloud container cluster service technology, and more specifically to a method, apparatus, computer equipment, and storage medium for automatically decrypting encrypted configurations of cloud container cluster services. Background Technology

[0002] In critical sectors such as finance and healthcare, as business complexity increases and security requirements rise, application systems typically need to dynamically read configuration information from configuration centers (such as Nacos) and decrypt encrypted configuration data when necessary. However, existing technologies have a series of significant defects and shortcomings in handling the reading and decryption of encrypted configurations, specifically in the following aspects:

[0003] Static decryption logic relies on hard coding: In the traditional approach, after loading configurations from configuration centers like Nacos, developers need to manually call decryption functions in their code to decrypt encrypted fields. This static decryption logic requires developers to hard-code the decryption logic in every place where configuration needs to be decrypted, leading to high code duplication and significantly increasing maintenance difficulty. If the decryption logic needs adjustment, all related code must be modified one by one, resulting in inefficiency and a high risk of errors.

[0004] Decryption logic is tightly coupled with configuration loading: Most existing systems tightly couple the configuration loading process with the decryption logic. This design pattern makes it impossible for the decryption logic to be reused or extended independently. For example, when different encryption fields or different encryption methods are required, developers have to write separate decryption logic for each encryption field, resulting in severe code redundancy. Furthermore, if the encryption method or decryption tool changes subsequently, the entire system's decryption logic needs to be adjusted accordingly, increasing system maintenance costs and risks.

[0005] Inability to automatically identify encrypted fields: While current mainstream configuration centers (such as Nacos) support dynamic loading of configurations, they generally lack the ability to automatically identify encrypted fields. This means that after the configuration is loaded, the system cannot automatically determine which fields need to be decrypted, and manual intervention is required. This manual judgment method is not only inefficient but also prone to errors, especially when processing a large number of configuration items, which further increases the risk of errors.

[0006] The lack of a unified and standardized encapsulation solution: Existing encryption configuration decryption solutions are mostly implemented "point-to-point," meaning that decryption logic is developed separately for each specific project or scenario, lacking a unified encapsulation mechanism and standardized interfaces. This decentralized implementation not only fails to create reusable components but also leads to the need for different projects to repeatedly implement the same decryption logic, resulting in severe code redundancy. Furthermore, due to the lack of a unified standard, decryption logic may differ between different projects, increasing the difficulty and cost of system integration.

[0007] In summary, existing technologies for handling the reading and decryption of encrypted configurations from the configuration center suffer from several significant shortcomings, including static decryption logic relying on hard-coded code, coupling of decryption logic with configuration loading, inability to automatically identify encrypted fields, and a lack of a unified, standardized encapsulation scheme. These problems not only reduce development efficiency and increase maintenance difficulty but also pose potential threats to system security and stability. Therefore, it is necessary to propose a new automatic decryption scheme for encrypted configurations to address these issues and improve the system's development efficiency, maintainability, and security. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide an automatic decryption method, apparatus, computer equipment and storage medium for encrypted configuration of cloud container cluster services.

[0009] To achieve the above objectives, the present invention adopts the following technical solution:

[0010] The automatic decryption method for encrypted configurations of cloud container cluster services includes:

[0011] Load the configuration information of the target application from the configuration center, the configuration information containing at least one encrypted configuration field;

[0012] Identify the target fields in the configuration information that are annotated with @Decrypt, whereby the @Decrypt annotation is used to mark the fields that need to be decrypted;

[0013] The encrypted configuration field is decrypted based on a preset decryption rule to obtain the decrypted configuration value;

[0014] The configuration value is injected into the target field to complete the configuration loading of the target application.

[0015] This invention also provides an automatic decryption device for encrypted configurations of cloud container cluster services, comprising:

[0016] A loading unit is used to load configuration information of a target application from a configuration center, the configuration information containing at least one encrypted configuration field;

[0017] The identification unit is used to identify target fields in the configuration information that are annotated with @Decrypt, whereby the @Decrypt annotation is used to mark fields that need to be decrypted;

[0018] The decryption unit is used to decrypt the encrypted configuration field based on a preset decryption rule to obtain the decrypted configuration value.

[0019] An injection unit is used to inject the configuration value into the target field to complete the configuration loading of the target application.

[0020] The present invention also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described method.

[0021] The present invention also provides a storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0022] The advantages of this invention compared to existing technologies are as follows: By introducing the @Decrypt annotation mechanism, developers no longer need to hardcode decryption logic in every configuration that requires decryption. They only need to add annotations to sensitive fields in the configuration class to automatically complete the decryption process. This design simplifies the development process, reduces code duplication, and improves development efficiency. The automated decryption process also reduces manual intervention, further accelerating development. Furthermore, by decoupling the decryption logic from the configuration loading process and encapsulating and reusing the decryption logic through a unified annotation mechanism and automatic configuration class, this design makes the modification and maintenance of the decryption logic more centralized and convenient. This eliminates the need for repeated modifications in multiple places. When the encryption method or decryption tool changes, only the relevant parts of the decryption logic need to be adjusted, without affecting other stages of configuration loading, thus enhancing system maintainability. Furthermore, through preset format conventions and the `@Decrypt` annotation, the system can automatically identify encrypted configuration fields that need decryption, eliminating the need for manual judgment or triggering of the decryption process. This mechanism not only reduces the risk of oversights caused by human operation but also terminates application startup upon decryption failure, preventing the use of uncracked sensitive configurations and improving configuration management security. Additionally, by encapsulating the decryption logic into a reusable Spring framework… The BootStarter component achieves the goal of "configure once, use everywhere," allowing different projects to share the same decryption logic, reducing code redundancy and improving code reusability. It also supports flexible extension and customization, allowing the addition of new encryption methods or decryption tools to meet security requirements in different scenarios. Furthermore, in cloud container cluster service scenarios, it supports dynamic configuration updates in the configuration center. When the encrypted configuration changes, the system can automatically reload the configuration, perform decryption, and inject the target fields without restarting the application. This feature adapts to the need for dynamic configuration adjustments in cloud environments, ensuring that applications always use the latest decrypted configuration and improving the automation level of configuration management in cloud container clusters.

[0023] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A schematic diagram illustrating an application scenario of the automatic decryption method for encrypted configuration of cloud container cluster services provided in this embodiment of the invention.

[0026] Figure 2A flowchart illustrating the automatic decryption method for encrypted configuration of cloud container cluster services provided in this embodiment of the invention;

[0027] Figure 3 A schematic block diagram of an automatic decryption device for encrypted configuration of cloud container cluster services provided in an embodiment of the present invention;

[0028] Figure 4 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0031] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0032] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0033] Please see Figure 1 and Figure 2 , Figure 1 This is a schematic diagram illustrating an application scenario of the automatic decryption method for encrypted configuration of cloud container cluster services provided in this embodiment of the invention. Figure 2A schematic flowchart illustrating the automatic decryption method for encrypted configuration of cloud container cluster services provided in this embodiment of the invention. The automatic decryption method for encrypted configurations in this cloud container cluster service is applied to the server, which interacts with the terminal. By introducing the `@Decrypt` annotation mechanism, developers no longer need to hardcode decryption logic in every configuration that requires decryption. They only need to add annotations to sensitive fields in the configuration class to automatically complete the decryption process, simplifying the development process, reducing code duplication, and improving development efficiency. In addition, by decoupling the decryption logic from the configuration loading process, and encapsulating and reusing the decryption logic through a unified annotation mechanism and automatic configuration class, the modification and maintenance of the decryption logic becomes more centralized and convenient. Furthermore, by using preset format conventions in conjunction with the `@Decrypt` annotation, the encrypted configuration fields that need to be decrypted can be automatically identified without manual judgment or manual triggering of the decryption process. This not only reduces the risk of oversights caused by human operation, but also terminates application startup when decryption fails, preventing the use of uncracked sensitive configurations and improving the security of configuration management. In addition, by encapsulating the decryption logic into a reusable Spring Boot Starter component, the goal of "one configuration, multiple uses" is achieved. Different projects can share the same set of decryption logic, reducing code redundancy and improving code reusability.

[0034] Figure 2 This is a flowchart illustrating the automatic decryption method for encrypted configuration of cloud container cluster services provided in this embodiment of the invention. Figure 2 As shown, the method includes the following steps S110 to S140.

[0035] S110. Load the configuration information of the target application from the configuration center, wherein the configuration information contains at least one encrypted configuration field;

[0036] Specifically, the configuration center can be Nacos. The target application imports a custom Spring Boot Starter component (spring-boot-starter-nacos-cyberark) via Maven / Gradle. This component has a built-in configuration loader (which can be the Nacos configuration loader) responsible for establishing a connection with the Nacos configuration center. Configure the Nacos address (e.g., server-addr:localhost:8848), namespace (e.g., namespace:public), and configuration file format (e.g., file-extension:yaml) in the target application's bootstrap.yml file to ensure that the Spring Boot Starter component can pull configurations via the Nacos SDK. Additionally, when Spring Boot starts, the Spring Boot Starter component automatically pulls the target application's configuration information (supporting yaml or properties formats) via the Nacos configuration loader. The configuration information is transmitted in JSON or YAML format, containing at least one encrypted configuration field. The encrypted configuration field must follow a preset format (i.e., the cyberark(...) format, for example: demo.dbPassword:"cyberark(encrypted-password)").

[0037] In other words, by encapsulating Nacos connection and loading logic through the Spring Boot Starter component, developers no longer need to manually write configuration fetch code, solving the problem of "coupling configuration loading and business logic" in traditional solutions and reducing code redundancy. Furthermore, loading configuration uniformly through the Spring Boot Starter component avoids duplicate development of Nacos connection logic across different projects, aligning with the design philosophy of "unified encapsulation" and reducing cross-project collaboration costs.

[0038] In one embodiment, before loading the configuration information of the target application from the configuration center, the method further includes:

[0039] The Spring Boot Starter component is pre-built, and the Spring Boot Starter component includes an auto-configuration class, a @Decrypt annotation definition, a decryptor (i.e., a CyberArk decryptor), and a decryption processor;

[0040] The auto-configuration class declares instances (i.e., Bean instances) of the decryptor and the decryption processor, which are automatically scanned and loaded by Spring Boot through a formatted file (i.e., META-INF / spring.factories).

[0041] Specifically, Maven / Gradle is used as the build tool, and a separate `spring-boot-starter-nacos-cyberark` module is created as a Spring Boot Starter component. The core directory structure of this module includes:

[0042] Annotation definition class: The @Decrypt annotation is declared as a field-level annotation using @Target(ElementType.FIELD), with no attribute configuration, and is only used to mark the field that needs to be decrypted.

[0043] The decryptor implementation class (CyberArk decryptor) includes methods such as checkFormat(String value) (validates the format of cyberark(...) using a regular expression), extractCiphertext(String value) (extracts the ciphertext within the brackets), and decrypt(String ciphertext) (calls the CyberArk security service API to perform decryption).

[0044] Decryption processor implementation classes, such as DecryptionBeanPostProcessor, are responsible for scanning beans in the Spring container, identifying fields annotated with @Decrypt, and triggering the decryption process.

[0045] Automatic configuration classes, such as NacosCyberarkAutoConfiguration, are used to integrate the above components and register beans with the Spring container.

[0046] In the Starter's configuration file (e.g., pom.xml), include the Nacos client dependency (for connecting to the configuration center) and the Spring Boot auto-configuration dependency (e.g., spring-boot-autoconfigure), and declare the components' exposed interfaces (e.g., @Decrypt annotation, decryptor API), hiding the internal implementation details. Additionally, package the Starter into a JAR file using `mvn clean install` and publish it to a private Maven repository (e.g., Nexus), allowing target applications to include it as a dependency (e.g., by declaring it in pom.xml). <dependency>).

[0047] In other words, by encapsulating the core components required for decryption, such as annotations, decryption logic, and processors, into independent Starters, the problem of redundant development of the same logic in different projects is avoided, thus solving the problem of "code redundancy caused by point-to-point implementation" in existing technologies and improving code reusability. In addition, the target application only needs to import the Starter dependency to use the automatic decryption function, without having to manually write annotation definitions, decryptors, or processors, simplifying the integration process, which is especially friendly to development teams with low technical barriers.

[0048] In one embodiment, loading the configuration information of the target application from the configuration center includes:

[0049] A connection is established with the configuration center through the Spring Boot Starter component, which contains a configuration loader;

[0050] Specifically, the pre-built spring-boot-starter-nacos-cyberark component integrates a Nacos configuration loader (based on the Nacos client SDK). This loader includes a connection management module (responsible for establishing TCP connections with the Nacos server), a configuration listening module (listening for dynamic configuration updates), and an authentication module (supporting authentication via username / password or AccessKey / SecretKey). Furthermore, the target application configures Nacos connection parameters in bootstrap.yml or application.yml. The Spring Boot Starter component automatically reads these parameters through Spring Boot's @ConfigurationProperties annotation, and the Nacos configuration loader establishes a persistent connection with the Nacos configuration center based on these parameters. Additionally, the Nacos configuration loader has a built-in reconnection mechanism. When the connection is interrupted (e.g., due to network fluctuations), it automatically attempts to re-establish the connection and records retry logs. If multiple connection failures occur, a fallback strategy is triggered (e.g., using locally cached configuration snapshots) to ensure the reliability of configuration loading.

[0051] In other words, by encapsulating Nacos connection logic through the Starter component, developers do not need to manually write connection code; they only need to configure basic parameters to complete the connection. This solves the problem of "hard-coded connection logic and repetitive development" in traditional solutions, lowering the development threshold. In addition, the built-in reconnection and degradation mechanisms adapt to complex network environments such as cloud container clusters (PKS), avoiding configuration loading failures due to temporary network problems and improving system availability.

[0052] The configuration loader obtains the configuration information of the target application from the configuration center.

[0053] Specifically, the Nacos configuration loader locates the target configuration file (e.g., demo-service.yaml) stored in Nacos based on the target application's `spring.application.name` (application name), configuration file format (e.g., `file-extension:yaml`), and grouping information. During the target application startup phase, the Nacos configuration loader retrieves configuration information from the Nacos configuration center via an HTTP GET request, supporting full retrieval (initial load) and incremental retrieval (during configuration updates). The retrieved configuration information is temporarily stored in memory as key-value pairs, with encrypted configuration fields following the `cyberark(...)` format (e.g., `db.password:cyberark(EncryptedPwd123)`). Additionally, the configuration loader registers a listener (based on Nacos's `ConfigService.addListener` method). When the configuration in Nacos changes, the listener automatically receives change notifications and re-retrieves the latest configuration, triggering subsequent decryption and injection processes without requiring a restart of the target application.

[0054] In other words, the entire process from configuration location to fetching is completed automatically by the loader without manual intervention, solving the problem of "manually triggering configuration retrieval dependencies" in traditional solutions and improving configuration management efficiency. A listening mechanism responds in real time to Nacos configuration changes, ensuring that the target application always uses the latest configuration, adapting to the "dynamic scaling and hot configuration updates" requirements of cloud container clusters and enhancing system flexibility. Furthermore, the fetched configuration information is directly passed to the subsequent annotation recognition and decryption stages, achieving a "load-decryption-injection" closed loop through internal flow within the Spring Boot Starter component, preventing configuration information from being exposed in business code and improving the security of sensitive data.

[0055] S120. Identify the target field in the configuration information that has the @Decrypt annotation, whereby the @Decrypt annotation is used to mark the field that needs to be decrypted;

[0056] Specifically, a custom `@Decrypt` annotation is defined, limiting its application to the field level (declared via `@Target(ElementType.FIELD)`) to mark configuration fields that need to be decrypted. Additionally, in the target application's configuration class (e.g., a class annotated with `@ConfigurationProperties`), the `@Decrypt` annotation is added to the fields that need decryption (e.g., `@Decryptprivate String dbPassword;`). Furthermore, the `DecryptionBeanPostProcessor` in the Spring Boot Starter component automatically scans all registered beans during the Spring container initialization phase (after the BeanFactory is created), and uses reflection to parse the fields in the configuration class, selecting fields annotated with `@Decrypt` as target fields.

[0057] In other words, developers only need to mark the fields to be decrypted using annotations, without having to manually call the decryption function in the business code. This solves the problem of "hard-coded decryption logic leading to code duplication and maintenance difficulties" in traditional solutions, thus improving development efficiency. In addition, clearly marking the target fields with annotations avoids oversights in manually judging the fields to be decrypted, ensuring that the decryption process only applies to necessary fields, thereby improving security.

[0058] In one embodiment, identifying the target field in the configuration information annotated with @Decrypt includes:

[0059] Scan the configuration classes of the target application;

[0060] Specifically, classes annotated with `@ConfigurationProperties` (used for binding configuration information) or annotated with `@Component`, `@Service`, etc., and containing configuration fields are defined as configuration classes to be scanned. Additionally, the `DecryptionBeanPostProcessor` in the Spring Boot Starter component, during the Spring container initialization phase (when the `postProcessBeanFactory` method is executed), retrieves all registered bean definitions from the `BeanFactory` and filters out classes that meet the "configuration class" criteria (such as beans annotated with `@ConfigurationProperties` or containing configuration fields). Furthermore, based on Spring's `BeanDefinitionRegistry`, all bean definitions are traversed, and annotation information (such as whether it contains `@ConfigurationProperties`) is obtained through reflection to determine the scope of configuration classes to be scanned, avoiding performance overhead caused by indiscriminately scanning non-configuration classes.

[0061] In other words, by using annotations to filter configuration classes, the scanning of irrelevant business classes is avoided, resource consumption is reduced, and scanning efficiency is improved, solving the cumbersome problem of "requiring manual specification of the decryption range" in traditional solutions. In addition, it supports configuration classes marked with various annotations (such as @ConfigurationProperties and @Component), covering common configuration binding scenarios in the target application and enhancing the versatility of the solution.

[0062] Parse the fields of the configuration class and filter out the fields annotated with @Decrypt as the target fields.

[0063] Specifically, for the scanned configuration class, all declared fields (including private fields) are obtained through reflection, and the annotation information of each field is traversed (using the Field.getAnnotations() method). Custom @Decrypt annotations are declared as field-level annotations (@Target(ElementType.FIELD)). If this annotation is detected during field parsing, the field is marked as a target field. For example, in the DemoConfig class above, the dbPassword field is selected as a target field because it has the @Decrypt annotation. Furthermore, the information of the selected target fields (including their class, field name, and field type) is temporarily stored in the DecryptionBeanPostProcessor's memory cache as a basis for subsequent decryption and injection.

[0064] In other words, by using annotations and reflection parsing, the traditional method of "manual judgment and hard-coding of decryption logic" is replaced, solving the shortcomings of existing technologies that "cannot automatically identify encrypted fields and rely on manual intervention," thus reducing the risk of human error. Furthermore, developers only need to annotate fields with the `@Decrypt` annotation, without needing to write decryption trigger logic in the business code, avoiding coupling between decryption logic and business logic and reducing code maintenance costs (e.g., when the encryption method changes, no modification to the business code is required, only an update to the Spring Boot Starter component). Additionally, by using a unified annotation mechanism to filter target fields, consistent decryption field identification logic is ensured across different projects and configuration classes, forming a standardized solution, improving team collaboration efficiency, and aligning with the design philosophy of "unified encapsulation and component reuse" in technical briefings.

[0065] S130. Decrypt the encrypted configuration field based on the preset decryption rules to obtain the decrypted configuration value;

[0066] Specifically, the CyberArk decryptor in the Spring Boot Starter component uses regular expressions (such as `cyberark\((.*?)\)`) to verify whether encrypted configuration fields conform to the `cyberark(...)` format. If they do not conform, a format exception is thrown. For fields that conform to the format, the ciphertext content between `cyberark` (and) is extracted (e.g., extracting `encrypted-password` from `cyberark(encrypted-password)`). The CyberArk decryptor calls the CyberArk security service's API interface, sends the extracted ciphertext to the server for decryption, and obtains the plaintext result (e.g., `decrypted-password`), which is the decrypted configuration value.

[0067] In other words, by matching the cyberark(...) format using regular expressions, the encrypted fields are automatically identified, solving the problem of "requiring manual intervention to judge encrypted fields" in traditional solutions and reducing the risk of human operation. In addition, the decryption rules (format verification, decryption service call) are encapsulated in the CyberArk decryptor. If the encryption method or decryption tool changes, only the decryptor needs to be modified, without adjusting the business code, thus solving the problem of "difficult expansion due to coupling between decryption logic and configuration loading".

[0068] In one embodiment, the step of decrypting the encrypted configuration field based on a preset decryption rule to obtain the decrypted configuration value includes:

[0069] The encrypted configuration field is matched using a regular expression to determine if it conforms to a preset format; if it does not conform, a format exception is thrown.

[0070] Specifically, the CyberArk decryptor uses a predefined regular expression `^cyberark\((.*)\)$` to match whether encrypted configuration fields begin with `cyberark` and end with `.*`, and contain ciphertext content (e.g., `cyberark(encrypted-password-123)`). After loading configuration information from Nacos, the CyberArk decryptor performs a regular expression match on each encrypted configuration field: if the field perfectly matches the above format (e.g., `cyberark(db-pwd-xxx)`), it is considered a valid encrypted field and proceeds to the next step; if it does not match (e.g., the field is `encrypted(db-pwd)` or `cyberarkdb-pwd`), an `EncryptionFormatException` is immediately thrown, with the exception message including the specific field name and the error reason (e.g., "Incorrect format, must conform to cyberark(...) specification"). After the exception is thrown, the decryption processor catches the exception and terminates the target application startup, while logging detailed error information to prevent the application from using incorrectly formatted configurations.

[0071] In other words, by using regular expressions to precisely match the cyberark(...) format, the traditional method of "manually determining the fields to be decrypted" is replaced. This solves the shortcomings of existing technologies that "cannot automatically identify encrypted fields and rely on manual intervention," reducing the risk of human error. In addition, format verification is performed before decryption, which can quickly detect incorrect configurations and terminate the startup, avoiding decryption failure or leakage of sensitive information due to format errors. This is especially suitable for fields with extremely high configuration security requirements, such as finance and healthcare, and improves system robustness.

[0072] If the conditions are met, the ciphertext content in the encryption configuration field is extracted;

[0073] Specifically, for encrypted configuration fields that pass format validation, the CyberArk decryptor uses the grouping function of the aforementioned regular expression to extract the content between `cyberark` (and) as the ciphertext. For example, for the field `cyberark(encrypted-db-password)`, the extracted ciphertext is `encrypted-db-password`; for the field `cyberark(secret-key-abc123)`, the extracted ciphertext is `secret-key-abc123`. Furthermore, the extracted ciphertext is temporarily stored in a memory cache as key-value pairs (field name - ciphertext) as input for subsequent decryption operations.

[0074] In other words, by extracting ciphertext using a unified logic, the extraction rules for different encrypted fields are consistent, avoiding decryption errors caused by differences in extraction methods. This solves the problem of "dispersed decryption logic and inconsistent processing rules" in traditional solutions. Furthermore, by explicitly separating the encryption format identifier (cyberark(...)) from the core ciphertext, the CyberArk decryptor ensures that it only decrypts valid ciphertext, improving decryption efficiency.

[0075] The CyberArk decryptor is invoked to decrypt the ciphertext content to obtain the decrypted configuration value.

[0076] Specifically, the CyberArk decryptor is initialized via an auto-configuration class when the Spring container starts. It includes built-in communication parameters for the CyberArk security service (such as the service address and authentication token, which can be injected through the target application's configuration file). The decryptor uses the extracted ciphertext as a parameter to call the CyberArk security service's decryption API (such as an HTTPS POST request). An example process is as follows: a request is sent to https: / / cyberark-service:443 / decrypt, carrying the ciphertext `encrypted-db-password` and authentication information; the decryption result (such as `plaintext-db-password`) is received from the service. If decryption is successful, the plaintext configuration value is returned; if decryption fails (e.g., invalid ciphertext, service unavailable), a `DecryptionFailedException` is thrown, the application startup is terminated, and an error log is logged.

[0077] In other words, the decryption logic is encapsulated within the CyberArk decryptor. Developers do not need to hardcode decryption API calls in their business code, solving the problems of "coupling between decryption logic and configuration loading, and code duplication and redundancy" in traditional solutions, thus reducing maintenance costs. Furthermore, by providing a unified decryption entry point through the CyberArk decryptor, upgrades to encryption methods or decryption services only require modifications to the decryptor's internal logic, without adjusting the target application code. This aligns with the design philosophy of "unified encapsulation and reusable components" outlined in technical briefings, improving system scalability. Additionally, the decryption process is executed by a professional security service (CyberArk), and the decrypted value is directly injected into the target field, preventing plaintext exposure in business code, reducing the risk of sensitive information (such as database passwords and keys) leakage, and meeting the security compliance requirements of fields such as finance.

[0078] S140. Inject the configuration value into the target field to complete the configuration loading of the target application.

[0079] Specifically, during the `postProcessBeforeInitialization` phase of the Spring container (after bean instantiation and before the execution of initialization methods), injection is performed via `DecryptionPostProcessor`. This uses reflection to bypass access restrictions on the target field (such as the `private` modifier), overwriting the original ciphertext value with the decrypted plaintext value (e.g., injecting `decrypted-password` into the `dbPassword` field). After injection, the system verifies whether the field value is in plaintext (not in cyberark(...) format). If decryption fails (e.g., due to an API call exception) or the injected value is invalid, an exception is thrown, application startup is terminated, and logs containing the field name and the reason for the exception are output.

[0080] In other words, decryption and injection are completed during the application startup phase, and startup is terminated upon failure. This prevents sensitive information (such as database passwords) from being used by business logic, making it particularly suitable for fields with extremely high data security requirements, such as finance and healthcare, and improving system security. When the encrypted configuration in the Nacos configuration center is dynamically updated, the Spring BootStarter component automatically re-executes the "load-decrypt-injection" process, which takes effect without restarting the application. This adapts to the needs of dynamic configuration adjustment in cloud container cluster services (PKS) and improves the automation level of configuration management.

[0081] In one embodiment, injecting the decrypted configuration value into the target field to complete the configuration loading of the target application includes:

[0082] During the Spring container initialization phase, the decrypted configuration value is overwritten with the original value of the target field to complete the configuration loading of the target application.

[0083] Specifically, the automatic decryption processor (DecryptionBeanPostProcessor) executes in the early stages of Spring container startup (after BeanFactory creation). It scans all beans registered in the container and identifies "target fields" (i.e., configuration fields to be decrypted, such as database password fields) annotated with @Decrypt. For each identified target field, a dedicated decryption processing class (DecryptionPostProcessor) is dynamically registered for its associated bean, ensuring that subsequent decryption operations only apply to that bean and avoid global interference. When Spring creates an instance of the target bean, the decryption processing class (DecryptionPostProcessor) intervenes in the postProcessBeforeInitialization phase (before bean initialization), traversing all fields of that bean. For target fields marked with @Decrypt, its original value is first obtained (must conform to the cyberark(...) format, such as cyberark(db_password)), and the CyberArk decryptor is called to complete the decryption, obtaining the plaintext configuration value (such as decrypted_db_password). The decrypted plaintext value is then directly overwritten with the original ciphertext value of the target field, ensuring that after bean initialization, the target field stores the decrypted and valid configuration value. If the decryption process fails (e.g., due to incorrect original value format or CyberArk service call exception), the decryption processing class will directly throw an exception, terminating the Spring container startup and preventing the injection of invalid or erroneous values ​​into the target field.

[0084] In other words, the target field is ultimately injected with the decrypted plaintext value, not the cyberark(...) ciphertext stored in Nacos. This directly meets the actual configuration needs of the target application (e.g., database connections require plaintext passwords). Simultaneously, the abnormal termination mechanism prevents invalid ciphertext or erroneous values ​​from causing application configuration loading failures, reducing the risk of online failures. Furthermore, developers do not need to manually write code to "read the original value → call decryption → replace the field value." They only need to annotate the target field with the `@Decrypt` annotation, and the framework automatically handles the remaining operations. This perfectly aligns with the solution's advantages of "simplifying code and improving development efficiency," avoiding code redundancy caused by traditional hard-coded decryption. Additionally, the decryption and value overriding operations are completed during the Spring container initialization phase, before Bean instantiation, ensuring that the target application directly uses the decrypted value when loading configuration during startup, without additional waiting or secondary loading. Moreover, all fields annotated with `@Decrypt` follow a unified "override original value" logic, avoiding configuration chaos caused by inconsistent decryption / injection methods for different fields, conforming to the solution's design goal of "unified decryption standards."

[0085] In one embodiment, after injecting the configuration value into the target field to complete the configuration loading of the target application, the method further includes:

[0086] When the encrypted configuration in the configuration center is dynamically updated, the Spring Boot Starter component reloads the configuration information and automatically repeats the decryption and injection operations.

[0087] Specifically, the Spring Boot Starter component integrates Nacos Config's dynamic configuration listening capabilities by default. In the auto-configuration class (NacosCyberarkAutoConfiguration), listeners for the Nacos configuration groups (such as demo.yaml) subscribed to by the target application are registered via @NacosConfigListener or the ConfigService provided by Spring CloudNacos. When the encrypted configuration of the target application in the Nacos console (such as demo.dbPassword:cyberark(new-encrypted-password)) is modified or published, the Nacos server will actively push a configuration change event. Upon receiving this event, the Starter's listening component triggers the configuration reload process.

[0088] Upon receiving a configuration change event, the Starter first retrieves the latest complete configuration information from Nacos, filtering out encrypted configuration values ​​in the cyberark(...) format (the automatic identification logic is consistent with the initialization phase, based on regular expression matching). It then reuses the already instantiated CyberArk decryptor to perform decryption on the latest retrieved encrypted configuration value (the process is the same as during initialization: check the cyberark(...) format → extract the ciphertext within the brackets → call the CyberArk service to decrypt → obtain the plaintext), ensuring consistent decryption logic and eliminating the need to develop a new decryption component.

[0089] After decryption, the Starter uses the extended logic of the "DecryptionPostProcessor" class to locate the target field annotated with `@Decrypt` in the target application (such as the `dbPassword` field in the configuration class). During Spring container runtime (non-initialization phase), the latest decrypted plaintext value is directly overwritten with the old value of the target field via reflection. Simultaneously, if the target field is associated with `@ConfigurationProperties` or other configuration binding annotations, the Starter triggers the re-application of the configuration bindings, ensuring that the target application subsequently uses the updated decrypted configuration.

[0090] In other words, updating, decrypting, and injecting Nacos encrypted configurations can be completed without restarting the target application, avoiding business interruptions caused by the traditional "configuration update requires application restart" (e.g., when the database password changes, the application can connect normally without going offline using the new password), which meets the application requirements of "stateless and highly available" in cloud-native scenarios. Furthermore, the decryption (reusing the CyberArk decryptor) and injection (reusing the @Decrypt annotation to locate target fields) logic during dynamic updates is completely consistent with the application initialization phase, eliminating the need to write differentiated code separately for "dynamic update" scenarios. This reduces code redundancy and avoids decryption failures due to inconsistent logic (e.g., normal initialization decryption, abnormal dynamic update decryption), aligning with the solution's design goal of "unified and standardized encapsulation." Additionally, the dynamically updated configuration is still stored in Nacos in encrypted format (cyberark(...)), decrypted only when the Starter is reloaded, preventing sensitive information (such as the new database password) from being transmitted or stored in plaintext during the update process; simultaneously, the Starter responds in real time after configuration changes and completes decryption and injection, ensuring that the target application can use the latest configuration promptly without manual intervention, reducing business risks caused by configuration update delays.

[0091] For example, the financial sector has extremely high requirements for the security, compliance, and business continuity of sensitive configurations (such as payment keys, database passwords, and risk control interface keys). The aforementioned automatic decryption method, through a closed-loop design of "encrypted storage + automatic decryption + dynamic updates," can accurately match the needs of financial scenarios. Its core adaptability lies in: using Nacos to achieve centralized management of sensitive configurations, ensuring decryption security through the @Decrypt annotation and the CyberArk decryptor, relying on Spring BootStarter to achieve reuse of multiple financial microservices, and supporting dynamic updates to avoid business interruption. Taking the "payment core microservice" scenario as an example:

[0092] Extending financial-grade security features based on spring-boot-starter-nacos-cyberark: Adding decryption log auditing functionality to the auto-configuration class (NacosCyberarkAutoConfiguration) (complying with the financial compliance requirement of "operation traceability"), recording the time, configuration key, and operation subject (microservice name) for each decryption.

[0093] Strengthen the authentication logic of the CyberArk decryptor: Integrate with the financial institution's internal IAM (Identity Management System) to ensure that only legitimate service accounts of the core payment microservice can call the CyberArk decryption interface, preventing unauthorized access. Declare auto-configuration classes using `spring.factories` to ensure that the Starter is automatically loaded by Spring Boot, eliminating the need for manual configuration by the financial development team.

[0094] The payment core microservice subscribes to the "payment configuration group" (such as pay-core.yaml) in Nacos through the Nacos configuration loader in the Starter, and loads sensitive configuration information. The configuration information includes encrypted fields such as the third-party payment API key (wechat.pay.api-key:cyberark(wechat_pay_v3_key_2024)) and the payment transaction database password (pay.db.password:cyberark(pay_db_pwd_2024)), all of which are stored in encrypted form in cyberark(...) format (to avoid the plaintext leakage of sensitive information in Nacos).

[0095] In the configuration class (such as PayConfig) of the core payment microservice, sensitive fields are annotated with @Decrypt to enable target field identification. The Starter's "automatic decryption processor" scans the PayConfig class during the Spring container initialization phase and filters out apiKey and dbPassword annotated with @Decrypt as target fields.

[0096] The Starter uses regular expressions to verify whether the configuration value of the target field conforms to the cyberark(...) format (e.g., cyberark(wechat_pay_v3_key_2024)). If it does not conform (e.g., incorrect format or plaintext), it throws an EncryptFormatException and terminates the microservice startup (to prevent unauthorized configurations from entering the financial transaction process). After the format verification passes, it extracts the ciphertext within the parentheses (e.g., wechat_pay_v3_key_2024). It then calls the CyberArk decryptor, combines it with financial IAM authentication information, and sends a decryption request to the CyberArk key management system to obtain the plaintext (e.g., WXPay_Key_2024!@#). During the decryption process, the Starter records audit logs (e.g., "2024-05-20 14:30:00 Payment core microservice successfully decrypted wechat.pay.api-key").

[0097] During the Spring container initialization phase (before Bean instantiation), the Starter's "DecryptionPostProcessor" uses reflection to overwrite the original ciphertext value of the `apiKey` field with the decrypted plaintext (e.g., `WXPay_Key_2024!@#`) and overwrite the original value of `dbPassword` with `pay_db_pwd_clear`. After the core payment microservice starts, it directly uses the injected plaintext configuration: for example, using the decrypted `apiKey` signature when calling the WeChat Pay API and the decrypted `dbPassword` when connecting to the payment transaction database, eliminating the need for the development team to manually handle the decryption logic.

[0098] When a third-party payment institution requests an update to its API key: Operations personnel modify and publish the new encryption configuration in the Nacos console. The Starter's Nacos configuration listening component receives the configuration change event and re-fetches the latest configuration. Reusing the aforementioned "decryption-injection" logic, it automatically decrypts the new ciphertext, overwrites the old apiKey value, and records audit logs; the entire process does not require restarting the core payment microservice (avoiding financial transaction interruptions).

[0099] In other words, sensitive configurations (payment keys, database passwords) are stored in encrypted form throughout the entire process (using the cyberark(...) format in Nacos), and decrypted only during microservice runtime. The decryption process requires IAM authentication and audit logs, meeting the requirements of "minimizing the exposure of sensitive information" and "traceable operations," thus avoiding financial risks caused by configuration leaks. Furthermore, it supports dynamic updates to Nacos configurations; key changes do not require restarting the core payment microservice, resolving transaction interruptions caused by traditional "configuration update requires restart" practices and ensuring payment business continuity. Additionally, financial development teams do not need to repeatedly write decryption logic across multiple microservices such as payment, risk control, and accounts; they only need to introduce a Starter and annotate it with @Decrypt to achieve unified decryption. Simultaneously, the unified configuration format (cyberark(...)) and decryption standard reduce communication costs across teams and prevent online failures caused by inconsistent decryption logic.

[0100] For another example, the healthcare field has stringent requirements for the security, configuration stability, and service continuity of sensitive information such as patient medical records, treatment records, and drug management system configurations. The aforementioned automatic decryption method, through its design of "encrypted storage of sensitive configurations + annotation-based automatic decryption + seamless dynamic updates," is adaptable to the needs of healthcare scenarios: it utilizes Nacos for centralized management of sensitive configurations in healthcare systems, uses the @Decrypt annotation to precisely locate fields requiring decryption, relies on the CyberArk decryptor to ensure data security, and integrates with Spring Boot Starter to enable reuse across multiple healthcare applications, while also supporting dynamic updates to avoid interruptions in medical services. Taking the "Hospital Electronic Medical Record (EMR) Management System" scenario as an example:

[0101] Develop a medical-specific starter based on spring-boot-starter-nacos-cyberark. Core components include:

[0102] The auto-configuration class (NacosCyberarkAutoConfiguration) declares bean instances for the CyberArk decryptor (CyberArkDecryptor) and the auto-decryption processor (DecryptionBeanPostProcessor), ensuring that the components are automatically loaded by Spring Boot; it also adds compliance verification logic for medical data decryption (such as ensuring that decryption operations comply with the permission specifications of the Hospital Information System (HIS)).

[0103] The @Decrypt annotation is defined as follows: It maintains field-level annotation characteristics and is used to mark sensitive configuration fields that need to be decrypted in the EMR system (such as database passwords and patient data encryption keys).

[0104] Decryption Processor: Adopting the "scan-identify-process" logic, it adapts to the scanning scope of medical system configuration classes (e.g., scanning only the core configuration modules of the EMR system). An auto-configuration class is declared through the META-INF / spring.factories file, ensuring that the Starter component is automatically loaded when the EMR system starts, eliminating the need for manual configuration by the medical development team.

[0105] The EMR management system subscribes to the "EMR configuration group" (such as emr-system.yaml) in Nacos through the Starter's Nacos configuration loader, loading configuration information containing encrypted fields. Examples of encrypted configuration fields include the EMR core database password (emr.db.password:cyberark(emr_db_pwd_2024)) and the patient medical record data encryption key (emr.patient.key:cyberark(patient_encrypt_key)), both stored in the cyberark(...) format to prevent the plaintext leakage of sensitive medical configurations in Nacos.

[0106] In the configuration class of the EMR system (such as EmrConfig), sensitive fields are annotated with @Decrypt. The Starter filters and parses target fields. During the Spring container initialization phase, the Starter's automatic decryption processor scans the EmrConfig class and selects dbPassword and patientKey annotated with @Decrypt as target fields, ensuring that decryption is performed only on the marked fields.

[0107] The configuration value of the target field is validated using regular expressions to ensure it conforms to the cyberark(...) format (e.g., cyberark(emr_db_pwd_2024)). If the format is incorrect (e.g., non-encrypted format or corrupted ciphertext), an EncryptFormatException is thrown, terminating the EMR system startup (to prevent unauthorized configuration from causing patient data leakage or system malfunction). If the format validation passes, the ciphertext content within the parentheses (e.g., emr_db_pwd_2024) is extracted. The CyberArk decryptor is then invoked to send a decryption request to the CyberArk key management system deployed within the hospital, retrieving the plaintext configuration value (e.g., EMR_DB_Pwd!2024, Patient_Key#2024). The plaintext is not stored on the hard drive during the entire decryption process; it is only processed temporarily in memory, adhering to the principle of "minimal exposure" of medical data.

[0108] During the Spring container initialization phase (before Bean instantiation), the Starter's decryption processing class (DecryptionPostProcessor) uses reflection to overwrite the original ciphertext value of the target field with the decrypted plaintext value. For example, it overwrites the original value of `dbPassword` with `EMR_DB_Pwd! 2024`, and overwrites the original value of `patientKey` with `Patient_Key#2024`. After the EMR system starts, it directly uses the injected plaintext configuration. For example, when connecting to the core database to store patient medical records, it uses `patientKey` to decrypt encrypted patient treatment records without requiring the development team to manually write decryption code, avoiding security risks caused by human intervention.

[0109] When a hospital needs to update the database password of its EMR system (e.g., during a regular security upgrade, updating emr.db.password from cyberark(emr_db_pwd_2024) to cyberark(emr_db_pwd_2024_new)): Hospital operations personnel modify and publish the new encryption configuration in the Nacos console. The Starter's Nacos configuration monitoring component receives the configuration change event and automatically retrieves the latest configuration information. It reuses the "format verification - ciphertext extraction - secure decryption - value overwrite" logic, injecting the newly decrypted plaintext into the dbPassword field. The entire process does not require restarting the EMR system (avoiding the problem of electronic medical records being unavailable during treatment), ensuring continuity of medical services.

[0110] In other words, sensitive configurations such as the EMR system's database password and patient data encryption keys are stored in Nacos using cyberark(...) encryption throughout the entire process. They are decrypted only during system operation and are not stored locally, complying with the requirement that "sensitive medical data must be stored and transmitted in an encrypted manner," thus avoiding the risk of patient privacy leaks or data tampering. Furthermore, Nacos supports dynamic configuration updates, eliminating the need to restart the EMR system when sensitive configurations change (e.g., updating keys during off-hours does not affect daytime medical record entry), resolving the medical service interruption problem caused by traditional "configuration updates requiring system downtime," and ensuring the stability of core operations such as electronic medical record retrieval and medical data querying. Additionally, medical development teams do not need to repeatedly develop decryption logic across multiple medical applications such as EMR, HIS, and LIS (Laboratory Information System). They only need to introduce a Starter and annotate it with @Decrypt to achieve unified decryption. The unified configuration format and decryption standard reduce communication costs for cross-departmental collaboration (e.g., IT department, clinical departments) and avoid system failures caused by differences in decryption logic.

[0111] The aforementioned automatic decryption method for encrypted configurations in cloud container cluster services, by introducing the `@Decrypt` annotation mechanism, eliminates the need for developers to hardcode decryption logic in every configuration that requires decryption. Developers can simply add annotations to sensitive fields in the configuration class to automatically complete the decryption process. This design simplifies the development process, reduces code duplication, and improves development efficiency. The automated decryption process also reduces manual intervention, further accelerating development. Furthermore, by decoupling the decryption logic from the configuration loading process and encapsulating and reusing the decryption logic through a unified annotation mechanism and automatic configuration class, this design makes the modification and maintenance of the decryption logic more centralized and convenient, eliminating the need for manual intervention. By repeatedly modifying multiple parts, when the encryption method or decryption tool changes, only the relevant parts of the decryption logic need to be adjusted, without affecting other stages of configuration loading, thus enhancing system maintainability. Furthermore, through the cyberark(...) format convention and the @Decrypt annotation, the system can automatically identify encrypted configuration fields that need decryption, eliminating the need for manual judgment or triggering of the decryption process. This mechanism not only reduces the risk of oversights caused by human operation but also terminates application startup upon decryption failure, preventing the use of uncracked sensitive configurations and improving configuration management security. Additionally, by encapsulating the decryption logic into a reusable Spring framework... The Boot Starter component achieves the goal of "configure once, use everywhere," allowing different projects to share the same decryption logic, reducing code redundancy and improving code reusability. It also supports flexible extension and customization, allowing the addition of new encryption methods or decryption tools to meet security requirements in different scenarios. Furthermore, in cloud container cluster service scenarios, it supports dynamic configuration updates for the Nacos configuration center. When the encryption configuration changes, the system can automatically reload the configuration, perform decryption, and inject the target fields without restarting the application. This feature adapts to the need for dynamic configuration adjustments in cloud environments, ensuring that applications always use the latest decrypted configuration and improving the automation level of configuration management in cloud container clusters.

[0112] Figure 3 This is a schematic block diagram of an automatic decryption device 300 for encrypted configuration of a cloud container cluster service provided in an embodiment of the present invention. Figure 3 As shown, corresponding to the above-described automatic decryption method for encrypted configuration of cloud container cluster services, the present invention also provides an automatic decryption device 300 for encrypted configuration of cloud container cluster services. This automatic decryption device 300 includes a unit for executing the above-described automatic decryption method for encrypted configuration of cloud container cluster services, and the device can be configured in a server. Specifically, please refer to... Figure 3 The cloud container cluster service's encryption configuration automatic decryption device 300 includes:

[0113] The loading unit 301 is used to load configuration information of the target application from the configuration center, the configuration information including at least one encrypted configuration field;

[0114] The identification unit 302 is used to identify target fields in the configuration information that have the @Decrypt annotation, wherein the @Decrypt annotation is used to mark the fields that need to be decrypted;

[0115] The decryption unit 303 is used to decrypt the encrypted configuration field based on a preset decryption rule to obtain the decrypted configuration value;

[0116] Injection unit 304 is used to inject the configuration value into the target field to complete the configuration loading of the target application.

[0117] In one embodiment, the loading unit 301 includes:

[0118] A module is established to connect to the configuration center via a Spring Boot Starter component, which includes a configuration loader;

[0119] The acquisition module is used to acquire the configuration information of the target application from the configuration center based on the configuration loader.

[0120] In one embodiment, the identification unit 302 includes:

[0121] The scanning module is used to scan the configuration classes of the target application;

[0122] The parsing and filtering module is used to parse the fields of the configuration class and filter out the fields annotated with @Decrypt as target fields.

[0123] In one embodiment, the decryption unit 303 includes:

[0124] The matching module is used to match whether the encrypted configuration field conforms to a preset format using regular expressions; if it does not conform, a format exception is thrown.

[0125] An extraction module is used to extract the ciphertext content from the encrypted configuration field if the conditions are met.

[0126] The decryption module is invoked to call the decryptor to decrypt the ciphertext content and obtain the decrypted configuration value.

[0127] In one embodiment, the injection unit 304 includes:

[0128] During the Spring container initialization phase, the decrypted configuration value is overwritten with the original value of the target field to complete the configuration loading of the target application.

[0129] In one embodiment, the device further includes:

[0130] A building unit is used to pre-build the Spring Boot Starter component, which includes an auto-configuration class, a @Decrypt annotation definition, a decryptor, and a decryption handler;

[0131] The auto-configuration class declares instances of the decryptor and the decryption processor, which are automatically scanned and loaded by Spring Boot through a specified format file.

[0132] In one embodiment, the device further includes:

[0133] The loading unit is used to reload the configuration information of the Spring Boot Starter component and automatically repeat the decryption and injection operations when the encrypted configuration of the configuration center is dynamically updated.

[0134] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned cloud container cluster service encryption configuration automatic decryption device 300 and each unit can be referred to the corresponding description in the foregoing method embodiments. For the sake of convenience and brevity, it will not be repeated here.

[0135] The aforementioned cloud container cluster service's encryption configuration automatic decryption device 300 can be implemented as a computer program, which can, for example... Figure 4 It runs on the computer device shown.

[0136] Please see Figure 4 , Figure 4 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0137] See Figure 4 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0138] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform an automatic decryption method for an encrypted configuration of a cloud container cluster service.

[0139] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0140] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an automatic decryption method for the encrypted configuration of a cloud container cluster service.

[0141] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0142] The processor 502 is used to run a computer program 5032 stored in the memory to perform the following steps:

[0143] The configuration information of the target application is loaded from the configuration center. The configuration information contains at least one encrypted configuration field. The target field with the @Decrypt annotation in the configuration information is identified. The @Decrypt annotation is used to mark the field that needs to be decrypted. The encrypted configuration field is decrypted based on a preset decryption rule to obtain the decrypted configuration value. The configuration value is injected into the target field to complete the configuration loading of the target application.

[0144] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0145] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0146] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein when executed by a processor, the computer program causes the processor to perform the following steps:

[0147] The configuration information of the target application is loaded from the configuration center. The configuration information contains at least one encrypted configuration field. The target field with the @Decrypt annotation in the configuration information is identified. The @Decrypt annotation is used to mark the field that needs to be decrypted. The encrypted configuration field is decrypted based on a preset decryption rule to obtain the decrypted configuration value. The configuration value is injected into the target field to complete the configuration loading of the target application.

[0148] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0149] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0150] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0151] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0152] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0153] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / dependency>

Claims

1. An automatic decryption method for encrypted configurations of cloud container cluster services, characterized in that, include: Load the configuration information of the target application from the configuration center, the configuration information containing at least one encrypted configuration field; Identify the target fields in the configuration information that are annotated with @Decrypt, whereby the @Decrypt annotation is used to mark the fields that need to be decrypted; The encrypted configuration field is decrypted based on a preset decryption rule to obtain the decrypted configuration value; The configuration value is injected into the target field to complete the configuration loading of the target application.

2. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, The process of loading the configuration information of the target application from the configuration center includes: A connection is established with the configuration center through the Spring Boot Starter component, which contains a configuration loader; The configuration loader obtains the configuration information of the target application from the configuration center.

3. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, The identification of target fields annotated with @Decrypt in the configuration information includes: Scan the configuration classes of the target application; Parse the fields of the configuration class and filter out the fields annotated with @Decrypt as the target fields.

4. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, The step of decrypting the encrypted configuration field based on a preset decryption rule to obtain the decrypted configuration value includes: The encrypted configuration field is matched using a regular expression to determine if it conforms to a preset format; if it does not conform, a format exception is thrown. If the conditions are met, the ciphertext content in the encryption configuration field is extracted; The decryptor is invoked to decrypt the ciphertext content to obtain the decrypted configuration value.

5. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, The step of injecting the decrypted configuration value into the target field to complete the configuration loading of the target application includes: During the Spring container initialization phase, the decrypted configuration value is overwritten with the original value of the target field to complete the configuration loading of the target application.

6. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, Before loading the configuration information of the target application from the configuration center, the process also includes: The Spring Boot Starter component is pre-built, and the Spring Boot Starter component includes an auto-configuration class, a @Decrypt annotation definition, a decryptor, and a decryption handler; The auto-configuration class declares instances of the decryptor and the decryption processor, which are automatically scanned and loaded by Spring Boot through a specified format file.

7. The automatic decryption method for encrypted configuration of cloud container cluster services according to claim 1, characterized in that, After injecting the configuration value into the target field to complete the configuration loading of the target application, the method further includes: When the encrypted configuration in the configuration center is dynamically updated, the Spring Boot Starter component reloads the configuration information and automatically repeats the decryption and injection operations.

8. An automatic decryption device for encrypted configuration of cloud container cluster services, characterized in that, include: A loading unit is used to load configuration information of a target application from a configuration center, the configuration information containing at least one encrypted configuration field; The identification unit is used to identify target fields in the configuration information that are annotated with @Decrypt, whereby the @Decrypt annotation is used to mark fields that need to be decrypted; The decryption unit is used to decrypt the encrypted configuration field based on a preset decryption rule to obtain the decrypted configuration value. An injection unit is used to inject the configuration value into the target field to complete the configuration loading of the target application.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images