A storage volume data encryption method and system in a K8s cloud-native environment

Abstract

The application relates to the technical field of data encryption, and provides a K8s cloud native environment storage volume data encryption method and system, which comprises the following steps: driving a storage volume interaction module on a processing unit to store an updated encapsulation key and updated data operation key encapsulation ciphertext after the updated encapsulation key and the updated data operation key encapsulation ciphertext are received, and meanwhile, historical version encapsulation keys and corresponding data operation key encapsulation ciphertexts are reserved; when an application component requests to access a storage volume, a corresponding data operation key is obtained according to a currently available encapsulation key in a storage library; the storage volume interaction module is driven to use the obtained data operation key to perform encryption and decryption operations on data in the storage volume, and during the switching process of the encapsulation key and the data operation key encapsulation ciphertext, the continuous access of the application component to the storage volume is maintained. The application has the effects of improving the flexibility and security of data encryption.

Description

Technical Field

[0001] This invention relates to the technical field of data encryption, specifically to a method and system for encrypting storage volume data in a K8s cloud-native environment. Background Technology

[0002] In a Kubernetes (K8s) cloud-native environment, with the dynamic scaling of application components and the frequent mounting and unmounting of storage volumes, traditional encryption key distribution and management methods face the risks of inefficiency and key leakage. Existing solutions rely excessively on centralized key management services, making it difficult to adapt to the rapid scheduling characteristics of containers. This limitation becomes particularly pronounced when dealing with scenarios where highly sensitive data requires frequent updates to encryption keys. For example, on a private cloud platform within a large enterprise, built on Kubernetes, hosting critical applications from multiple business units, all sensitive data in persistent storage volumes must be encrypted. The platform's core key management service is responsible for the lifecycle management of these keys, including generation, storage, distribution, and destruction. When an application container starts and needs to access its storage volume, it requests the corresponding decryption key from the key management service through the K8s storage interface. After verifying the legitimacy of the request, the key management service securely transmits the key to the worker node running the container. The storage driver on the node uses this key to decrypt and mount the storage volume.

[0003] However, as enterprises increasingly demand higher data security compliance, such as requiring more frequent updates to encryption keys for storage volumes containing highly sensitive data like customer personal information and core transaction records (specifically, changing from monthly updates to 24-hour updates), and necessitating immediate key replacement in any suspected case of key leakage, existing key management mechanisms face significant challenges. While existing centralized key management service systems are designed with secure key storage and on-demand distribution in mind, they primarily focus on providing keys for newly launched containers and handling a small number of non-urgent key replacement requests. They are not optimized for batch, synchronous key updates to a large number of active storage volumes within a short period.

[0004] Problems arise when the platform attempts to perform high-frequency key updates. To replace the encryption key for a storage volume, the key management service first needs to generate a new key. Subsequently, all application containers currently accessing that storage volume using the old key theoretically need to stop running, unmount the storage volume, obtain the new key, remount the storage volume, and restart. Even with automation through Kubernetes' rolling update mechanism, this process means that related application services will experience a brief period of unavailability during the key update. For financial trading or customer service applications with extremely high real-time requirements, even a few seconds of downtime can lead to a degraded user experience or even business losses. Further complicating matters, the dynamic scaling characteristics of Kubernetes clusters conflict with the key update process. If the key update process has not fully propagated to all distribution points of the key management service, or if the key management service experiences delays when handling a large number of update requests, newly created containers may incorrectly obtain the old encryption key, causing application startup failures or abnormal data access. Conversely, if an old, running container fails to receive the new key in a timely manner, it may continue to operate using the expired old key, theoretically creating a security vulnerability until the container is forcibly restarted.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] This application discloses a storage volume data encryption method and system in a K8s cloud-native environment. It aims to solve the problems of low efficiency, high risk of key leakage, and difficulty in adapting to the rapid scheduling characteristics of containers when application components are dynamically scaled and storage volumes are frequently mounted and unmounted in a K8s cloud-native environment. In particular, when facing scenarios where highly sensitive data requires frequent updates of encryption keys, existing centralized key management service systems cannot effectively support high-frequency, batch, and synchronous key updates, resulting in service interruptions, abnormal data access, or security vulnerabilities.

[0007] The technical solution of this application is as follows: In a first aspect, this application discloses a method for encrypting storage volume data in a K8s cloud-native environment, used to execute in a cloud-native environment where application components expand and storage volumes periodically connect and disconnect, including: Configure the data manipulation key used for data encryption and decryption, and configure the encapsulation key used to encapsulate the data manipulation key to establish a hierarchical key structure; When the hierarchical key structure needs to update the key, the encapsulation key is updated to obtain the updated encapsulation key, and the data operation key is re-encapsulated using the updated encapsulation key to obtain the updated data operation key encapsulated ciphertext. Transmit the updated encapsulation key and the updated data manipulation key to encapsulate ciphertext into one or more processing units in a cloud-native environment; Upon receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the encapsulation key and the corresponding data operation key encapsulated ciphertext of the previous version, in order to build a repository of encapsulation keys and the corresponding data operation key encapsulated ciphertext; when an application component requests access to the storage volume, it decapsulates the corresponding data operation key encapsulated ciphertext based on the currently available encapsulation key in the repository to obtain the corresponding data operation key; The storage volume interaction module is driven to use the data operation key obtained from decapsulation to encrypt and decrypt the data in the storage volume, and to maintain continuous access to the storage volume by application components during the switching between the encapsulation key and the data operation key encapsulated ciphertext.

[0008] This technical solution establishes a hierarchical key structure and supports dynamic updates of encapsulated keys and re-encapsulation of data operation keys, achieving flexible key management and secure updates. Simultaneously, by storing multiple versions of key information locally in the processing unit and intelligently switching between them, it ensures continuous access to the storage volume by application components during key updates. This effectively solves the problems of service interruption and data access anomalies caused by frequent key updates in cloud-native environments, significantly improving the flexibility, security, and business continuity of data encryption.

[0009] Secondly, this application also discloses a storage volume data encryption system for a K8s cloud-native environment, used to perform storage volume data encryption in a K8s cloud-native environment, including: The key structure establishment module is used to configure the data operation keys used for data encryption and decryption, and to configure the encapsulation keys used to encapsulate the data operation keys, so as to establish a hierarchical key structure. The encapsulation key update module is used to update the encapsulation key when the hierarchical key structure needs to be updated, obtain the updated encapsulation key, and use the updated encapsulation key to re-encapsulate the data operation key to obtain the updated data operation key encapsulated ciphertext. The key-ciphertext transmission module is used to transmit the updated encapsulation key and the updated data operation key encapsulated ciphertext to one or more processing units in the cloud-native environment. The data operation key module is used to drive the storage volume interaction module on the processing unit to store the updated encapsulation key and the updated data operation key encapsulated ciphertext after receiving them. At the same time, it retains the encapsulation key and the corresponding data operation key encapsulated ciphertext of the previous version to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertexts. When the application component requests access to the storage volume, it decapsulates the corresponding data operation key encapsulated ciphertext according to the currently available encapsulation key in the repository to obtain the corresponding data operation key. The encryption / decryption interaction module is used to drive the storage volume interaction module to use the data operation key obtained from decapsulation to perform encryption and decryption operations on the data in the storage volume, and to maintain continuous access to the storage volume by the application components during the switching between the encapsulation key and the data operation key encapsulated ciphertext.

[0010] This technical solution, through modular design, automates and intelligently encrypts storage volume data in a Kubernetes cloud-native environment. Modules such as key structure establishment, encapsulation key updates, key ciphertext transmission, data operation key management, and encryption / decryption interaction work collaboratively to ensure secure key lifecycle management and seamless integration of the data encryption / decryption process. This effectively solves the problems of complex key management and difficult updates in cloud-native environments, improving the overall security and operational efficiency of the system.

[0011] Beneficial Effects: The storage volume data encryption method disclosed in this application for a K8s cloud-native environment achieves flexibility and security in key management by establishing a hierarchical key structure, separating the data operation key from the encapsulation key, and allowing the encapsulation key to be updated independently. During the key update process, this method re-encapsulates the data operation key and transmits it along with the updated encapsulation key to the processing unit. The storage volume interaction module on the processing unit can intelligently store multiple versions of the encapsulation key and the data operation key encapsulated ciphertext, building a local repository. When an application component requests access to the storage volume, this module can decapsulate it based on the currently available key information in the repository to obtain the data operation key. More importantly, this method can maintain continuous access to the storage volume by the application component during the switching between the encapsulation key and the data operation key encapsulated ciphertext, avoiding the service interruption problem common in traditional key update mechanisms.

