A key-based resilient file system authentication method and device

Abstract

The application discloses a kind of based on key's flexible file system authentication method and device, it is related to cloud computing, distributed storage technical field.The method, by issuing the key that user is created for file system under the flexible file management and control platform to the flexible file service success, NFS server is configured file for file system;NFS server receives RPC request sent after NFS client executes mounting command;Receive RPC request, complete parameter analysis, check parameter;NFS server sends request to key server, and key server checks key and judges whether the decrypted ciphertext is consistent with the key information in configuration file, if consistent, mounting request is legal;If not consistent, refuse mounting request.The permission authentication of the key and NAT gateway combination distinguishes the NFS mounting request from different user virtual machines, and realizes more accurate permission control compared with traditional NFS protocol.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and distributed storage technology, and in particular to a key-based elastic file system authentication method and apparatus. Background Technology

[0002] With the rapid development of cloud computing technology and the establishment of new-generation cloud platforms, the demand for file storage is increasing daily. In these new-generation cloud platforms, the CStor elastic file system provides file storage services to users based on the traditional NFS protocol. However, traditional NFS authentication can only be performed based on the NFS client's IP address.

[0003] In a VPC scenario, when a user mounts a virtual machine via an NFS client, a mount request is sent to the NFS server. This request is forwarded to the NFS server by the NAT gateway. When the virtual machine sends a mount request, the IP address displayed is the address of the NAT gateway, and the NFS server cannot identify or distinguish which VM the mount request originated from. In CStor Elastic File System, authentication is performed using the traditional NFS protocol. The VPC's NAT gateway has access to the elastic file system, allowing all virtual machines within the NAT gateway to mount and modify any elastic file system without any control permissions.

[0004] However, in the process of implementing the inventive technical solution in the embodiments of this application, the inventors of this application discovered that the above-mentioned technology has at least the following technical problems:

[0005] All virtual machines can mount file systems through the NAT gateway, but there is a lack of precise authentication for virtual machine mount requests. Summary of the Invention

[0006] This application provides a key-based elastic file system authentication method and apparatus, which solves the problem in the prior art where all virtual machines under a NAT gateway have the right to mount and modify any elastic file system. It realizes permission authentication by combining NAT gateway and key, and can authenticate mount requests through key, thereby achieving precise permission control.

[0007] This application provides a key-based elastic file system authentication method, including the following steps:

[0008] S1. After the user successfully sends the key created for the file system to the elastic file service on the elastic file management platform, the NFS server configures the file system.

[0009] S2. The NFS server receives the RPC request sent by the NFS client after executing the mount command;

[0010] S3. Receive RPC request, complete parameter parsing, and verify parameters;

[0011] S4. The NFS server sends a request to the key server, which verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected.

[0012] Furthermore, the configuration file in S1 includes: file system information and file system key information.

[0013] Furthermore, S2 specifically includes the following steps:

[0014] S21. The NFS client executes the mount command to parse the key;

[0015] S22: The NFS client encapsulates the dirpath and secret into rpc_message and sends an RPC request to the NFS server.

[0016] Furthermore, the mount command in S21 includes: mount parameters, secret parameters, or secretFile parameters.

[0017] Furthermore, the S22 encapsulation of the secret specifically refers to the NFS client encapsulating the secret into the data packet within the IP message.

[0018] Furthermore, after S2 executes the mount command, it also includes replacing the Source IP in the IP Header of the IP packet with the NAT gateway address.

[0019] Furthermore, in S4, sending the request specifically involves the NFS server calculating the HTTP request parameters based on the secret and the AK and SK in the NFS configuration, and then sending the request to the key server.

[0020] Furthermore, S4 specifically includes the following steps:

[0021] S41. Combine the user ID, mounting key, and AK, sort the parameters, and concatenate them with \n. Perform MD5 and base64 operations on the concatenation result.

[0022] S42. Concatenate the calculation result, request path, and time using \n;

[0023] S43. Use SK to encrypt the result of S42 using Hmac;

[0024] S44. The encryption result is placed in the HTTP request header and an HTTP request is sent to the key server, which then performs key verification.

[0025] Furthermore, the key server's key verification in step S44 specifically includes the following steps:

[0026] S51. Obtain the HMAC from the HTTP request and verify permissions;

[0027] S52 and base64 decoding to obtain key information;

[0028] S53. Query the key data in the database to determine if it exists. If it does not exist, return a failure message; if it exists, obtain the decrypted ciphertext and return the decrypted ciphertext.

[0029] A key-based elastic file system authentication device includes a configuration key module, an RPC message module, a parameter verification module, and a key verification module, wherein:

[0030] The configuration key module is used to configure the file system configuration file on the NFS server after the user successfully sends the key created for the file system to the elastic file service from the elastic file management platform.

