Cross-domain identity management method for high-performance computing cluster

Abstract

This application provides a cross-domain identity management method for high-performance computing clusters. The method includes: responding to a job request submitted by a platform user, determining the minimum authorized capability set and restricted workspace scope required for the job request; determining the estimated runtime of the job and determining a credential validity period matching the estimated runtime; applying to a cluster certificate authority for the issuance of a temporary credential based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the credential validity period; and responding to the platform initiating an operation request to the high-performance computing cluster carrying the temporary credential, with the cluster side executing a proxy to intercept the operation request and verifying the operation request according to the minimum authorized capability set and the restricted workspace scope. This method can at least avoid the problem of insufficient permissions due to manual configuration causing job failures, as well as the security risks caused by excessive permissions.

Description

Technical Field

[0001] This application relates to the interdisciplinary field of high-performance computing and security authentication, specifically to a cross-domain identity management method for high-performance computing clusters. Background Technology

[0002] As scientific computing is increasingly offered as a SaaS (Software as a Service) or web platform, more and more computing tasks are being centrally handled by the platform. The platform backend then submits and manages these jobs to the High Performance Computing (HPC) cluster on behalf of numerous platform users. In this architecture, the platform process needs to securely execute cluster operations (including creating workspaces, uploading input files, submitting jobs, querying status, and sending back results) using the identity of the cluster system user corresponding to the platform user, while simultaneously meeting multiple security requirements such as the principle of least privilege, controllable lifecycle, trusted identity, and audit traceability.

[0003] Because the platform domain and cluster domain belong to two independent identity management and access control systems, there is no native trust relationship between the user system on the platform side and the Linux system user system on the cluster side. Therefore, a cross-domain identity delegation mechanism is needed to bridge the two domains. Currently, the industry mainly offers the following solutions to address this need:

[0004] (1) User credential scheme for long-term storage cluster system of platform

[0005] In this scheme, the platform database or keystore permanently stores the SSH (Secure Shell) private key or login password for each platform user's corresponding cluster system user. When the platform needs to perform cluster operations, it directly reads the corresponding private key or password and initiates an SSH connection.

[0006] The drawbacks of this solution are as follows: First, the credentials are exposed for a long time. Once the platform is compromised, the cluster identities of all platform users can be illegally abused, and the credentials can be reused indefinitely. Second, the permissions are too broad. The platform obtains full shell permissions for the cluster system users, which far exceeds the actual need for "submitting a single job". Third, revocation is difficult. Once the credentials are issued, they are valid for a long time and can still be used after the job is completed. It is impossible to make them expire immediately after the job ends.

[0007] (2) Global Shared Cluster System User Pool Scheme

[0008] In this scheme, all platform users share one or more pre-created cluster system users, and the platform uses this shared identity to uniformly execute cluster operations for all users.

[0009] The shortcomings of this solution are: it cannot trace specific operational behaviors by platform user, it cannot achieve user-level permission isolation and quota control, and it does not meet security audit and compliance requirements.

[0010] In view of the above, this application is hereby submitted. Summary of the Invention

[0011] This application aims to provide a cross-domain identity management method for high-performance computing clusters, which can at least avoid the problem of insufficient permissions caused by manual configuration leading to job failure, as well as the security risks caused by excessive permissions.

[0012] In a first aspect, embodiments of this application provide a cross-domain identity management method for high-performance computing clusters, including: in response to a job request submitted by a platform user, determining the minimum set of authorized capabilities and the restricted workspace scope required for the job request;

[0013] Determine the estimated runtime of the operation and determine the validity period of the voucher that matches the estimated runtime;

[0014] Based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the certificate validity period, apply to the cluster certificate authority for the issuance of a temporary certificate, and distribute the minimum authorized capability set and restricted workspace scope to the cluster-side execution agent;

[0015] In response to the platform sending an operation request to the high-performance computing cluster with temporary credentials, the cluster side executes a proxy to intercept the operation request and verifies the operation request based on the minimum authorized capability set and the restricted workspace scope. The high-performance computing cluster is controlled to respond to the operation request only if the operation request meets the authorized scope.

[0016] Secondly, embodiments of this application also provide an electronic device, the electronic device comprising:

[0017] Processor and memory;

[0018] The processor executes the steps of the cross-domain identity management method for high-performance computing clusters as described in any embodiment by invoking programs or instructions stored in the memory.

[0019] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a program or instructions that cause a computer to perform the steps of the cross-domain identity management method for high-performance computing clusters as described in any embodiment.

[0020] In summary, this application proposes a cross-domain identity management method for high-performance computing clusters. Specifically, in response to a job request submitted by a platform user, the method determines the minimum authorized capability set and restricted workspace scope required for the job request; it determines the estimated runtime of the job and the validity period of the credential matching the estimated runtime; based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the credential validity period, it applies to the cluster certificate authority for the issuance of a temporary credential and distributes the minimum authorized capability set and restricted workspace scope to the cluster-side execution agent; in response to the platform initiating an operation request to the high-performance computing cluster with the temporary credential, the cluster-side execution agent intercepts the operation request and verifies it according to the minimum authorized capability set and restricted workspace scope. Only when the operation request conforms to the authorized scope is the high-performance computing cluster controlled to respond to the operation request. This avoids the problem of insufficient permissions due to manual configuration causing job failures, as well as the security risks caused by excessive permissions. Attached Figure Description

[0021] Figure 1 This is a flowchart of a cross-domain identity management method for high-performance computing clusters provided in an embodiment of this application;

[0022] Figure 2 This is a flowchart of another cross-domain identity management method for high-performance computing clusters provided in the embodiments of this application;

[0023] Figure 3 This is a schematic diagram of the structure of a cross-domain identity management system for high-performance computing clusters provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] Example 1

[0028] Figure 1 This is a flowchart illustrating a cross-domain identity management method for high-performance computing clusters provided in an embodiment of this application. See also... Figure 1The cross-domain identity management method for high-performance computing clusters specifically includes the following steps:

[0029] S110. In response to a job request submitted by a platform user, determine the minimum set of authorized capabilities and the restricted workspace scope required for the job request.

[0030] The minimum authorized capability set refers to the set of atomic operation permissions that do not contain redundant permissions, which are necessary to ensure the normal operation of a single computation job.