[0012] Compared with existing technologies, the solution of this application has significantly superior technical effects: First, this application effectively solves the problems of inefficiency and service interruption in existing centralized key management services when faced with high-frequency key updates by using a hierarchical key structure and local multi-version key storage. In existing technologies, frequent key updates often require application containers to stop, unload storage volumes, obtain new keys, and restart, resulting in business unavailability. This application, however, ensures that application components can continuously access storage volumes during key updates by caching historical version keys locally in the processing unit and intelligently switching between them, thereby improving business continuity.

[0013] Secondly, this application reduces reliance on centralized key management services by storing and managing keys locally within the processing unit, thus alleviating their load pressure in high-concurrency key update scenarios. In existing solutions, the key management service needs to handle a large number of real-time key requests, which can easily become a performance bottleneck. This application decentralizes some key management logic to the processing unit, improving the efficiency of key distribution and updates.

[0014] Furthermore, this application constructs a key repository by preserving the ciphertext encapsulation keys and corresponding data operation keys of historical versions, enabling key rollback and fault recovery and enhancing the system's robustness. In the event of an anomaly during the key update process, the system can quickly revert to a usable historical key version, avoiding the risk of data access interruption or data loss.

[0015] In summary, the storage volume data encryption method in the K8s cloud-native environment proposed in this application effectively overcomes the efficiency, security, and business continuity challenges faced by existing technologies in the context of frequent key updates in cloud-native environments through innovative hierarchical key management, local multi-version key storage, and seamless switching mechanisms. It provides a more efficient, secure, and stable solution for sensitive data encryption in the K8s cloud-native environment. Attached Figure Description

[0016] Figure 1 This is a flowchart of a method for encrypting storage volume data in a K8s cloud-native environment, as described in one embodiment of the present invention. Figure 2 This is a flowchart of a method for encrypting storage volume data in a K8s cloud-native environment, according to another embodiment of the present invention. Figure 3 This is a system block diagram of a storage volume data encryption system in a K8s cloud-native environment according to another embodiment of the present invention; Explanation of reference numerals in the attached figures: 1. Storage volume data encryption system in K8s cloud-native environment; 11. Key structure establishment module; 12. Encapsulation key update module; 13. Key ciphertext transmission module; 14. Data operation key module; 15. Encryption and decryption interaction module. Detailed Implementation

[0017] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] This application proposes a storage volume data encryption method for a Kubernetes cloud-native environment, designed for execution in cloud-native environments where application components expand and storage volumes periodically connect and disconnect. Figure 1 As shown, it includes: S1, Configure the data operation key for data encryption and decryption, and configure the encapsulation key for encapsulating the data operation key to establish a hierarchical key structure; S2, when the hierarchical key structure needs to update the key, update the encapsulation key to obtain the updated encapsulation key, and use the updated encapsulation key to re-encapsulate the data operation key to obtain the updated data operation key encapsulated ciphertext. S3, transmit the updated encapsulation key and the updated data operation key to encapsulate ciphertext to one or more processing units in the cloud-native environment; S4, after receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the historical versions of the encapsulation key and the corresponding data operation key encapsulated ciphertext, to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertexts; when the application component requests access to the storage volume, it decapsulates the corresponding data operation key encapsulated ciphertext according to the currently available encapsulation key in the repository to obtain the corresponding data operation key; S5 drives the storage volume interaction module to use the data operation key obtained from decapsulation to perform encryption and decryption operations on the data in the storage volume, and maintains the application component's continuous access to the storage volume during the switching process between the encapsulation key and the data operation key encapsulated ciphertext.

[0020] To facilitate understanding of the technical solution of this application, the key terms and implementation environment involved in the text will be explained in a unified manner first.

[0021] "Kubernetes cloud-native environment" refers to a distributed computing environment built on Kubernetes, used to support the deployment, orchestration, and operation management of containerized applications. In this environment, application components have dynamic scaling capabilities, and the storage volumes used in conjunction with application components will also undergo state switching such as mounting, unmounting, reattaching, or changes in access subjects during scheduling, migration, reconstruction, or fault recovery processes. Therefore, the data protection mechanism of storage volumes not only needs to meet encryption requirements, but also needs to adapt to node changes, component migration, and access continuity requirements.

[0022] "Data manipulation key" refers to the key that directly participates in the encryption and decryption of data on the storage volume. This key is used to perform encrypted writing and decrypted reading of the actual data in the storage volume, and is usually implemented using a high-entropy symmetric key to meet the processing efficiency and security strength requirements of large-scale data read and write scenarios.

[0023] A "sealing key" is a key used to encapsulate and protect data manipulation keys. By encrypting or encapsulating the data manipulation key with a sealing key, a "data manipulation key ciphertext" can be created, ensuring that the data manipulation key is not exposed in plaintext during storage, synchronization, and distribution. Even if the data manipulation key ciphertext is intercepted, without the corresponding sealing key, it is impossible to recover the data manipulation key that can actually be used for data processing.

[0024] A "layered key structure" refers to a key organization method in which the data operation keys that directly participate in data encryption and decryption are set up in layers and managed separately from the encapsulation keys used to protect the data operation keys. With this structure, updates, replacements, and synchronization can be performed only on the upper-layer encapsulation keys without changing the underlying data operation keys. This decouples key update actions from business data encryption and decryption actions, reducing the impact of key rotation on business continuity.

[0025] A "processing unit" refers to a node entity in a Kubernetes cloud-native environment that hosts application components and interacts with storage volumes. It typically corresponds to a worker node. The processing unit is equipped with control logic related to the storage volume access process, which is used to perform key acquisition, key switching, and data encryption / decryption processing when application components access the storage volume.

[0026] The "Storage Volume Interaction Module" refers to a software module deployed on the processing unit, used to manage key-related operations and volume-side collaborative processing during storage volume access. This module participates in receiving, storing, and maintaining versions of updated encapsulation keys and data operation key encapsulated ciphertexts, as well as in the decapsulation, key loading, and encryption / decryption process coordination when application components access the storage volume.

[0027] The "repository" refers to a key storage area maintained locally by the processing unit, used to store different versions of encapsulation keys and the corresponding data operation keys encapsulated in ciphertext. This storage area is used not only to record the key material of the currently effective version, but also to retain historical version data to support version compatibility, smooth transition, and anomaly rollback handling during key switching.

[0028] "Application components" refer to containerized applications deployed in a Kubernetes cloud-native environment. Application components achieve persistent data read and write by mounting or accessing storage volumes, and their ability to continuously access storage volumes directly affects the stability of business operations.

[0029] Based on the above terminology definitions, this application proposes a storage volume data encryption method suitable for Kubernetes cloud-native environments. This method revolves around a processing chain of "layered key establishment—encapsulation key update—update information distribution—local version storage—on-demand decapsulation—smooth volume-side switching," focusing on addressing the problems of existing solutions easily leading to access interruptions, uneven key switching, or insufficient seamless business switching capabilities in scenarios involving high-frequency encapsulation key updates, dynamic node changes, and switching of storage volume access subjects.

[0030] During the hierarchical key structure establishment phase, the data operation key used for encrypting and decrypting data in the storage volume is first configured, along with a sealing key used to protect this data operation key, thus forming a hierarchical key structure. The data operation key can be an Advanced Encryption Standard (AES) key, used to encrypt and decrypt the actual data in the storage volume. The sealing key can be a sealing side key in an asymmetric key system or a master key generated by a key management service. For example, the AES data operation key can be sealed with the public key of an RSA key pair, and desealed using the corresponding private key; alternatively, a master key can be generated by KMS, and this master key can be used to encrypt or perform derivative sealing of the data operation key. Regardless of the implementation method, the data operation key is not directly exposed in the distribution and local persistence links, but rather participates in subsequent synchronization and invocation in the form of a data operation key-encapsulated ciphertext.

[0031] During the key update phase, when a preset update cycle is reached or a potential security risk is detected, the encapsulation key is updated to obtain the updated encapsulation key. The original data operation key is then re-encapsulated using the updated encapsulation key to generate the updated data operation key-encapsulated ciphertext. This processing method separates the encapsulation key update from the data operation key itself, preferably keeping the data operation key unchanged and only adjusting its outer protection form. This avoids large-scale data re-encryption processing caused by replacing the entire underlying data encryption / decryption key, reducing disruption to online business access paths.