[0031] The RPC message module is used by the NFS server to receive RPC requests sent by the NFS client after executing the mount command;

[0032] The parameter validation module is used to receive RPC requests, parse the parameters, and validate the parameters.

[0033] The key verification module is used by the NFS server to send a request to the key server. The key server verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected.

[0034] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0035] The mount request is authenticated by verifying the key. If the verification passes, the mount request is deemed legitimate; if the verification fails, the mount request is rejected. By combining the key with the NAT gateway for permission authentication, it is possible to determine which user's virtual machine issued the mount request. This solves the problem of lack of control over permissions in the traditional NFS protocol, realizes accurate permission authentication on the NFS server, and significantly improves the accuracy of elastic file system authentication. Attached Figure Description

[0036] Figure 1 This is a flowchart of the key-based elastic file system authentication method of the present invention;

[0037] Figure 2 This diagram illustrates the authentication method using the traditional NFS protocol in the CStor elastic file system of this invention.

[0038] Figure 3 This is a diagram illustrating the traditional NFS client RPC request encapsulation method of the present invention;

[0039] Figure 4 This is a diagram of the traditional NFS protocol network IP packet format of the present invention;

[0040] Figure 5 This is a diagram of the key-based elastic file system of the present invention;

[0041] Figure 6 This is a diagram illustrating the encapsulation of keys into an RPC framework for this invention.

[0042] Figure 7 This is a structural diagram of the key encapsulation in the data packet for the file system of the present invention;

[0043] Figure 8 This is a flowchart illustrating the NFS mountd mount request verification method of the present invention.

[0044] Figure 9 This is a flowchart illustrating the key verification process between the NFS server and the key server in this invention. Detailed Implementation

[0045] This invention proposes a key-based elastic file system authentication method and apparatus. By combining key authentication with NAT gateway authentication, it distinguishes NFS mount requests from different user virtual machines, achieving more precise permission control compared to the traditional NFS protocol.

[0046] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0047] Example 1

[0048] A key-based authentication method for a resilient file system includes the following steps:

[0049] S1. After the user successfully sends the key created for the file system to the elastic file service on the elastic file management platform, the NFS server configures the file system.

[0050] S2. The NFS server receives the RPC request sent by the NFS client after executing the mount command;

[0051] S3. Receive RPC request, complete parameter parsing, and verify parameters;

[0052] S4. The NFS server sends a request to the key server, which verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected.

[0053] The configuration file in S1 includes: file system information and file system key information.

[0054] In this embodiment, as Figure 2 As shown, the CStor Elastic File System uses the traditional NFS protocol for authentication. The user created file system 1 in the console interface. After file system creation, the CStor Elastic File Service created a rule configuration file for file system 1. The rule configuration file content is as follows: In the configuration file, a default rule was created in the fs1 file system 1 under the mnt directory, granting permissions to mount the file system to NAT gateways 2.2.2.1 and 2.2.2.2. rw represents a read-write file system, and root_squash indicates that when accessed as the root administrator, it is mapped to an anonymous user on the NFS server.

[0055]

[0056] Elastic File Service creates default rules that grant all NAT gateways permission to mount file systems. All virtual machines can access the file system through the NAT gateway. Before using the elastic file system, the virtual machine executes the `mount` command. The `mount` command is as follows: `-t nfs` indicates that the file system type is NFS; `-o` allows specifying additional mounting options; `async` indicates that the file system uses an asynchronous memory mechanism; `noatime` indicates that the inode access time is not updated on each access; `nodiratime` indicates that the directory's `atime` is not updated on each access; `wsize = 1048576` represents the grid write size.

[0057] The `mount` command includes mount parameters, which the `mount` process parses. Figure 3 As shown, the RPC request is encapsulated according to the mount parameters, sent to the NFS server, and the mount command is executed. After successfully mounting the file system, users can use the Elastic File Service as if it were a local file system. Figure 2 VM1, VM2, VM3, VM4, VM5, and VM6 can all mount and access the Elastic File System through the NAT gateway, but VM6 cannot access the gateway or the file system.

[0058] CStor Elastic File System uses the traditional NFS protocol for authentication, which has the problem of not being able to distinguish between virtual machines and access control. The permissions of the elastic file system are opened to all gateways, and virtual machines under the gateways can mount and modify the elastic file system without implementing access control.