[0031] A restricted workspace scope refers to the additional path-level access boundary restrictions applied to file operations within the minimum authorized capability set. This is used to strictly confine the scope of operations performed by credentials to the file system area dedicated to this job.

[0032] Specifically, the execution of a cluster command (responding to a job request submitted by a platform user requires at least one cluster command) often implicitly includes several necessary sub-capabilities. Granting only directly written commands will lead to job failure due to the lack of implicit capabilities; conversely, relaxing authorization to avoid failure will result in excessive permissions. To address this, this embodiment proposes starting with the capabilities directly requested by the job, progressively supplementing implicit sub-capabilities along the command capability dependency graph, while converging the access scope of each capability within the job's workspace. This is then subjected to sufficiency and minimum constraints, intersecting with available permissions to obtain a set of authorizations that is both sufficient and minimal. This overall process is called "minimum capability set derivation," and the internal step of eliminating out-of-bounds or redundant items is called "minimum pruning." The command capability dependency graph can be preset according to the scheduler type or dynamically learned and updated.

[0033] Core elements and their coordination:

[0034] Capability dependency graph. Using atomic capabilities (command execution, file read, file write, path access, etc.) as nodes, directed edges represent the dependency relationships where exercising a preceding capability necessarily requires a subsequent capability. The graph has two sources: First, a pre-set static dependency table maintained by the administrator according to the scheduler type, showing commands and their implicit sub-capabilities. Preferably, the submitted command implicitly includes the following sub-capabilities: reading the job script, creating the output directory, writing to standard output and error files, and reading a specified input data path. This static dependency table is updated with scheduler version upgrades. Second, dynamic learning, which deduces the actual resources accessed by the command from historical execution logs, supplementing or correcting dependencies missing in the static table. When conflicts arise, such as a discrepancy between dynamically learned dependencies and the static table, in a preferred embodiment, the pre-set static table prevails, and the differences are recorded in a list awaiting manual review to avoid log noise introducing unauthorized dependencies; the administrator decides whether to include them in the static table based on the review results.

[0035] First, for a certain operational capability, candidate paths are determined, and the job workspace is the specified path; the intersection of the candidate path and the prefix of the specified path is the final restricted scope of the capability.

[0036] In one implementation, the candidate path is the full path under the user's home directory in the cluster system, and the job workspace is the specific job path under the home directory. The intersection of the path prefixes of the two is the part under the job path prefix.

[0037] The method for determining the direct request capability set is as follows: Parse the job object, determine the initial command capabilities based on the job type, and add corresponding capabilities according to data transmission requirements. The correspondence between job type and initial command capabilities includes: submission-type jobs correspond to job submission commands; monitoring-type jobs correspond to job status query commands; and control-type jobs correspond to job cancellation commands. Data transmission requirements include: if the job needs to upload input data, add file upload and write capabilities; if the job needs to download result data, add file download and read capabilities.

[0038] In a preferred embodiment, the job submission command includes sbatch, the job status query command includes squeue and sacct, the job cancellation command includes scancel, and the file upload / write capability and file download / read capability are implemented based on scp.

[0039] The derivation process starts with the directly requested capability set and processes them item by item: First, calculate the restricted scope of each capability, which is the intersection of the candidate path and the specified path prefix. If the scope is empty and the capability is a file-related capability, it is discarded. For file-related capabilities, an empty scope means that their implicit access has exceeded the workspace of this job, making them both useless and out of bounds; granting them would only increase risk. For non-file-related capabilities, such as pure command execution and status queries, their validity does not depend on the path scope; an empty scope is not used as a basis for discarding, and they are included normally according to the command whitelist. The retained capabilities, along with their restricted scopes, are added to the result set, and their dependent sub-capabilities are included in the pending processing scope to continue expanding until no new capabilities are added. A sufficiency check is then performed to confirm that the minimum sub-capabilities necessary for executing the job's direct commands are included; otherwise, issuance is rejected and an insufficient permission message is displayed. Next, a minimum pruning is performed, eliminating redundant items in the result set that cannot be reached from the directly requested capabilities. Finally, the intersection of the result set with the user's actual available permissions and the cluster's actual available capabilities is taken, retaining only the capabilities common to all three, resulting in the final authorized capability set. The user's actual available permissions refer to the set of permissions assigned to the user by the administrator on the platform side, such as being allowed to submit jobs but prohibited from deleting other people's jobs; the cluster's actual available capabilities refer to the functions that the cluster nodes currently have, such as some clusters only supporting specific job submission methods.

[0040] The final capability set is encoded into a mandatory command authorization list (command whitelist) and path prefix constraints for each capability, which are then written into the certificate field during the credential issuance process.

[0041] In general, determining the minimum authorized capability set and restricted workspace scope required for a job request includes: determining the operation type of the job request; using the request command corresponding to the operation type as a reference, determining a first candidate capability set based on the dependency graph between the command and the implicit sub-capabilities; and for each capability in the first candidate capability set, determining its restricted workspace scope. If the restricted workspace scope is empty and the capability is a file-related capability, then the capability is deleted from the first candidate capability set, and the remaining capability items are determined as the second candidate capability set. The intersection of the capability items in the second candidate capability set with the capability items that the platform user has access to and the capability items that the cluster system has access to obtain the minimum authorized capability set required for the job request.

[0042] Through hierarchical derivation based on capability dependencies, credentials only contain the commands and restricted workspace paths required for the current job. For example, monitoring credentials cannot be used to submit jobs or delete files. This mechanism automatically completes implicit sub-capabilities and prunes out-of-bounds access, avoiding job failures due to insufficient permissions caused by manual configuration, as well as security risks caused by excessive permissions.

[0043] S120. Determine the estimated runtime of the operation and determine the validity period of the voucher that matches the estimated runtime.

[0044] If the job request includes a declared runtime, the declared runtime is determined as the estimated runtime; if the job request does not include a declared runtime, the estimated runtime is determined based on the runtime of similar historical jobs.

[0045] If the estimated runtime exceeds the upper limit threshold, the temporary certificate will be recorded as a renewal type and renewed when the temporary certificate is detected to be expiring. If the estimated runtime does not exceed the upper limit threshold, the temporary certificate will be recorded as a non-renewal type and set to an invalid state when the temporary certificate is detected to be expiring.