[0032] During the update information distribution phase, the updated encapsulation key and the updated data operation key encapsulated in ciphertext are transmitted to one or more processing units in the cloud-native environment. This transmission process can be initiated by the key management service through a secure communication channel to each processing unit, or by the storage volume interaction module on the processing unit actively polling the key management service at a preset period to obtain the latest version information. Regardless of whether the push or polling method is used, the processing unit obtains matching sets of encapsulation key version information and data operation key encapsulated in ciphertext version information to ensure that the version matching relationship is clear during subsequent local decapsulation.

[0033] During the local version storage phase, the storage volume interaction module on the processing unit, upon receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, performs local storage on the received content and retains the encapsulation keys and their corresponding data operation key encapsulated ciphertexts for previous versions, thereby constructing a local repository for encapsulation keys and data operation key encapsulated ciphertexts. The storage volume interaction module can write different versions of key materials to the local file system, lightweight database, or other persistent media, and establish version identifiers, status identifiers, and corresponding relationship indexes to distinguish between currently effective versions, versions to be switched, and historical rollback versions. In this way, during subsequent storage volume access, different versions of key materials can be retrieved and called according to unified rules, without causing mismatches in the original access paths due to updates overwriting existing ones.

[0034] During the on-demand decapsulation phase, when an application component requests access to the target storage volume, the storage volume interaction module decapsulates the corresponding data operation key ciphertext from the currently available encapsulation keys in the repository to obtain the target data operation key. Specifically, the storage volume interaction module can first read the target storage volume's volume metadata, version identifier, or associated policy information to determine the key version that should be used for the current access, then extract the encapsulation key and data operation key ciphertext corresponding to that version from the local repository, and complete the decapsulation process. For example, when application component A requests access to storage volume X, and the currently associated valid version identifier of storage volume X is V2, the storage volume interaction module extracts the V2 version encapsulation key and the V2 version data operation key ciphertext from the repository, and after decapsulation, obtains the data operation key that matches the current access status of the storage volume.

[0035] During the data encryption / decryption and smooth switching phase, the storage volume interaction module uses the data operation key obtained from decapsulation to perform encrypted writing and decryption reading of data in the storage volume. It maintains continuous access to the storage volume by application components during version switching of the encapsulation key and the ciphertext encapsulated by the data operation key. After obtaining the data operation key, the storage volume interaction module can load the key into the memory-based key usage environment and cooperate with the underlying block device encryption module or file system encryption module to perform real-time encryption and decryption processing on the read / write path. During version switching, the storage volume interaction module can retain the short-term availability of the old version key while simultaneously loading, verifying, and enabling the new version key material, ensuring controlled overlap between the old and new versions within the switching window. Once the new version key has been synchronized and meets the usage conditions, the access path is smoothly switched to the new version key, thus avoiding interruption of ongoing volume access requests due to a single point of failure to cut off the old version key. This ensures that application components maintain continuous access to the storage volume before and after key switching.

[0036] Optional, combined Figure 2 As shown, after receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the historical versions of the encapsulation key and the corresponding data operation key encapsulated ciphertext, to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertexts. When an application component requests access to the storage volume, the steps of decapsulating the corresponding data operation key encapsulated ciphertext based on the currently available encapsulation key in the repository to obtain the corresponding data operation key include: A1, when the storage volume interaction module on the driving processing unit receives the updated encapsulation key, it writes the updated encapsulation key into the protected memory; when the driving processing unit receives the updated data operation key encapsulated ciphertext, it stores the updated data operation key encapsulated ciphertext, while retaining the historical version of the encapsulation key and the corresponding data operation key encapsulated ciphertext, so as to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertext. A2, the storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized and obtain the synchronization detection result; A3. When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has not been synchronized, use the encapsulation key of the historical version in the repository to decapsulate the corresponding version of the data operation key encapsulated ciphertext to obtain the currently available data operation key. A4, writes the currently available data operation key to the volume key memory slot associated with the storage volume; A5. When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has been synchronized, the updated encapsulation key in the protected memory is used to decapsulate the updated data operation key encapsulated ciphertext to obtain the latest data operation key. A6, uses atomic write to replace the latest data operation key with the volume key memory slot; A7 is used by the block device encryption module to read the latest data operation key from the volume key memory slot via a pre-registered handle.

[0037] Specifically, writing the updated encapsulation key into protected memory means storing the updated encapsulation key in a memory area with security protection capabilities. This protected memory is used to restrict unauthorized access, reading, and tampering, and can be implemented through hardware-level security mechanisms, operating system-level access control mechanisms, memory encryption mechanisms, or isolated execution environments. Since the encapsulation key is used to decapsulate the ciphertext encapsulated by the data operation key, and is directly related to whether the data operation key can be correctly recovered, writing the updated encapsulation key into protected memory helps maintain the confidentiality and integrity of the encapsulation key during storage and retrieval, and reduces the risk of the key being exposed locally on the processing unit.

[0038] The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This means that the storage volume interaction module performs continuous checks on the version identifier, annotation information, tag information, or custom resource status information corresponding to the target storage volume to determine whether the updated data operation key encapsulated ciphertext has reached a usable state and is consistent with the current access state of the storage volume. This synchronization detection process corresponds to the status confirmation process before key switching. It does not detect the existence of a single ciphertext, but rather whether the updated data operation key encapsulated ciphertext, associated version information, and the current access relationship of the storage volume have met the consistency conditions. Only when all relevant key components are in place and the corresponding relationships are clear can subsequent decapsulation and switching processes be executed.

[0039] When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has not yet been synchronized, the corresponding version of the data operation key encapsulated ciphertext is decapsulated using the historical version of the encapsulation key in the repository to obtain the currently usable data operation key. This process maintains the existing access path during the transition phase when the new version of the key material has not yet been synchronized, avoiding data operation key recovery failure, volume-side encryption / decryption link interruption, or application component access anomalies due to premature switching to the new version of the key that has not been synchronized. In other words, when the synchronization detection result does not meet the switching conditions, the processing unit does not directly enable the updated encapsulation key to participate in volume-side access, but continues to use the historical version of the key material that matches the current volume status to ensure the continuity of the storage volume access process.

[0040] Furthermore, writing the currently available data operation key into the volume key memory slot associated with the storage volume means establishing a corresponding key residing location for each storage volume and writing the data operation key currently used for data encryption and decryption on that storage volume into the dedicated memory area corresponding to that storage volume. The volume key memory slot provides a stable, fast, and controlled key reading entry point for the block device encryption module, allowing the block device encryption module to obtain the currently effective data operation key without repeatedly executing the decapsulation process. The volume key memory slot is associated with a specific storage volume to ensure that key calls from different storage volumes are independent in parallel access scenarios, avoiding misuse between volumes.

[0041] When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has been synchronized, the updated encapsulated key in protected memory is used to decapsulate the updated data operation key encapsulated ciphertext, obtaining the latest data operation key. At this point, the updated encapsulated key has been stored locally under protection, and the updated data operation key encapsulated ciphertext has met the synchronization completion conditions. Therefore, given a clear version matching relationship, the latest data operation key can be recovered and used as the target key for subsequent volume-side encryption and decryption.

[0042] The atomic write method replaces the latest data operation key with the volume key memory slot. This refers to using an indivisible write-replacement mechanism to switch the state between the old and new keys when updating the key content in the volume key memory slot. During this write process, the key state in the volume key memory slot remains constant; it either remains the historical key before the switch or is directly updated to the latest key after the switch, preventing partial overwriting of key content, read-write interleaving, or exposure of intermediate states. This method ensures consistency between the key replacement action and the read action of the block device encryption module, reducing the risk of data access anomalies caused by incomplete slot states at the moment of switchover.

[0043] The block device encryption module reads the latest data operation key from the volume key memory slot via a pre-registered handle. This means that the block device encryption module pre-establishes a trusted access relationship with the volume key memory slot and directly reads the data operation key in the currently written slot based on this access relationship. This key is used to perform encrypted writing and decryption reading of stored volume data. The pre-registered handle is used to limit the key reading path, reduce the exposure surface introduced by repeated key transmission between modules, and enable the block device encryption module to continuously obtain the currently effective volume-side key without being aware of the upper-layer key synchronization and switching details.

[0044] In some preferred embodiments, it is assumed that the key management service unit in the Kubernetes cluster performs a key update for a specific storage volume. First, the key management service unit generates an updated encapsulation key and uses this updated encapsulation key to re-encapsulate the target data operation key, forming an updated data operation key encapsulated ciphertext. Then, the updated encapsulation key and the updated data operation key encapsulated ciphertext are transmitted to the target processing unit. Upon receiving the update information, the storage volume interaction module on the processing unit writes the updated encapsulation key to protected memory, writes the updated data operation key encapsulated ciphertext and its version information to the local repository, and continues to retain historical versions of the encapsulation key and their corresponding data operation key encapsulated ciphertext. Subsequently, the storage volume interaction module continuously monitors the metadata associated with the target storage volume to determine whether the updated data operation key encapsulated ciphertext has been synchronized in the current cluster environment.