[0059] To address the aforementioned problems, this invention improves upon traditional NFS protocol authentication methods by using keys, creating a key for each file system, such as... Figure 5 As shown, the user binds the key Secret001 to file system 1 in the console interface. The key is distributed to the elastic file service through the elastic file management platform. After the key is successfully distributed, the NFS server configures the file system configuration file. The configuration file content is as follows: In the configuration file, the key is configured in file system 1 fs1 under the mnt directory, granting virtual machines with NAT gateways of 2.2.2.1 and 2.2.2.2 and possessing the key Secret001 permission to mount the file system. rw is a read-write file system, and root_squash indicates that when accessed as the root administrator, it is mapped to an anonymous user on the NFS server.

[0060] The configuration file specifies that only users who possess both file system 1 information and key Secret001 information can mount the file system in the virtual machine. Figure 5 In the above, VM1, VM4, and VM5 can mount file systems, VM2 and VM3 can access the NAT gateway but cannot access the file system, and VM6 cannot access the NAT gateway and cannot access the file system.

[0061] This invention solves the problem that the NFS server cannot identify which virtual machine issued the mount request by combining a key with a NAT gateway. It distinguishes mount requests from different user virtual machines, provides a more accurate authentication method, and improves the accuracy of elastic file system authentication.

[0062] like Figure 1 As shown, after configuring the NFS server, the NFS client executes the mount command, encapsulates dirpath and secret into rpc_message, and sends it to the NFS server via an RPC request. The NFS server parses the parameters, verifies the parameters, sends a request to the key server to verify the key, and the key server returns the decrypted ciphertext. The server then compares the decrypted ciphertext with the key information to determine whether the mount request is valid.

[0063] S2 specifically includes the following steps:

[0064] S21. The NFS client executes the mount command to parse the key;

[0065] S22: The NFS client encapsulates the dirpath and secret into rpc_message and sends an RPC request to the NFS server.

[0066] The mount command in S21 includes: mount parameter, secret parameter, or secretFile parameter.

[0067] S22 encapsulation of the secret specifically involves the NFS client encapsulating the secret into the data packet within the IP message.

[0068] After S2 executes the mount command, it also includes replacing the Source IP in the IP header of the IP packet with the NAT gateway address.

[0069] In this embodiment, when a user mounts a file system through an NFS client, the `mount` command is executed to complete key resolution, such as... Figure 6 As shown, the key is parsed and encapsulated into an rpc_message, which is then sent to the NFS server via RPC. Figure 7 As shown, when encapsulating the key, the secret is placed in the data packet within the IP message, such as... Figure 4 As shown, after the mount command is executed successfully, the Source IP in the IP Header of the network packet is replaced with the NAT gateway address.

[0070] The mount command includes either traditional NFS mount parameters and the secret parameter, or traditional NFS mount parameters and the secretFile parameter. The two mount commands are as follows: -t nfs indicates that the file system type to be mounted is NFS; -o indicates that additional mount options can be specified; async indicates that the file system uses an asynchronous memory mechanism; noatime indicates that the inode access time is not updated on each access; nodiratime indicates that the atime of the current directory is not updated on each access; wsize=1048576 indicates the grid write size; secret is used to transmit the key; secretFile transmits the key as a key file, storing the key content in the file.

[0071]

[0072] In S4, sending a request specifically involves the NFS server calculating the HTTP request parameters based on the secret and the AK and SK in the NFS configuration, and then sending the request to the key server.

[0073] S4 specifically includes the following steps:

[0074] S41. Combine the user ID, mounting key, and AK, sort the parameters, and concatenate them with \n. Perform MD5 and base64 operations on the concatenation result.

[0075] S42. Concatenate the calculation result, request path, and time using \n;

[0076] S43. Use SK to encrypt the result of S42 using Hmac;

[0077] S44. The encryption result is placed in the HTTP request header and an HTTP request is sent to the key server, which then performs key verification.

[0078] In this embodiment, as Figure 8 As shown, the NFS server verifies the parameters. In addition to verifying the source IP address, it also needs to send a request to the key server to verify the key. The key verification is not a simple verification by sending the key information to the key server via an HTTP request. Instead, it calculates the HTTP request parameters using the secret and the AK and SK in the NFS configuration and sends the request to the key server.

[0079] In S44, the key server completes key verification through the following steps:

[0080] S51. Obtain the HMAC from the HTTP request and verify permissions;

[0081] S52 and base64 decoding to obtain key information;

[0082] S53. Query the key data in the database to determine if it exists. If it does not exist, return a failure message; if it exists, obtain the decrypted ciphertext and return the decrypted ciphertext.

[0083] In this embodiment, as Figure 9 As shown, the key server returns the decrypted ciphertext corresponding to the secret. The key information in the NFS configuration file is compared with the decrypted ciphertext. If they match, the mount request is deemed valid; otherwise, the mount request is rejected.

[0084] A key-based elastic file system authentication device includes a configuration key module, an RPC message module, a parameter verification module, and a key verification module, wherein:

[0085] The configuration key module is used to configure the file system configuration file on the NFS server after the user successfully sends the key created for the file system to the elastic file service from the elastic file management platform.

[0086] The RPC message module is used by the NFS server to receive RPC requests sent by the NFS client after executing the mount command;

[0087] The parameter validation module is used to receive RPC requests, parse the parameters, and validate the parameters.

[0088] The key verification module is used by the NFS server to send a request to the key server. The key server verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected.

[0089] In this embodiment, the user creates a file system and a key for the file system in the console interface. The key is distributed to the elastic file service through the elastic file management platform. After the key is successfully distributed, the NFS server creates a rule configuration file for the file system. Before using the file system, the virtual machine needs to execute a mount command and mount the file system to the local directory through the NFS client. The virtual machine sends a mount request to the NFS server. After receiving the request, the NFS server completes parameter parsing and verifies the parameters. In addition to verifying the source IP address, it also needs to send a request to the key server to verify the key. The key server returns the decryption password, which is compared with the key information in the configuration file to determine whether they match. The mount request is then processed based on the comparison result.

[0090] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0094] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0095] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A key-based elastic file system authentication method, characterized in that, Includes the following steps: S1. After the user successfully sends the key created for the file system to the elastic file service on the elastic file management platform, the NFS server configures the file system. S2. The NFS server receives the RPC request sent by the NFS client after executing the mount command; S3. Receive RPC request, complete parameter parsing, and verify parameters; S4, the NFS server sends a request to the key server, which verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected. Specifically, S2 includes the following steps: S21. The NFS client executes the mount command to parse the key; S22: The NFS client encapsulates the dirpath and secret into rpc_message and sends an RPC request to the NFS server. Specifically, S4 includes the following steps: S41. Combine the user ID, mounting key, and AK, sort the parameters, and concatenate them with \n. Perform MD5 and base64 operations on the concatenation result. S42. Concatenate the calculation result, request path, and time using \n; S43. Use SK to encrypt the result of S42 using Hmac; S44. The encryption result is placed in the HTTP request header and an HTTP request is sent to the key server, which then performs key verification.

2. The key-based elastic file system authentication method as described in claim 1, characterized in that, The configuration file in S1 includes: file system information and file system key information.

3. The key-based elastic file system authentication method as described in claim 1, characterized in that, The mount command in S21 includes: mount parameters, secret parameters, or secretFile parameters.

4. The key-based elastic file system authentication method as described in claim 1, characterized in that, The S22 encapsulation of the secret specifically refers to the NFS client encapsulating the secret into the data packet within the IP message.

5. The key-based elastic file system authentication method as described in claim 1, characterized in that, After S2 executes the mount command, the following steps are also included: replacing the Source IP in the IP Header of the IP packet with the NAT gateway address.

6. The key-based elastic file system authentication method as described in claim 1, characterized in that, The specific process of sending a request in S4 is as follows: The NFS server calculates the HTTP request parameters based on the secret and the AK and SK in the NFS configuration, and sends the request to the key server.

7. The key-based elastic file system authentication method as described in claim 1, characterized in that, The key server in S44 performs key verification specifically through the following steps: S51. Obtain the HMAC from the HTTP request and verify permissions; S52 and base64 decoding to obtain key information; S53. Query the key data in the database to determine if it exists. If it does not exist, return a failure message; if it exists, obtain the decrypted ciphertext and return the decrypted ciphertext.

8. A key-based elastic file system authentication device, comprising a configuration key module, an RPC message module, a parameter verification module, and a key verification module, wherein: The configuration key module is used to configure the file system configuration file on the NFS server after the user successfully sends the key created for the file system to the elastic file service from the elastic file management platform. The RPC message module is used by the NFS server to receive RPC requests sent by the NFS client after executing the mount command; The parameter validation module is used to receive RPC requests, parse the parameters, and validate the parameters. The key verification module is used by the NFS server to send a request to the key server. The key server verifies the key and determines whether the decrypted ciphertext matches the key information in the configuration file. If they match, the mount request is valid; otherwise, the mount request is rejected. Specifically, the RPC message module is used by the S21 and NFS clients to execute the mount command and parse the key. S22: The NFS client encapsulates the dirpath and secret into rpc_message and sends an RPC request to the NFS server. Specifically, the key verification module is used to combine the user ID, the mounted key, and the AK in S41, sort the parameters, concatenate them with \n, and perform MD5 and base64 on the concatenation result. S42. Concatenate the calculation result, request path, and time using \n; S43. Use SK to encrypt the result of S42 using HMAC; S44. Put the encrypted result into the HTTP request header and send the HTTP request to the key server, which will then perform key verification.

Images