[0046] Fixed-term vouchers cannot be adapted to jobs of varying durations. Too short a duration can cause permissions to expire midway through a long job, while too long a duration increases the exposure time of permissions. To address this issue, this embodiment proposes a validity period decision strategy: if the job declares an estimated runtime, the declared value is used as the estimated runtime; otherwise, the 90th percentile of the runtime of similar historical jobs is used as the estimated runtime. The 90th percentile means that 90% of similar historical jobs have runtimes lower than this value. In a preferred embodiment, similar jobs are categorized by a combination of job type, submission queue, and job size. The job size can be a range of application nodes or cores. When there are insufficient historical samples for a certain type of job or it is in a cold start phase with no available historical samples, a default estimated runtime is used. Preferably, the default estimated runtime is the default job time limit for the queue or a conservative preset value.

[0047] The initial validity period is obtained by multiplying the estimated duration by a redundancy coefficient and adding a fixed buffer duration, which covers queuing and startup margins, and then limiting it to a preset minimum and maximum validity period. Preferably, the redundancy coefficient is 1.2. If the estimated duration exceeds the maximum validity period threshold, the voucher is marked as renewable, and its initial expiration time is the current time plus the maximum validity period; otherwise, it is marked as non-renewable, and its expiration time is the current time plus the initial validity period. The final output includes the voucher's effective time, expiration time, and whether it is renewable.

[0048] Heartbeat and Renewal Rules: A heartbeat is a survival signal generated by the execution agent periodically probing whether a job is still alive. The execution agent periodically probes whether the corresponding job's process is still running, or queries the scheduler to see if the job is still in a pending or running state, receiving one heartbeat per probe. If a survival signal is not received for several consecutive probes, the job is considered disconnected and renewal is stopped. Preferably, "several consecutive probes" specifically refers to two consecutive probes.

[0049] The renewal rules are as follows: Before a voucher expires, the voucher lifecycle management module actively queries the corresponding job status. When the voucher is marked as renewable, the job is in a pending or running state, and the heartbeat is normal, a short-term voucher with the same permission scope is reissued, and the expiration time is updated. The validity period of the reissued short-term voucher remains the maximum validity period, which is 2 hours from the current time. If the job has ended or the heartbeat connection is lost, the voucher will not be renewed and will expire naturally.

[0050] Non-renewable but not yet completed branch: When a job is marked as non-renewable but its runtime unexpectedly exceeds the initial validity period, the default behavior is that the certificate expires and becomes invalid, and an alarm event is recorded for operation and maintenance intervention, without automatically extending the privileges. This situation can be avoided in advance by the aforementioned long job marking and renewal mechanism, that is, jobs whose estimated duration exceeds the maximum validity period threshold are marked as renewable at the time of issuance, thereby avoiding job interruption due to expiration.

[0051] When determining the estimated runtime of a job, in addition to the 90th percentile runtime of similar jobs, the runtime can also be predicted using historical mean plus standard deviation, or by using a regression / machine learning model based on the job input size.

[0052] The above strategy ensures that the stability and security of long jobs are balanced: the validity period is adaptively generated according to the estimated duration of the job, and the long job is dynamically renewed through survival status verification so as not to be interrupted midway, while avoiding long-term permission exposure caused by fixed long validity periods.

[0053] The above strategy is configurable, and the configurable parameters are shown in Table 1.

[0054] Table 1

[0055]

[0056] The credential lifecycle is strictly tied to the job, and it becomes invalid immediately upon job completion. The platform no longer stores private keys or passwords that can be reused indefinitely. If the platform is compromised, the loss is limited to the remaining time of the jobs in progress, significantly reducing security risks.

[0057] S130. Based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the certificate validity period, apply to the cluster certificate authority for the issuance of a temporary certificate, and distribute the minimum authorized capability set and the restricted workspace scope to the cluster-side execution agent.

[0058] Temporary credentials are carried by user certificates issued by the cluster certificate authority. The user certificate fields include at least: cluster system user identifier, credential validity period, executable file path of the capability execution wrapper, job identifier, and credential identifier.

[0059] The capability execution wrapper is a functional component of the cluster-side execution agent. It is used to intercept operation requests carrying the temporary credentials, verify the operation requests according to the minimum authorized capability set and the restricted workspace scope, and only execute compliant requests.

[0060] In a preferred embodiment, the temporary credential is carried by a short-term SSH user certificate issued by the cluster CA. The capability set and validity period are naturally encoded in the certificate field, requiring no additional modification to the SSH protocol. Examples of certificate fields are shown in Table 2.

[0061] Table 2

[0062]

[0063] The capability execution wrapper is a software component deployed on the cluster side and is part of the execution agent module. Its function is to intercept all connection requests carrying credentials, perform mandatory verification according to the authorization whitelist and path prefix constraints, and only allow compliant commands to be executed.

[0064] In a preferred embodiment, the value of the force-command field is the installation path of the capability execution wrapper, such as / opt / cdt-agent / cap-wrapper.

[0065] When issuing certificates, extended capabilities such as interactive terminal permissions and port forwarding permissions are not granted. Interactive terminal permissions correspond to the permit-pty field in the certificate, and port forwarding permissions correspond to the permit-port-forwarding field; these permissions are not granted to prevent obtaining operational capabilities beyond the job's requirements.

[0066] The minimum capability set distribution path: The `force-command` field only serves a "routing" function, forcing a connection into the wrapper, and does not carry specific authorization content itself. The minimum authorized capability set (command whitelist and path prefix constraints for each capability) output by the capability derivation module is synchronously distributed to the cluster side during the credential issuance process for use by the wrapper during verification. In a preferred embodiment, the credential proxy module pushes the authorization configuration file associated with the credential identifier to the cluster-side execution proxy, including the command whitelist and path prefix constraints; the wrapper reads the corresponding configuration based on the credential identifier in the `extension` field during verification. In another preferred embodiment, the command whitelist and path prefix constraints are encoded and written into the `extension` field, and the wrapper directly parses them from the certificate. Both methods achieve a closed loop of "derivation result → cluster-side verification," and the choice of method does not affect the technical solution.