[0045] When the detection result indicates that the updated data operation key encapsulated ciphertext has not yet been synchronized, the storage volume interaction module retrieves the historical version encapsulation key and the corresponding historical version data operation key encapsulated ciphertext that match the current volume state from the local repository, performs decapsulation processing to obtain the currently usable data operation key, and writes this currently usable data operation key into the volume key memory slot corresponding to the target storage volume. At this time, the block device encryption module continues to read the currently usable data operation key from the volume key memory slot through a pre-registered handle, and maintains data encryption and decryption operations on the target storage volume based on this key, thereby ensuring that the application components' continuous access to the storage volume is not affected.

[0046] When the detection result indicates that the updated data operation key encapsulated ciphertext has been synchronized, the storage volume interaction module calls the updated encapsulated key in the protected memory to perform decapsulation processing on the updated data operation key encapsulated ciphertext, obtaining the latest data operation key. Subsequently, the latest data operation key is atomically written to the corresponding volume key memory slot of the target storage volume. Because this replacement process uses an atomic write mechanism, the key state in the volume key memory slot remains clear and consistent during the switching process. Therefore, the block device encryption module can always obtain complete and valid key content when reading this slot. After the replacement is completed, the block device encryption module reads and uses the latest data operation key through a pre-registered handle to perform encrypted writing and decryption reading on the data in the target storage volume. The entire switching process occurs between the storage volume interaction module, protected memory, storage repository, volume key memory slot, and block device encryption module. Application components do not need to be aware of the key version change, thus ensuring that the key update process is coordinated with the business access process.

[0047] Optionally, the storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The key management service unit encapsulates the data operation key into ciphertext, the identifier of the encapsulated key, and the timestamp into a data packet; The key management service unit uses a private key to digitally sign data packets, forming key metadata credentials; The key management service unit writes the key metadata credentials into the metadata annotation of the storage volume; The storage volume interaction module obtains key metadata credentials; The storage volume interaction module uses a public key to verify the digital signature of the key metadata credential; When the digital signature verification is valid, the storage volume interaction module extracts the data operation key encapsulated ciphertext and the identifier of the encapsulated key from the key metadata certificate; it compares the identifier of the encapsulated key with the target updated version recorded locally; if the comparison result meets the target updated version, it is determined that the updated data operation key encapsulated ciphertext has been synchronized; otherwise, it is determined that the updated data operation key encapsulated ciphertext has not been synchronized. The storage volume interaction module obtains the encapsulation key based on the identifier of the encapsulation key; The storage volume interaction module uses the encapsulation key to decapsulate the ciphertext encapsulated by the data operation key, and obtains the data operation key. The storage volume interaction module uses data manipulation keys to configure the block device encryption module; When the digital signature verification is invalid, the storage volume interaction module rejects the key metadata credentials.

[0048] Specifically, the key management service unit refers to the central service responsible for generating, storing, distributing, and managing encryption keys. It integrates key information such as the data manipulation key encapsulated ciphertext, the identifier of the encapsulated key, and the timestamp into a single data packet to ensure the atomicity and integrity of this information during transmission and storage. The data manipulation key encapsulated ciphertext is the actual key used for data encryption and decryption, the identifier of the encapsulated key uniquely identifies the currently used version of the encapsulated key, and the timestamp records the generation time of the key metadata credential to determine its validity.

[0049] Furthermore, the key management service unit digitally signs the data packet using its private key. A digital signature is a cryptographic technique used to verify the authenticity of the data source, the integrity of the data, and to prevent repudiation. Signing with the private key ensures that the data packet was indeed generated by the key management service unit and has not been tampered with during transmission. The signed data packet, together with the signature itself, constitutes the key metadata credential.

[0050] The key metadata credentials are then written to the storage volume's metadata annotations. In a Kubernetes cloud-native environment, metadata annotations are key-value pairs on Kubernetes objects (such as PersistentVolume or PersistentVolumeClaim) used to store unstructured, user-defined metadata. Storing key metadata credentials in metadata annotations allows key information to be tightly associated with the storage volume and managed and synchronized throughout the storage volume's lifecycle.

[0051] When the storage volume interaction module needs to check the key synchronization status, it will actively or passively obtain the key metadata credential from the storage volume's metadata annotation. After obtaining it, the storage volume interaction module uses the public key corresponding to the key management service unit to verify the digital signature of the key metadata credential. The public key and private key are paired; the public key can be published and used to verify information signed by the corresponding private key. If the digital signature verification is valid, it indicates that the source of the key metadata credential is trustworthy and its content has not been tampered with.

[0052] When the digital signature verification is valid, the storage volume interaction module securely extracts the data manipulation key encapsulated ciphertext and the identifier of the encapsulation key from the key metadata certificate. Then, it compares the extracted encapsulation key identifier with the target updated version recorded locally. This comparison aims to confirm whether the currently obtained key metadata is the latest version expected by the system. If the comparison result matches the target updated version, it is determined that the updated data manipulation key encapsulated ciphertext has been synchronized; otherwise, if the versions do not match, it is considered that the update has not yet been synchronized, and it may be necessary to wait or take other processing measures.

[0053] After synchronization is complete, the storage volume interaction module retrieves the corresponding encapsulation key from the local repository based on the identifier of the encapsulation key. Next, it uses this encapsulation key to decapsulate the ciphertext containing the data manipulation key extracted from the key metadata credential, thus obtaining the actual data manipulation key used for data encryption and decryption. Finally, the storage volume interaction module uses the decapsulated data manipulation key to configure the block device encryption module, enabling it to perform transparent encryption and decryption operations on the data in the storage volume.

[0054] As a specific implementation, when digital signature verification is invalid, the storage volume interaction module will reject the key metadata credential. This means that the credential is considered untrusted or has been tampered with, and the system will not use the key information contained therein, thereby effectively preventing potential security threats.

[0055] Optionally, the storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module registers an event listener for metadata updates to the storage volume with the Kubernetes API server; The storage volume interaction module receives metadata update events pushed by the K8s API server through an event listener, and obtains key metadata credentials based on the metadata update events; When the event listener does not receive the key metadata credential within a preset time, the storage volume interaction module starts an adaptive periodic query mechanism; The adaptive periodic query mechanism adjusts the query interval based on the response latency of the K8s API server and the cluster load; The storage volume interaction module maintains a local metadata version cache; When the storage volume interaction module performs periodic queries based on the adjusted query interval, it sends a query request to the K8s API server carrying the version identifier in the local metadata version cache. The K8s API server returns metadata updates that are higher than the version identifier of the query request; When the storage volume interaction module receives the key metadata credential, it updates the version identifier in the local metadata version cache and stops periodic queries; it compares the version identifier in the key metadata credential with the target update version; when the comparison result meets the target update version, it determines that the updated data operation key encapsulated ciphertext has been synchronized.

[0056] Specifically, the storage volume interaction module registers event listeners for storage volume metadata updates with the Kubernetes API server. This means the storage volume interaction module uses the Watch mechanism provided by the Kubernetes API to subscribe to metadata change events for a specific storage volume object. The purpose is to achieve real-time awareness of key metadata credential updates, avoiding the latency and resource consumption caused by passive polling. The event listener can be understood as a callback function or message queue subscriber; when the Kubernetes API server detects changes in the storage volume's metadata, it proactively pushes the update event to the registered listeners.

[0057] When the event listener does not receive key metadata credentials within a preset time, the storage volume interaction module initiates an adaptive periodic query mechanism. This is a fault-tolerance and robustness enhancement strategy to address potential network latency, API server failures, or event loss during event push. The adaptive periodic query mechanism dynamically adjusts the query interval based on the Kubernetes API server's response latency and cluster load. For example, when the Kubernetes API server response latency is high or the cluster load is heavy, the query interval will be appropriately extended to avoid further burdening the system; conversely, when the system is in good condition, the query interval can be shortened to improve synchronization timeliness. Its purpose is to optimize system resource utilization while ensuring timely synchronization.