[0067] All fields in the table above are standard fields for SSH certificates. In this embodiment, the `principals` field is filled with the mapped cluster system user determined by the identity binding module, the `valid-before` field is filled with the result of the validity period decision module, and the credential identifier in the `extension` field is used to associate with the issued authorization configuration.

[0068] For example, the division of responsibilities among the components in the issuance process can be seen in Table 3.

[0069] Table 3

[0070]

[0071] The coordinating party for issuance is the platform-side credential agent module, not the cluster-side execution agent module. The execution agent does not assume the responsibility of "deciding whether to issue or organize the certificate content" during the issuance phase; it only assists in distributing the authorization configuration (and optionally forwarding requests).

[0072] The cluster CA's issuance method: The cluster CA is an independent signature service deployed on the cluster side, pre-holding the cluster CA key pair (public key / private key). The public key is configured in the SSH trust chain of each node in the cluster for subsequent signature verification; the private key is used only for issuance and is exclusively kept by the cluster CA service. Upon receiving a valid certificate issuance request, the cluster CA uses its private key to digitally sign the certificate fields (principals, valid-before, force-command, source-address, extension, etc.) in the request, generating a short-lived SSH user certificate and returning it. The issuance request is organized and submitted by the credential proxy module. In one preferred embodiment, the submission method is to directly call the cluster CA's signature interface via a secure channel; in another preferred embodiment, the credential proxy module forwards the request to the cluster CA via the execution proxy module.

[0073] After receiving the results from the preceding modules (capability set and restricted scope, validity period and renewability flags, job identifier and credential identifier, and valid identity mapping binding token), the credential agent module first verifies that the binding token is valid and has not expired. Based on this, it organizes a certificate issuance request and completes the issuance and authorization process according to the following steps:

[0074] The first step is to organize the certificate fields: fill in the mapping cluster system username in principals, fill in the expiration time in valid-before, point force-command to the capability execution wrapper path, write the job identifier and credential identifier into extension, and specify source-address.

[0075] The second step is to distribute the minimum capability set: the command whitelist and path prefix constraints output by the capability inference module are simultaneously distributed to the cluster side. In one preferred embodiment, an authorization configuration file with the credential identifier as the key is pushed to the cluster-side execution agent; in another preferred embodiment, the above content is encoded into the extension field.

[0076] The third step is to submit an issuance request and obtain a certificate: The credential agent module submits the organized certificate fields as an issuance request to the cluster CA; after verifying that the request source is legitimate and the fields are compliant, the cluster CA signs it with its private key and returns a short-term user certificate.

[0077] The issuance result is returned to the credential agent module and cached according to the credential identifier (including certificate handle, expiration time, renewable flag, and bound job identifier) ​​for subsequent execution, renewal, and revocation. Simultaneously, the audit and reconciliation module records the issuance triplet. This process is repeated during renewal, issuing a new certificate with the same scope of permissions but an extended expiration time.

[0078] In addition to short-lived SSH certificates issued by the cluster CA, temporary credentials can also be carried in the following forms: range-bound JWTs issued via the SlurmREST API, one-time PAM tokens, and temporary keys derived from KMS.

[0079] S140. In response to the platform sending an operation request to the high-performance computing cluster with temporary credentials, the cluster side executes an agent to intercept the operation request and verifies the operation request based on the minimum authorized capability set and the restricted workspace scope. The high-performance computing cluster is controlled to respond to the operation request only if the operation request meets the authorized scope.

[0080] For example, the operation request carrying the temporary credential is imported into the capability execution wrapper according to the executable file path of the capability execution wrapper; the capability execution wrapper parses the original command of this operation request and the file path involved, and compares it item by item with the issued minimum authorized capability set and restricted workspace scope;

[0081] After successful verification, the operation is executed and a receipt verification value is generated. The receipt verification value is the result of hashing the key fields of the operation record, which is used by the platform to verify the authenticity and completeness of the record.

[0082] Specifically, when the platform initiates a connection to the cluster to execute operations using the issued certificate, the cluster-side execution agent performs the following verifications before execution: First, it verifies the certificate signature is valid and the current time is within the valid-before field using the cluster CA's public key; second, it queries the CRL (Certificate Revocation List) to confirm that the credential identifier has not been revoked; third, based on the certificate's force-command setting, all connections are forced into the capability execution wrapper instead of directly executing the user-submitted command; fourth, the wrapper reads the corresponding authorization configuration (or directly decrypts it from the extension) based on the credential identifier in the extension field of the certificate. The process involves several steps: First, the wrapper parses the original command of the current connection request (in SSH scenarios, SSH automatically saves the command the requester originally intended to execute to the SSH_ORIGINAL_COMMAND environment variable, from which the wrapper reads it), compares it item by item with the authorized command whitelist, and compares the file paths involved with the path prefix constraints. Second, if the command is within the whitelist and the paths all fall under the restricted scope prefix, execution is allowed, and a receipt verification value for this operation is generated and reported to the platform. If the command exceeds the authorization limit or the path goes out of bounds, execution is rejected and an audit event is recorded.

[0083] The above verification is enforced before each operation is executed, and unauthorized / outbound requests cannot bypass the wrapper to reach the cluster directly.

[0084] Example 2

[0085] Based on the above embodiments, this embodiment adds the following step: "monitoring the running status of the job, and when the job is detected to have entered the final state of completion, failure, or cancellation, revoking the temporary credential and terminating the session connection established based on the temporary credential," to prevent permission leakage and improve security. Figure 2 As shown, the cross-domain identity management method for high-performance computing clusters includes the following steps:

[0086] S210. In response to a job request submitted by a platform user, determine the minimum set of authorized capabilities and the restricted workspace scope required for the job request.

[0087] S220. Determine the estimated runtime of the operation and determine the validity period of the voucher that matches the estimated runtime.

[0088] S230. Based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the certificate validity period, apply to the cluster certificate authority for the issuance of a temporary certificate, and distribute the minimum authorized capability set and the restricted workspace scope to the cluster-side execution agent.

[0089] S240. In response to the platform sending an operation request to the high-performance computing cluster with temporary credentials, the cluster side executes an agent to intercept the operation request and verifies the operation request based on the minimum authorized capability set and the restricted workspace scope. The high-performance computing cluster is controlled to respond to the operation request only if the operation request meets the authorized scope.