[0058] The storage volume interaction module maintains a local metadata version cache, which stores version identifiers of currently known storage volume metadata. During periodic queries, the storage volume interaction module sends a query request to the Kubernetes API server, carrying the version identifier from the local metadata version cache. Upon receiving this request, the Kubernetes API server only returns metadata updates with version identifiers higher than those carried in the query request, thus achieving incremental updates and reducing unnecessary data transfer. When the storage volume interaction module receives the key metadata credential, it updates the version identifier in the local metadata version cache, stops the current periodic query, and resumes event listening mode. Subsequently, it compares the version identifier in the key metadata credential with the target update version. If the comparison result matches the target update version, it can be determined that the updated data operation key encapsulated ciphertext has been successfully synchronized.

[0059] Optionally, the step of causing the storage volume interaction module on the driving processing unit to write the updated encapsulation key to the protected memory upon receiving the updated encapsulation key includes: The storage volume interaction module obtains the updated encapsulation key; The storage volume interaction module locks the pre-allocated memory region in physical memory and identifies the locked memory region; The storage volume interaction module writes the updated encapsulation key to the locked memory area; The storage volume interaction module sets memory page access permissions for locked memory regions, allowing only specific kernel modules or trusted processes to access locked memory regions through restricted interfaces. The storage volume interaction module manages multiple fixed-size memory blocks in a locked memory region based on memory page access permissions; the memory blocks are used to store the encapsulation keys for different storage volumes. The storage volume interaction module updates the encapsulation key in memory blocks using atomic writes.

[0060] Specifically, after receiving the updated encapsulation key, the storage volume interaction module first obtains the key. To ensure the security of key storage, the storage volume interaction module locks a pre-allocated memory region in physical memory, thus defining a locked memory region. The purpose of locking the memory region is to prevent it from being swapped to disk by the operating system, avoiding the leakage of sensitive key data to non-volatile storage media. Subsequently, the updated encapsulation key is written to this locked memory region.

[0061] To further enhance security, the storage volume interaction module finely configures memory page access permissions for locked memory regions. This permission configuration aims to allow only specific kernel modules or rigorously authenticated trusted processes to access the locked memory region through a predefined restricted interface. This mechanism significantly restricts direct access to the encapsulation key, effectively preventing unauthorized processes or malware from stealing the key.

[0062] In practical applications, the storage volume interaction module manages multiple fixed-size memory blocks within a locked memory region based on predefined memory page access permissions. These memory blocks are specifically used to store encapsulation keys for different storage volumes, achieving isolated key storage and efficient management. Furthermore, atomic writes are used when updating the encapsulation keys within the memory blocks. Atomic writes ensure the integrity and uninterrupted nature of the key update operation; that is, the entire key data is either completely written successfully or not written at all, preventing key data corruption or inconsistency due to system interruptions or failures.

[0063] Optionally, the storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module maintains a local storage volume metadata registry; the storage volume metadata registry is used to mount the unique identifier of the storage volume, the corresponding key metadata credential version, and the monitoring status flag; The storage volume interaction module starts a lightweight metadata monitoring agent; the lightweight metadata monitoring agent refers to periodically sending batch requests to specific endpoints of the K8s API server in a batch manner; the batch request carries the unique identifier of a batch of storage volumes in the storage volume metadata registry and the corresponding key metadata credential version. After a specific endpoint of the K8s API server receives a batch request, it queries the metadata of each storage volume in parallel and only returns key metadata credential updates with a key metadata credential version higher than the highest key metadata credential version in the batch request. After receiving the returned key metadata credential update, the lightweight metadata monitoring agent parses the update content and updates the key metadata credential version of the corresponding storage volume in the local storage volume metadata registry according to the unique identifier of the storage volume, while setting the monitoring status to synchronized. The storage volume interaction module determines whether the updated data operation key encapsulated ciphertext has been fully synchronized based on the monitoring status markers.

[0064] Specifically, the storage volume interaction module maintains a local storage volume metadata registry. This registry can be understood as a local cache or database, used to record key metadata information for all mounted storage volumes on the current processing unit. The unique identifier of a storage volume is used to uniquely identify it; for example, it could be the storage volume name, UUID, or a combination of PV / PVC ID. The key metadata credential version is used to track the version number of the currently known key metadata credential for each storage volume, facilitating subsequent version comparison with the Kubernetes API server for incremental updates. A monitoring status flag indicates whether the key metadata credential for the storage volume has been synchronized; this could be a boolean value or an enumerated value.

[0065] Furthermore, the storage volume interaction module initiates a lightweight metadata monitoring agent. This agent is a standalone, low-resource-consumption component or thread whose core function is to periodically send requests to a specific endpoint of the Kubernetes API server in a batch manner. Batch processing means that the agent does not send a request individually for each storage volume, but rather packages the monitoring requests for a batch of storage volumes into a single request. The batch request carries the unique identifiers of the batch of storage volumes in the storage volume metadata registry and their corresponding key metadata credential versions. The specific endpoint of the Kubernetes API server is designed to efficiently handle such batch requests; upon receiving a request, it can query the metadata of each storage volume involved in the request in parallel. To optimize response efficiency and reduce data transfer volume, this endpoint only returns key metadata credential updates whose versions are higher than the highest version in the batch request—that is, only the latest updates that the client has not yet obtained.

[0066] When the lightweight metadata monitoring agent receives the updated key metadata credentials from the Kubernetes API server, it parses these updates. After parsing, the agent locates the corresponding storage volume record in the local storage volume metadata registry based on the unique identifier of the storage volume contained in the update content and updates its key metadata credentials version. Simultaneously, the monitoring status flag for that storage volume is set to synchronized, indicating that its key metadata credentials have been updated to the latest state. Finally, the storage volume interaction module can use these monitoring status flags to determine whether the updated data operation key encapsulated ciphertext has been fully synchronized.

[0067] Optionally, the storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module obtains the corresponding key update frequency parameters and compliance requirements from the preset tenant security policy configuration based on the identifier of the tenant to which each storage volume belongs; The storage volume interaction module configures an independent metadata monitoring queue for each tenant. The polling cycle and retry policy of the metadata monitoring queue are adjusted according to the key update frequency parameter. The storage volume interaction module routes the storage volume's metadata update events to the corresponding tenant's metadata monitoring queue; The storage volume interaction module processes events in each tenant's monitoring queue and verifies and records the synchronization status of key metadata credentials according to compliance requirements to determine whether the data operation key encapsulated ciphertext has been fully synchronized.

[0068] Specifically, a tenant identifier can be understood as a logical or physical tag used to uniquely identify different tenants in a Kubernetes cloud-native environment. This could be a namespace name, tenant ID, or a tag associated with the tenant. Predefined tenant security policy configurations refer to a predefined and stored set of security rules for different tenants, which includes tenant-specific key management policies, such as key update frequency, encryption algorithm requirements, key length standards, and data synchronization compliance requirements. The key update frequency parameter specifies how often a particular tenant's key should be updated, such as hourly, daily, or weekly. Compliance requirements refer to the regulations, industry standards, or internal security specifications that must be followed during key synchronization and management, such as GDPR, HIPAA, or PCI DSS.

[0069] The independent metadata monitoring queue refers to a dedicated message queue allocated to each tenant for receiving and processing metadata update events for their storage volumes. By configuring an independent queue for each tenant, interference between events from different tenants can be avoided, and independent resource scheduling and processing can be performed based on tenant priority and key update frequency parameters. The polling period and retry policy are dynamically adjusted according to the key update frequency parameter. For example, for tenants requiring high-frequency key updates, the polling period of their monitoring queue will be set to a shorter period, and the retry policy will be more aggressive to ensure timely key updates.

[0070] In practical applications, routing storage volume metadata update events to the corresponding tenant's metadata monitoring queue can be achieved through an event bus or message broker. When the Kubernetes API server publishes a storage volume metadata update event, the storage volume interaction module forwards the event to the corresponding tenant's metadata monitoring queue based on the tenant identifier of the storage volume contained in the event.

[0071] Furthermore, processing events in each tenant's monitoring queue refers to the storage volume interaction module retrieving events from its respective monitoring queue and initiating the corresponding processing flow. Verifying and recording the synchronization status of key metadata credentials according to compliance requirements means that during processing, the received key metadata credentials are rigorously verified based on compliance requirements obtained from the tenant's security policy configuration. This includes checking the validity of the credentials, digital signature, key strength, and compliance with specific encryption standards. The verification results are recorded as a basis for determining whether the data operation key encapsulated ciphertext has been fully synchronized, and provide support for auditing and compliance reporting.

[0072] Optionally, the storage volume interaction module processes events in each tenant's monitoring queue and verifies and records the synchronization status of key metadata credentials according to compliance requirements. The steps include: The storage volume interaction module loads compliance requirements into the rule execution environment; the rule execution environment is a verification runtime environment used to load and execute compliance requirements. The rule execution environment distributes key metadata credential verification requests to the verification task queue and drives multiple verification work units to perform verification in parallel, so as to output verification results and update the synchronization status record of the storage volume. The rule execution environment verifies the synchronization status of the key metadata credential based on the loaded compliance requirements and obtains the verification result. The verification includes: comparing the timestamp in the key metadata credential with the current system time to determine the validity of the credential; and checking the encryption algorithm strength and key length contained in the key metadata credential according to the security level configured by the tenant. Update the synchronization status record of the storage volume based on the verification results.

[0073] Specifically, after receiving the key metadata credentials, the storage volume interaction module sends its synchronization status verification request to the rule enforcement environment. The rule enforcement environment can be understood as a software component or service specifically designed to process and execute predefined compliance rules. Its purpose is to provide a structured, scalable, and efficient platform to ensure the validity and compliance of key metadata credentials. The rule enforcement environment distributes received verification requests to a verification task queue, which caches pending verification requests, thereby achieving asynchronous processing and load balancing. Simultaneously, the rule enforcement environment drives multiple verification work units to execute verifications in parallel. Each verification work unit is an independent processing entity within the rule enforcement environment; each work unit can concurrently retrieve verification requests from the verification task queue and execute verification logic, aiming to improve verification throughput and response speed.

[0074] The rule enforcement environment verifies the synchronization status of key metadata credentials based on pre-loaded compliance requirements. This verification process includes several aspects. First, it compares the timestamp contained in the key metadata credential with the current system time to determine if the credential is valid, i.e., its timeliness. For example, if the timestamp indicates that the credential has expired, it will be considered invalid. Second, it checks the encryption algorithm strength and key length contained in the key metadata credential according to the security level configured by the tenant to which the storage volume belongs. For example, for tenants with high security levels, the use of the AES-256 encryption algorithm and a key length of at least 2048 bits may be required, while for tenants with low security levels, AES-128 may be allowed. These checks aim to ensure that the keys and encryption methods used comply with tenant-specific security standards. After verification, the rule enforcement environment outputs the verification result and updates the synchronization status record of the storage volume accordingly, such as marking it as "synchronized," "verification failed," or "expired."

[0075] Optionally, the rule enforcement environment verifies the synchronization status of the key metadata credentials based on the loaded compliance requirements. The steps to obtain the verification result include: The rule enforcement environment distributes the received key metadata credential verification requests to the verification task queue; The rule execution environment starts multiple verification work units, which retrieve verification requests from the verification task queue in parallel. Verify the compliance requirements of the unit of work in the local cache tenant security policy configuration; The verification unit verifies the synchronization status of the obtained key metadata credentials based on the compliance requirements of the local cache, and obtains the verification result. The verification unit writes the verification results into the result collection queue; The rule execution environment retrieves the verification results from the result collection queue and updates the synchronization status record of the storage volume.

[0076] Specifically, the rule enforcement environment verifies the synchronization status of the key metadata credentials based on the loaded compliance requirements. The steps to obtain the verification result can be further refined as follows: The rule enforcement environment can be configured to receive key metadata credential verification requests from the storage volume interaction module. These requests typically contain the key metadata credential to be verified and its associated storage volume identifier. Upon receiving the request, the rule enforcement environment is responsible for effectively distributing these requests to one or more verification task queues. The verification task queues can be implemented as message queue services, such as Kafka or RabbitMQ, to ensure reliable transmission and asynchronous processing of requests.

[0077] Furthermore, the rule enforcement environment is designed to launch multiple verification work units. These verification work units are independent computational entities, such as containerized microservices or worker threads in a thread pool. The verification work units are configured to retrieve pending verification requests from the verification task queue in parallel. This parallel processing significantly improves the throughput and response speed of key metadata credential verification, especially in large-scale cloud-native environments.

[0078] Before executing a verification task, each verification unit caches the compliance requirements in the security policy configuration of the tenant it is responsible for locally. This local caching mechanism reduces frequent access to the central configuration service, thereby reducing verification latency and improving verification efficiency. Compliance requirements can include various verification rules such as key validity, encryption algorithm strength, and key length.

[0079] In practical applications, the verification work unit verifies the synchronization status of the key metadata credentials obtained from the verification task queue based on local cache compliance requirements. The verification process may involve comparing the timestamp of the credentials to determine their timeliness, and checking the encryption algorithm and key length declared in the credentials to ensure they meet the tenant's security level requirements. After verification, the verification work unit writes the generated verification result, such as whether the verification passed or failed, and the specific reason for failure, to a result collection queue. The result collection queue can also be implemented using a message queue service to aggregate the verification results from all verification work units.

[0080] Finally, the rule enforcement environment continuously retrieves the verification results submitted by each verification work unit from the result collection queue. Once the verification results are obtained, the rule enforcement environment updates the synchronization status record of the storage volume in a timely manner based on these results. For example, if all relevant key metadata credentials pass verification, the synchronization status of the storage volume can be marked as "synchronized"; otherwise, it may be marked as "synchronization failed" and trigger the corresponding alarm mechanism.

[0081] This application also discloses a storage volume data encryption system in a K8s cloud-native environment, used to perform storage volume data encryption in a K8s cloud-native environment, combined with... Figure 3 As shown, the storage volume data encryption system 1 in the K8s cloud-native environment includes: The key structure establishment module 11 is used to configure the data operation key for data encryption and decryption, and to configure the encapsulation key for encapsulating the data operation key, so as to establish a hierarchical key structure. The encapsulation key update module 12 is used to update the encapsulation key when the hierarchical key structure needs to be updated, obtain the updated encapsulation key, and use the updated encapsulation key to re-encapsulate the data operation key to obtain the updated data operation key encapsulated ciphertext. The key-ciphertext transmission module 13 is used to transmit the updated encapsulation key and the updated data operation key encapsulated ciphertext to one or more processing units in the cloud-native environment. The data operation key module 14 is used to drive the storage volume interaction module on the processing unit to store the updated encapsulation key and the updated data operation key encapsulated ciphertext after receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext. At the same time, it retains the encapsulation key and the corresponding data operation key encapsulated ciphertext of the historical version to build a repository of encapsulation keys and the corresponding data operation key encapsulated ciphertext. When the application component requests access to the storage volume, it decapsulates the corresponding data operation key encapsulated ciphertext according to the currently available encapsulation key in the repository to obtain the corresponding data operation key. The encryption / decryption interaction module 15 is used to drive the storage volume interaction module to use the data operation key obtained from decapsulation to perform encryption / decryption operations on the data in the storage volume, and to maintain continuous access to the storage volume by the application components during the switching between the encapsulation key and the data operation key encapsulated ciphertext.

[0082] To better understand the system solution proposed in this application, some key modules and their functions are described in detail below.

[0083] The key structure establishment module is responsible for configuring data manipulation keys used for data encryption and decryption, and configuring encapsulation keys used to encapsulate the data manipulation keys, to establish a hierarchical key structure. This module can be deployed in a standalone Key Management Service (KMS) or as a core component of a cloud-native platform. Specifically, the key structure establishment module can generate high-entropy symmetric keys as data manipulation keys, such as Advanced Encryption Standard (AES)-256 keys, for directly encrypting storage volume data. Simultaneously, this module can generate an asymmetric key pair, such as an RSA key pair, where the private key serves as the encapsulation key for encrypting the data manipulation keys, while the public key is used for decryption. Alternatively, the key structure establishment module can also be integrated with a Hardware Security Module (HSM) to generate and protect the encapsulation keys, thereby further enhancing key security.

[0084] The encapsulation key update module is responsible for updating the encapsulation key when the hierarchical key structure requires a key update. It obtains the updated encapsulation key and uses it to re-encapsulate the data operation key, resulting in updated data operation key-encapsulated ciphertext. This module can be implemented as a separate service process within the key management service or as a sub-function of the key structure establishment module. For example, the encapsulation key update module can automatically generate a new encapsulation key based on a preset key update strategy (e.g., updating every 24 hours) or a received security event trigger. Subsequently, the module obtains the current data operation key and encrypts it using the newly generated encapsulation key, thereby generating new data operation key-encapsulated ciphertext. In some implementations, the encapsulation key update module can employ a key rotation mechanism, i.e., updating only the encapsulation key without changing the data operation key itself, and then re-encrypting the data operation key with the new encapsulation key, thus reducing the impact of the update operation on data encryption and decryption.