[0090] S250. Monitor the running status of the job. When the job is detected to have entered the final state of completion, failure, or cancellation, revoke the temporary certificate and interrupt the session connection established based on the temporary certificate.

[0091] Decoupling credentials from job lifecycles can lead to credentials remaining valid after a job ends, resulting in access control leaks. To address this, this embodiment proposes the following division of responsibilities for each component during the revocation process: The credential lifecycle management module acts as the primary coordinator, responsible for monitoring job status and anomaly signals, making revocation or renewal decisions, maintaining the CRL, and issuing revocation commands; the execution agent module is the cluster-side executor of the revocation commands, responsible for receiving revocation list synchronization, rejecting new connections with revoked credentials, and closing ongoing sessions and terminating associated processes. Together, they complete the "decision → issuance → execution" closed loop.

[0092] The voucher state machine has four core states: issued, in use, expired, and revoked. "Issued" means the voucher has been generated but not yet used; "In use" means it has been used for the first time and is within its validity period; "Expired" means it has exceeded its validity period and has not been renewed; and "Revoked" means it was actively revoked due to the completion of a task or an anomaly detection. The normal workflow is: issued → in use, then → expired or revoked.

[0093] Scenarios that trigger revocation: First, job final state trigger: the job is immediately revoked when it enters any of the final states of completion, failure, or cancellation. Second, anomaly trigger: the job is immediately revoked when unauthorized operation, access path out of bounds, abnormal access source, or abnormal operation frequency is detected. Third, orphan credential trigger: if the corresponding job cannot be found after the grace period has expired after the credential is issued (suspected that the job has not been actually implemented after issuance or that there has been a long-term disconnection between domains), it is determined to be an orphan credential and revoked.

[0094] Revocation execution process: The credential lifecycle management module updates the credential status to revoked and records the revocation reason; writes the credential identifier into the CRL and synchronizes it to the cluster-side execution agent; notifies the execution agent to interrupt all ongoing sessions corresponding to this credential; and records the revocation audit event.

[0095] Active session interruption mechanism: Each time execution is permitted, the execution agent registers an active session and process table with the credential identifier as the key, recording the SSH connection currently associated with that credential and its derived job processes. Upon receiving a revocation notification, the execution agent locates all associated sessions in the table based on the credential identifier, closes the corresponding SSH connection and terminates its derived associated processes, thereby ensuring that revocation not only prevents newly initiated operations but also immediately interrupts ongoing operations.

[0096] CRL Synchronization Mechanism: The revocation list is maintained by the platform-side credential lifecycle management module and synchronized to the cluster side via a proxy. In a preferred implementation, incremental synchronization is used: an incremental entry is pushed when a revocation event occurs, and a full calibration is performed as a fallback based on the status polling cycle to reduce synchronization latency. To address potential synchronization delays or failures, a triple fallback mechanism is implemented: the proxy locally persists the most recent CRL, and immediately pulls the difference after communication is restored; if the push fails, it is retried according to the backoff strategy; since temporary credentials have a very short validity period (constrained by T_max), even if the CRL is briefly out of sync, the credential will naturally expire, thus limiting risk exposure.

[0097] Furthermore, it also includes a cross-domain state consistency calibration step: when communication is interrupted or the state is inconsistent between the platform domain and the cluster domain, the state is determined according to the priority rule that the final state of the cluster takes precedence over the real-time state of the scheduling system, and the real-time state of the scheduling system takes precedence over the cached state of the platform; if the cluster does not respond within the set time, a grace period timer is started to wait, and if there is still no response after the grace period expires, it is treated as an orphan certificate and revocation is triggered.

[0098] The platform domain and cluster domain belong to two independent systems, and the status information regarding whether a job is still running may come from different channels and be inconsistent for short periods. Improper handling of inter-domain communication interruptions can lead to unauthorized cancellation of credentials (permission leakage) or erroneous cancellation (business interruption). To address this issue, this embodiment proposes a status judgment method: the credential lifecycle management module actively retrieves three types of status information according to the status polling cycle and determines whether the job is still running based on the priorities shown in List 4.

[0099] Table 4

[0100]

[0101] Judgment Rules: When the three sources are consistent, the status directly drives the renewal or revocation of the credential. When the three sources are inconsistent, the highest priority in Table 4 above applies: if the cluster's final state is "ended," the credential is revoked immediately; if the real-time scheduling status and the platform cache are inconsistent, the real-time scheduling status takes precedence and the platform cache is updated. If the cluster does not respond for a short period, a grace period timer (default 10 minutes) is started to wait and retry; if it recovers within the grace period, the credential is re-evaluated; if there is still no response by the expiration date, the credential is revoked as an orphan credential.

[0102] The above determination is completed by the credential lifecycle management module in each polling cycle: pull the final state of the cluster and the real-time status of the scheduling, and compare them with the platform cache; when a conflict occurs or a response cannot be obtained, the calibration process is entered according to the above rules, and the credential is revoked or renewed.

[0103] Furthermore, it also includes: triple binding and reconciliation steps; when a temporary voucher is issued, the voucher identifier, job identifier, and minimum authorized capability set are associated and stored to form a cross-domain triple basic record; each time an operation is executed on the cluster side, the binding token, job identifier, execution command, and return code are recorded and the verification value is sent back to the platform; the platform side performs reconciliation verification by associating the two domain records according to the job identifier, and triggers revocation when an anomaly is found.

[0104] Binding upon issuance: An audit binding token is generated upon issuance of the voucher and stored in association with the voucher identifier, job identifier, and authorized capability set information, forming a basic record of the voucher identifier, job identifier, and cluster operation triplet. Optionally, a hash chain-based record anti-tampering mechanism can be enabled: Each record is associated with the hash value of the previous record, forming a chain. If any record is tampered with, subsequent hash values ​​will not match, thus ensuring that the records are immutable.

[0105] Execution Receipt: Each time the execution agent on the cluster side performs an operation, it records the binding token, job identifier, node identifier, execution command, and return code information, and sends a verification value back to the platform side. This verification value is used by the platform side to verify the authenticity and integrity of the records on the cluster side. In a preferred embodiment, the verification value is the result of applying an HMAC operation to the key fields of the current operation record. The key fields include the binding token, job identifier, execution command, return code, and timestamp. The HMAC key is a reconciliation key pre-shared between the platform's audit and reconciliation module and the execution agent on the cluster side. The reconciliation key is issued during the execution agent deployment or identity binding phase and can be derived and rotated by KMS. The platform recalculates and compares the received records using the same key to determine whether the receipt was generated by a legitimate execution agent and whether the record has been tampered with.

[0106] Reconciliation and Verification: The platform-side audit and reconciliation module associates platform-side issuance records with cluster-side operation records according to the job identifier, verifying whether each operation falls within the authorized capabilities of the voucher, and whether the receipt verification value is consistent with the local recalculation. Optionally, the hash chain continuity is also verified. If any anomalies such as unauthorized operations, inconsistent receipts, or broken chains are found, the anomaly is marked and the voucher revocation process is triggered.

[0107] The cross-domain identity management method for high-performance computing clusters provided in this application offers the advantage of end-to-end traceability and compliance: the cross-domain binding and reconciliation mechanism of credentials, jobs, and operations ensures that every cluster operation can be traced back to a specific credential and job, supports cross-domain log consistency verification, and meets the compliance requirements for identity authentication, operation auditing, and access control. It also boasts strong robustness in abnormal scenarios: the state consistency calibration rules under inter-domain communication interruptions effectively avoid the risk of permission leakage when a job has ended but the credential remains valid, as well as the risk of business interruption due to accidental cancellation during long job execution.

[0108] Example 3

[0109] Based on the above embodiments, the method further includes: establishing an identity mapping relationship between platform users in the platform domain and cluster system users in the high-performance computing cluster domain, specifically including:

[0110] The platform domain and cluster domain each send random verification information to the applicant. After the applicant completes the response using the identity credentials of the corresponding domain, the system performs joint verification. After the verification is successful, a unique binding token is generated based on the key and a mapping relationship is established. The joint verification must simultaneously meet the following conditions: the platform domain signature verification is successful, the cluster domain response verification is successful, neither verification value has been used and the timestamp is within the valid window, and the user identifier carried in the platform domain response and the cluster domain response is consistent.

[0111] Static identity mapping is filled out unilaterally by the user and cannot prove that the applicant actually holds control of the corresponding cluster system user, posing a risk of binding the platform account to someone else or a cluster account without control. Once the mapping is established, all subsequent credentials will be issued with an incorrect cluster identity, constituting a systemic risk. To address this, this embodiment proposes a dual-domain independent issuance of verification information and joint verification method. Based on cryptographic algorithms, it proves that the applicant simultaneously controls the platform domain account and the declared cluster domain account, and has the ability to prevent replay attacks and man-in-the-middle attacks. After successful verification, a unique binding token is derived to establish the mapping relationship.

[0112] Optionally, the above process can be described as a joint verification of two certificates: the applicant must prove that he / she is indeed the owner of the platform account and the owner of the cluster account declared. Both are indispensable before the platform will allow the two accounts to be bound together.

[0113] Execution process: Phase 1 (Platform Domain Verification). The platform domain generates a random verification value and a timestamp and sends it to the applicant; the applicant uses the platform domain's identity credentials (such as the platform account private key or login token) to sign the concatenation of "verification value + platform user identifier + declared cluster system username" and generates a response to be returned to the platform domain.