[0085] The key-ciphertext transmission module is responsible for transmitting the updated encapsulation key and the updated data operation key encapsulated in ciphertext to one or more processing units in the cloud-native environment. This module can be implemented using Kubernetes' API mechanism or message queue service. For example, the key-ciphertext transmission module can push the updated key information to the storage volume interaction module on each worker node in the Kubernetes cluster through a secure communication channel, such as gRPC or HTTP / 2 protocol based on TLS encryption. As another implementation, the key-ciphertext transmission module can also publish the key update information to the Kubernetes ConfigMap or Secret resource, and the storage volume interaction module on the processing unit can actively poll or listen for update events of these resources through the Kubernetes API to obtain the latest key.

[0086] The data manipulation key module is responsible for driving the storage volume interaction module on the processing unit to store the updated encapsulation key and the updated data manipulation key-encapsulated ciphertext upon receiving them. It also retains historical versions of the encapsulation key and their corresponding ciphertexts to build a repository of encapsulation keys and their corresponding ciphertexts. When an application component requests access to the storage volume, it decapsulates the corresponding ciphertext using the currently available encapsulation key in the repository to obtain the corresponding data manipulation key. This module is typically deployed as part of the storage volume interaction module on Kubernetes worker nodes. Specifically, the data manipulation key module can store the received new and old key information in local persistent storage, such as an encrypted file system or a local database, and maintain a version control mechanism to distinguish between different key versions. When an application component needs to access the storage volume, the data manipulation key module queries the local repository, selects the corresponding encapsulation key based on the currently active key version, and decrypts the ciphertext to obtain the data manipulation key used for data encryption and decryption. For example, when application component A requests access to storage volume X, the data manipulation key module examines the metadata of storage volume X to determine which version of the encapsulation key should be used. Assuming the current version is V2, the data manipulation key module retrieves the V2 version encapsulation key from the repository and uses it to decrypt the V2 version data manipulation key encapsulation ciphertext, obtaining the data manipulation key.

[0087] The encryption / decryption interaction module is responsible for driving the storage volume interaction module to use the data operation key obtained from decapsulation to encrypt and decrypt data in the storage volume, and maintaining continuous access to the storage volume by application components during the switching between the encapsulation key and the ciphertext encapsulated by the data operation key. This module is also typically part of the storage volume interaction module and is tightly integrated with the underlying storage driver and block device encryption mechanism. For example, after obtaining the data operation key, the encryption / decryption interaction module securely loads it into a protected memory area and configures the underlying block device encryption module (such as dm-crypt in Linux or BitLocker in Windows) to use the key to perform real-time encryption and decryption of read and write operations on the storage volume. During key switching, the encryption / decryption interaction module can adopt a dual-key parallel operation method, that is, the old key remains available until the new key is fully synchronized and ready, ensuring that ongoing data operations are not interrupted. Once the new key is atomically loaded and activated, the system smoothly switches to the new key, and the application components are unaware of this process, thus maintaining continuous access to the storage volume. As a preferred implementation, the encryption / decryption interaction module can utilize the operating system's memory locking mechanism (such as the mlockall system call) to load the key into non-swappable memory to prevent the key from being written to disk, thereby further enhancing security.

[0088] The storage volume data encryption system proposed in this application for a Kubernetes cloud-native environment effectively solves the downtime and data access interruption problems faced by traditional solutions during high-frequency key updates in a Kubernetes cloud-native environment through its modular design and collaborative working mechanism. Compared with the limitations of existing technologies that rely excessively on centralized key management services and are difficult to adapt to container rapid scheduling and high-frequency key updates, the system in this application significantly improves the flexibility, security, and business continuity of data encryption by building a key store locally in the processing unit and achieving uninterrupted key switching.

[0089] Specifically, this system decomposes key management functionality into independent modules such as key structure establishment, encapsulation key updates, key ciphertext transmission, data operation key management, and encryption / decryption interaction, achieving clear division of responsibilities and functional decoupling. This modular design allows the system to more flexibly adapt to the dynamic scaling of application components and frequent mounting and unmounting of storage volumes in a Kubernetes cloud-native environment. Especially in high-frequency key update scenarios, this system maintains a key repository locally within the processing unit and supports smooth switching between old and new keys, avoiding the storage volume unmounting and application restart operations caused by key updates in traditional solutions, thereby eliminating the risk of business interruption. Furthermore, the application of a hierarchical key structure allows encapsulation key updates to be performed without directly affecting data operation keys, further improving the efficiency and security of key updates. This localized key management and intelligent switching mechanism enables data encryption in a Kubernetes cloud-native environment to better adapt to dynamically scaling application scenarios and stringent security compliance requirements, providing enterprises with a more robust and efficient data protection solution.

[0090] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for encrypting storage volume data in a Kubernetes cloud-native environment, used to execute in a cloud-native environment where application components expand and storage volumes are periodically connected and disconnected, characterized in that... include: Configure a data operation key for data encryption and decryption, and configure an encapsulation key for encapsulating the data operation key to establish a hierarchical key structure; When the hierarchical key structure needs to update the key, the encapsulation key is updated to obtain the updated encapsulation key, and the data operation key is re-encapsulated using the updated encapsulation key to obtain the updated data operation key encapsulated ciphertext. Transmit the updated encapsulation key and the updated data manipulation key to encapsulate ciphertext into one or more processing units in a cloud-native environment; After receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the historical version of the encapsulation key and the corresponding data operation key encapsulated ciphertext, so as to build a repository of encapsulation keys and the corresponding data operation key encapsulated ciphertext. When an application component requests access to a storage volume, it decapsulates the corresponding data operation key from the ciphertext encapsulated with the corresponding data operation key based on the currently available encapsulation key in the repository. The storage volume interaction module is driven to use the data operation key obtained from decapsulation to encrypt and decrypt the data in the storage volume, and maintains the application component's continuous access to the storage volume during the switching between the encapsulation key and the data operation key encapsulated ciphertext. After receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the encapsulation key and the corresponding data operation key encapsulated ciphertext of the historical version, so as to build a repository of encapsulation keys and the corresponding data operation key encapsulated ciphertext. When an application component requests access to a storage volume, the steps of decapsulating the ciphertext encapsulated with the corresponding data operation key based on the currently available encapsulation key in the repository to obtain the corresponding data operation key include: When the storage volume interaction module on the driving processing unit receives an updated encapsulation key, it writes the updated encapsulation key into the protected memory. When the driving processing unit receives an updated data operation key encapsulated ciphertext, it stores the updated data operation key encapsulated ciphertext and retains the historical encapsulation key and the corresponding data operation key encapsulated ciphertext to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertext. The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized and obtain the synchronization detection result; When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has not been synchronized, the corresponding version of the data operation key encapsulated ciphertext is decapsulated using the encapsulation key of the historical version in the repository to obtain the currently available data operation key. Write the currently available data operation key to the volume key memory slot associated with the storage volume; When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has been synchronized, the updated encapsulation key in the protected memory is used to decapsulate the updated data operation key encapsulated ciphertext to obtain the latest data operation key. The latest data operation key is replaced and written to the volume key memory slot using an atomic write method; The block device encryption module reads the latest data operation key from the volume key memory slot using a pre-registered handle.

2. The method for encrypting storage volume data in a K8s cloud-native environment according to claim 1, characterized in that, The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The key management service unit encapsulates the data operation key into ciphertext, the identifier of the encapsulated key, and the timestamp into a data packet; The key management service unit uses a private key to digitally sign the data packet, forming a key metadata credential; The key management service unit writes the key metadata credentials into the metadata annotation of the storage volume; The storage volume interaction module obtains the key metadata credentials; The storage volume interaction module uses a public key to verify the digital signature of the key metadata credential; When the digital signature verification is valid, the storage volume interaction module extracts the data operation key encapsulated ciphertext and the identifier of the encapsulated key from the key metadata certificate; it compares the identifier of the encapsulated key with the target update version recorded locally; when the comparison result meets the target update version, it is determined that the updated data operation key encapsulated ciphertext has been synchronized; otherwise, it is determined that the updated data operation key encapsulated ciphertext has not been synchronized. The storage volume interaction module obtains the encapsulation key based on the identifier of the encapsulation key; The storage volume interaction module uses the encapsulation key to decapsulate the ciphertext of the data operation key to obtain the data operation key. The storage volume interaction module uses the data operation key to configure the block device encryption module; When the digital signature verification is invalid, the storage volume interaction module rejects the key metadata credential.