[0114] In the second stage (cluster domain verification), the platform, through the cluster-side execution agent, writes a one-time random verification value to the home directory of the declared cluster system user (or requires the applicant to sign the verification value with the cluster system user's private key); the applicant completes the response as a cluster system user (reads the content of the verification file and sends it back, or returns the signature result), and submits it to the cluster-side execution agent for verification via the platform or directly.

[0115] The third stage is joint verification. Joint verification must meet the following conditions simultaneously, and binding will be rejected if any one of them is not met: the platform domain signature verification is passed; the cluster domain response verification is passed; neither verification value has been used and the timestamp is within the valid window, thus preventing replay attacks; the platform user identifier carried in the two domain responses is completely consistent with the cluster system username, thus preventing man-in-the-middle tampering.

[0116] The fourth stage involves deriving the binding token. After successful verification, the system uses the binding key as the key and performs HMAC (Hash-based Message Authentication Code) calculations on the identity mapping information to derive a unique binding token. This token, along with the identity mapping, is then stored in the identity binding table, and an expiration date is set. Preferably, the expiration date is 30 days by default, after which the dual-domain binding must be re-completed. Thereafter, all credential issuance must first verify that the binding token is still valid and has not expired; otherwise, issuance will be rejected.

[0117] The landing channel for cluster domain verification information: Dual-domain binding is a one-time pre-processing step before the establishment of the identity delegation system. At this time, the applicant may not yet have obtained the issued task-level temporary credential, nor does he / she have the regular cluster access capability issued by the platform. Therefore, the cluster domain verification in the second stage does not rely on the task-level temporary credential, but is completed using the applicant's original cluster login credentials, which are independent of this scheme. In a preferred embodiment, the platform side uses the cluster execution agent to write a one-time verification file to the home directory of the declared cluster user in a controlled manner. The verification file contains a random verification value generated by the platform; the controlled manner means that the agent is limited to performing only the restricted action of writing the verification file to the specified home directory, and no other operations are allowed. After logging in using his / her original cluster login method, the applicant reads the contents of the file and sends it back. Preferably, the cluster login method includes an SSH key or a login password. In another preferred embodiment, the applicant directly signs the verification value with his / her cluster account private key and sends it back.

[0118] It should be noted that the cluster domain verification channel and the issued task-level temporary credentials are two independent entities: the former is a one-time proof of identity and control, used only to establish the mapping; the latter is a runtime credential issued sequentially after the binding is established and is bound to a specific job. After the binding is established, the applicant's original cluster login credentials are no longer used for normal operation.

[0119] By using a dual-domain, two-way verification mechanism based on cryptographic algorithms to prove that the applicant simultaneously holds control of accounts in two domains, it can prevent binding to other people or users of cluster systems without control, and has the ability to prevent replay attacks and man-in-the-middle attacks.

[0120] Corresponding to the cross-domain identity management methods for high-performance computing clusters mentioned above, see, for example... Figure 3 The diagram shown illustrates the architecture of a cross-domain identity management system for high-performance computing clusters, comprising three layers and two independent modules:

[0121] The multi-tenant platform application layer (1) is responsible for workflow and job management.

[0122] The cross-domain identity delegation layer (2) contains five functional modules: identity binding module (7), capability derivation module (3), validity period decision module (4), voucher lifecycle management module (5), and audit reconciliation module (6).

[0123] HPC Cluster Layer (10): Runs the Slurm scheduler, compute nodes, and file system.

[0124] Two independent modules (not part of the cross-domain identity delegation layer (2), deployed across domains respectively):

[0125] Credential Agent Module (8): Deployed on the platform side, responsible for applying to the cluster CA for the issuance of temporary credentials and credential caching. Execution Agent Module (9): Deployed on the cluster side, responsible for credential verification, field force-command verification, session interruption and receipt.

[0126] The identity binding module (7) is triggered independently when the user establishes a mapping for the first time (unrelated to job submission). After generating a binding token, subsequent job processes can proceed. When a job is submitted, the multi-tenant platform application layer (1) sends the request to the cross-domain identity delegation layer (2), which is processed collaboratively by the capability inference module (3), validity period decision module (4), credential lifecycle management module (5), and audit reconciliation module (6). The delegation layer requests credentials from the credential proxy module (8) and initiates execution with credentials to the execution proxy module (9). After the credential proxy module (8) and the execution proxy module (9) reconcile and interact, they are both connected to the HPC cluster layer (10).

[0127] Terminology Explanation: "Domain" refers to two independent identity management and access control domains, namely the platform domain of the platform's own identity system and the cluster domain of the HPC cluster system's own identity system.

[0128] "Cross-domain" means crossing two independent identity management systems.

[0129] Table 5 below shows the inputs, outputs, triggering times, and downstream consumers of each module, describing the end-to-end data flow relationship.

[0130] Table 5

[0131]

[0132] For example, taking the MPI (Message Passing Interface) computation job numbered 456 submitted by platform user alice and cluster system user alice_hpc as an example, the above process steps are followed. The computation job is a submission type and requires the upload of input files.

[0133] First, identity binding: When Alice initially establishes the mapping with Alice_hpc, it has already passed dual-domain verification. Specifically, the platform domain uses its platform credentials to sign the response, and the cluster domain is determined by the execution agent writing a one-time verification file in the Alice_hpc home directory. Alice reads the contents of this file using its original cluster login method and sends it back. After successful joint verification, a binding token is derived and stored in the database. When submitting job 456, the credential agent first verifies that the binding token is valid and within its validity period.

[0134] Next, the minimum capability set is derived: the capability derivation module parses job 456 and maps the direct request capability set according to the submission type and upload requirements. In one implementation, the direct request capability set includes submission commands and file upload / write commands; if monitoring is required, it may also include queue query commands and accounting query commands. Implicit sub-capabilities are completed level by level along the command capability dependency graph, including reading job scripts, creating and writing output files, and reading input data paths. A candidate path set is determined, and after finding the intersection of path prefixes with the job workspace, the restricted scope of each file-type capability converges to the job workspace path. In one implementation, the candidate path set is the full path under the user's home directory in the cluster system, and the job workspace is the specific job path under the home directory; the restricted scope converges to this job path. File-type implicit capabilities that exceed the boundary are discarded. After sufficiency verification and minimum pruning, and after intersection with the user and cluster available capabilities, the minimum authorized capability set and command whitelist are output.

[0135] Then, an expiration decision is made: Since job 456 did not declare a runtime, the estimated runtime is taken as the 90th percentile of historical runtime for similar jobs. In one implementation, these similar jobs are categorized by type, queue, and size, with a historical 90th percentile runtime of 40 minutes. Using a redundancy factor of 1.2 and a buffer of 10 minutes, the initial expiration time is calculated to be 58 minutes. This falls within the range of a minimum expiration time of 5 minutes to a maximum expiration time of 2 hours and does not exceed the maximum expiration time; therefore, it is marked as non-renewable.

[0136] Next, credential issuance: the credential agent requests a short-term SSH certificate from the cluster CA. In one implementation, the `principals` field is `alice_hpc`, the `valid-before` field is 58 minutes after the current time, the `force-command` field points to the capability wrapper and loads the command whitelist and job workspace path prefix constraints, and the extended field contains the job identifier 456 and the credential identifier. After the cluster CA issues the certificate with its private key, it returns and caches it, and the audit and reconciliation module records the issuance triplet.

[0137] The platform, carrying the certificate, sequentially executes the steps of creating a workspace, uploading input files, and submitting the job. The execution agent verifies the signature, queries the CRL, enters the wrapper via force-command, parses the original command, and compares it item by item with the whitelist and path prefix. Upon successful comparison, the command is executed and the verification value is returned. Any unauthorized commands or out-of-bounds path requests are directly intercepted and logged for auditing.

[0138] The credential lifecycle management module queries the status of job 456 according to the status polling cycle and maintains the active session table. During job execution, the credential remains valid. Since it is marked as non-renewable in this example, if the job is not completed before expiration, an alarm is recorded according to the default policy, and the operation and maintenance team intervenes. If the job is predicted to be a long job, it should be marked as renewable in step 3 and renewed via heartbeat.

[0139] If a query shows that the accounting status is running but the node process has exited, or if there is a short-term lack of response on the cluster side, the decision to cancel or maintain the status will be made after calibration according to the priority and grace period strategy of cluster final state taking precedence over scheduling transient state, and scheduling transient state taking precedence over platform cache.

[0140] When job 456 completes execution and enters the final completed state, revocation is immediately triggered. The credential status is set to revoked, the credential identifier is written to the CRL and synchronized with the execution agent, the remaining session is terminated according to the credential identifier, and the revocation audit is recorded.

[0141] The audit reconciliation module associates two-field records according to job identifier 456, and verifies that all operations are within the authorized scope and that the verification values ​​of the receipts are consistent. Optionally, the continuity of the hash chain is verified, and the records are archived after passing the verification.

[0142] Figure 4This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 4 As shown, the electronic device 500 includes one or more processors 501 and memory 502.

[0143] The processor 501 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 500 to perform desired functions.

[0144] The memory 502 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 501 may execute the program instructions to implement the cross-domain identity management method for high-performance computing clusters described above in any embodiment of this application, and / or other desired functions. Various contents such as initial extrinsic parameters and thresholds may also be stored in the computer-readable storage medium.

[0145] In one example, the electronic device 500 may further include an input device 503 and an output device 504, these components being interconnected via a bus system and / or other forms of connection mechanisms (not shown). The input device 503 may include, for example, a keyboard, a mouse, etc. The output device 504 may output various information to the outside, including warning messages, braking force, etc. The output device 504 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0146] Of course, for the sake of simplicity, Figure 4 Only some of the components of the electronic device 500 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 500 may include any other suitable components depending on the specific application.