3. The method for encrypting storage volume data in a K8s cloud-native environment according to claim 2, characterized in that, The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module registers an event listener for metadata updates to the storage volume with the Kubernetes API server; The storage volume interaction module receives metadata update events pushed by the K8s API server through the event listener, and obtains the key metadata credentials based on the metadata update events; When the event listener does not receive the key metadata credential within a preset time, the storage volume interaction module initiates an adaptive periodic query mechanism; The adaptive periodic query mechanism adjusts the query interval based on the response latency of the K8s API server and the cluster load; the storage volume interaction module maintains a local metadata version cache. When the storage volume interaction module performs periodic queries based on the adjusted query interval, it sends a query request to the K8s API server carrying the version identifier in the local metadata version cache. The K8s API server returns metadata updates with a version identifier higher than the query request; When the storage volume interaction module receives the key metadata credential, it updates the version identifier in the local metadata version cache and stops the periodic query; it compares the version identifier in the key metadata credential with the target update version; when the comparison result meets the target update version, it determines that the updated data operation key encapsulated ciphertext has been synchronized.

4. The method for encrypting storage volume data in a K8s cloud-native environment according to claim 1, characterized in that, When the storage volume interaction module on the drive processing unit receives the updated encapsulation key, the step of writing the updated encapsulation key into the protected memory includes: The storage volume interaction module obtains the updated encapsulation key; The storage volume interaction module locks the pre-allocated memory region in physical memory, thus determining the locked memory region; The storage volume interaction module writes the updated encapsulation key into the locked memory area; The storage volume interaction module sets the memory page access permissions for the locked memory region, allowing only specific kernel modules or trusted processes to access the locked memory region through a restricted interface. The storage volume interaction module manages multiple fixed-size memory blocks in the locked memory region based on memory page access permissions; the memory blocks are used to store encapsulation keys for different storage volumes. The storage volume interaction module updates the encapsulation key in the memory block using an atomic write method.

5. A method for encrypting storage volume data in a K8s cloud-native environment according to claim 1, characterized in that, The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module maintains a local storage volume metadata registry; the storage volume metadata registry is used to mount the unique identifier of the storage volume, the corresponding key metadata credential version, and the monitoring status flag. The storage volume interaction module initiates a lightweight metadata monitoring agent; the lightweight metadata monitoring agent refers to periodically sending batch requests to a specific endpoint of the K8s API server in a batch processing manner; the batch request carries the unique identifier of a batch of storage volumes in the storage volume metadata registry and the corresponding key metadata credential version. After receiving a batch request, a specific endpoint of the K8s API server queries the metadata of each storage volume in parallel and returns only the key metadata credential update with a version higher than the highest key metadata credential version in the batch request. After receiving the returned key metadata credential update, the lightweight metadata monitoring agent parses the update content and updates the key metadata credential version of the corresponding storage volume in the local storage volume metadata registry according to the unique identifier of the storage volume, while setting the monitoring status flag to synchronized. The storage volume interaction module determines whether the updated data operation key encapsulated ciphertext has been fully synchronized based on the monitoring status marker.

6. The method for encrypting storage volume data in a K8s cloud-native environment according to claim 1, characterized in that, The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized. This includes the following steps: The storage volume interaction module obtains the corresponding key update frequency parameters and compliance requirements from the preset tenant security policy configuration based on the identifier of the tenant to which each storage volume belongs. The storage volume interaction module configures an independent metadata monitoring queue for each tenant, and the polling period and retry policy of the metadata monitoring queue are adjusted according to the key update frequency parameter. The storage volume interaction module routes the storage volume's metadata update events to the corresponding tenant's metadata monitoring queue; The storage volume interaction module processes events in each tenant's monitoring queue and verifies and records the synchronization status of the key metadata credentials according to the compliance requirements, in order to determine whether the data operation key encapsulated ciphertext has been fully synchronized.

7. A method for encrypting storage volume data in a K8s cloud-native environment according to claim 6, characterized in that, The storage volume interaction module processes events in each tenant's monitoring queue and verifies and records the synchronization status of key metadata credentials according to the compliance requirements. The steps include: The storage volume interaction module loads the compliance requirements into the rule execution environment; wherein, the rule execution environment is a verification runtime environment used to load and execute the compliance requirements, and the rule execution environment stores key metadata. The verification request is distributed to the verification task queue and drives multiple verification work units to perform verification in parallel, so as to output the verification result and update the synchronization status record of the storage volume; The rule execution environment verifies the synchronization status of the key metadata credential according to the loaded compliance requirements and obtains the verification result. The verification includes: comparing the timestamp in the key metadata credential with the current system time to determine the validity of the credential; and checking the encryption algorithm strength and key length contained in the key metadata credential according to the security level configured by the tenant. Based on the verification results, update the synchronization status record of the storage volume.

8. A method for encrypting storage volume data in a K8s cloud-native environment according to claim 7, characterized in that, The rule execution environment verifies the synchronization status of the key metadata credentials according to the loaded compliance requirements, and the steps to obtain the verification result include: The rule execution environment distributes the received key metadata credential verification requests to the verification task queue; The rule execution environment starts multiple verification work units, and the verification work units obtain verification requests from the verification task queue in parallel. The verification unit locally caches the compliance requirements in the tenant security policy configuration; The verification unit verifies the synchronization status of the obtained key metadata credentials based on the compliance requirements of the local cache, and obtains the verification result. The verification unit writes the verification result into the result collection queue; The rule execution environment retrieves the verification results from the result collection queue and updates the synchronization status record of the storage volume.

9. A storage volume data encryption system for a K8s cloud-native environment, used to perform storage volume data encryption in a K8s cloud-native environment, characterized in that, include: A key structure establishment module is used to configure data operation keys for data encryption and decryption, and to configure encapsulation keys for encapsulating the data operation keys, so as to establish a hierarchical key structure. The encapsulation key update module is used to update the encapsulation key when the hierarchical key structure needs to be updated, to obtain the updated encapsulation key, and to re-encapsulate the data operation key using the updated encapsulation key to obtain the updated data operation key encapsulated ciphertext. The key-ciphertext transmission module is used to transmit the updated encapsulation key and the updated data operation key encapsulated ciphertext to one or more processing units in the cloud-native environment. The data operation key module is used to drive the storage volume interaction module on the processing unit to store the updated encapsulation key and the updated data operation key encapsulated ciphertext after receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext. At the same time, it retains the encapsulation key and the corresponding data operation key encapsulated ciphertext of the historical version to build a repository of encapsulation key and the corresponding data operation key encapsulated ciphertext. When an application component requests access to a storage volume, it decapsulates the corresponding data operation key from the ciphertext encapsulated with the corresponding data operation key based on the currently available encapsulation key in the repository. The encryption / decryption interaction module is used to drive the storage volume interaction module to use the data operation key obtained from decapsulation to perform encryption and decryption operations on the data in the storage volume, and to maintain the application component's continuous access to the storage volume during the switching between the encapsulation key and the data operation key encapsulated ciphertext. After receiving the updated encapsulation key and the updated data operation key encapsulated ciphertext, the storage volume interaction module on the driving processing unit stores the updated encapsulation key and the updated data operation key encapsulated ciphertext, while retaining the encapsulation key and the corresponding data operation key encapsulated ciphertext of the historical version, so as to build a repository of encapsulation keys and the corresponding data operation key encapsulated ciphertext. When an application component requests access to a storage volume, it decapsulates the corresponding data operation key from the ciphertext encapsulated with the data operation key based on the currently available encapsulation key in the repository, obtaining the corresponding data operation key, including: When the storage volume interaction module on the driving processing unit receives an updated encapsulation key, it writes the updated encapsulation key into the protected memory. When the driving processing unit receives an updated data operation key encapsulated ciphertext, it stores the updated data operation key encapsulated ciphertext and retains the historical encapsulation key and the corresponding data operation key encapsulated ciphertext to build a repository of encapsulation keys and corresponding data operation key encapsulated ciphertext. The storage volume interaction module continuously monitors the metadata associated with the storage volume to detect whether the updated data operation key encapsulated ciphertext has been synchronized and obtain the synchronization detection result; When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has not been synchronized, the corresponding version of the data operation key encapsulated ciphertext is decapsulated using the encapsulation key of the historical version in the repository to obtain the currently available data operation key. Write the currently available data operation key to the volume key memory slot associated with the storage volume; When the synchronization detection result indicates that the updated data operation key encapsulated ciphertext has been synchronized, the updated encapsulation key in the protected memory is used to decapsulate the updated data operation key encapsulated ciphertext to obtain the latest data operation key. The latest data operation key is replaced and written to the volume key memory slot using an atomic write method; The block device encryption module reads the latest data operation key from the volume key memory slot using a pre-registered handle.

Images