[0147] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the cross-domain identity management method for high-performance computing clusters provided in any embodiment of this application.

[0148] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0149] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the cross-domain identity management method for high-performance computing clusters provided in any embodiment of this application.

[0150] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0151] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this invention, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A cross-domain identity management method for high-performance computing clusters, characterized in that, include: In response to a job request submitted by a platform user, determine the minimum set of authorized capabilities and the restricted workspace scope required for the job request; Determine the estimated runtime of the operation and determine the validity period of the voucher that matches the estimated runtime; Based on the cluster system user corresponding to the platform user, the minimum authorized capability set, the restricted workspace scope, and the certificate validity period, apply to the cluster certificate authority for the issuance of a temporary certificate, and distribute the minimum authorized capability set and the restricted workspace scope to the cluster-side execution agent; In response to the platform sending an operation request to the high-performance computing cluster with the temporary credentials, the cluster-side execution proxy intercepts the operation request and verifies the operation request based on the minimum authorized capability set and the restricted workspace scope. Only when the operation request meets the authorized scope is the high-performance computing cluster controlled to respond to the operation request.

2. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, The determination of the minimum authorized capability set and restricted workspace scope required for the job request includes: Determine the operation type of the job request, and using the request command corresponding to the operation type as a reference, determine the first candidate capability set based on the dependency graph between the command and the implicit sub-capabilities; In addition, for each capability in the first candidate capability set, its restricted workspace scope is determined. If the restricted workspace scope is empty and the capability is a file-related capability, the capability is deleted from the first candidate capability set, and the remaining capability items are determined as the second candidate capability set. The minimum authorized capability set required for the job request is obtained by taking the intersection of the capability items in the second candidate capability set with the capability items that the platform user has the right to use and the capability items that the cluster system has.

3. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, The determination of the estimated runtime of the task includes: If the job request includes a declared runtime, the declared runtime is determined as the estimated runtime; If the job request does not include a declared runtime, the estimated runtime is determined based on the runtime of similar jobs in the past.

4. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, Also includes: If the estimated runtime exceeds the upper limit threshold, the temporary certificate is recorded as a renewal type and renewed when the temporary certificate is detected to have expired. If the estimated runtime does not exceed the upper limit threshold, the temporary certificate is recorded as a non-renewal type and set to an invalid state when the temporary certificate is detected to have expired.

5. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, The temporary credential is carried by a user certificate issued by the cluster certificate authority, and the user certificate fields include at least: cluster system user identifier, credential validity period, executable file path of the capability execution wrapper, job identifier, and credential identifier; The capability execution wrapper is a functional component of the cluster-side execution agent. It is used to intercept operation requests carrying the temporary credentials, verify the operation requests according to the minimum authorized capability set and the restricted workspace scope, and only execute compliant requests.

6. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, The cluster-side execution proxy intercepts the operation request and verifies the operation request based on the minimum authorized capability set and the restricted workspace scope. It controls the high-performance computing cluster to respond to the operation request only if the operation request conforms to the authorized scope, including: The operation request carrying the temporary credentials is imported into the capability execution wrapper according to the executable file path of the capability execution wrapper; the capability execution wrapper parses the original command of this operation request and the file path involved, and compares it item by item with the issued minimum authorized capability set and the restricted workspace scope; After the verification is successful, the operation is executed and a receipt verification value is generated. The receipt verification value is the result of hashing the key fields of the operation record, which is used by the platform to verify the authenticity and integrity of the record.

7. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, Also includes: Establish an identity mapping relationship between platform users in the platform domain and cluster system users in the high-performance computing cluster domain, specifically including: The platform domain and cluster domain each send random verification information to the applicant. After the applicant completes the response using the identity credentials of the corresponding domain, the system performs joint verification. After the verification is successful, a unique binding token is generated based on the key and a mapping relationship is established. The joint verification must simultaneously satisfy the following conditions: the platform domain signature verification is successful, the cluster domain response verification is successful, neither verification value has been used and the timestamp is within the valid window, and the user identifier carried in the platform domain response and the cluster domain response is consistent.

8. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, Also includes: Monitor the running status of the job, and when the job is detected to have entered the final state of completion, failure or cancellation, revoke the temporary certificate and interrupt the session connection established based on the temporary certificate; The revocation of the temporary credential includes: writing the identifier of the temporary credential into the certificate revocation list and synchronizing it to the cluster-side execution agent; the cluster-side execution agent uses the identifier as the key to look up the active session and process table, closes the corresponding connection, and terminates the derived associated process.

9. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, It also includes a cross-domain state consistency calibration step: when communication is interrupted or the state is inconsistent between the platform domain and the cluster domain, the state is determined according to the priority rule that the final state of the cluster takes precedence over the real-time state of the scheduling system, and the real-time state of the scheduling system takes precedence over the cached state of the platform. If the cluster does not respond within the set time, a grace period timer will be started to wait. If there is still no response after the grace period expires, the certificate will be treated as an orphan certificate and revocation will be triggered.

10. The cross-domain identity management method for high-performance computing clusters according to claim 1, characterized in that, It also includes triple binding and reconciliation steps: when a temporary voucher is issued, the voucher identifier, job identifier, and minimum authorized capability set are associated and stored to form a cross-domain triple basic record; each time an operation is executed on the cluster side, the binding token, job identifier, execution command, and return code are recorded and the verification value is sent back to the platform; the platform side performs reconciliation verification by associating the two domain records according to the job identifier, and triggers revocation when an anomaly is found.

Images