In traditional Linux HPC setups, users log in to the system, and the system has an authentication mechanism (for example, LDAP or Kerberos). Users are then logged in to the system directly and can perform actions on behalf of themselves. Permissions for files, folders, and executables are determined by the permissions of the logged-in user.
In cloud-native scenarios that use microservices and APIs, authentication and authorization is handled differently. Users authenticate with an authentication server and get an access token in return. The services in the backend run as service users, not the actual user who made the request. Permission to perform an action, access data, or access resources is handled by the system and is not determined by file, folder, or executable permissions.
In Ansys HPC Platform Services there are two types of processes that can occur in the backend when working with autoscaling environments:
- User Impersonation
Since this is an agent-based architecture, this is aligned with getting the correct user logged into the cloud-native core services from the agent (evaluator) end.
This way the agent only sees what the user is allowed to see from a project and task perspective.
- Job Submission Impersonation
Who submits the job to the orchestrator (LSF, PBS, Slurm, and UGE only)
This is aligned with getting the correct user submitting the work to the orchestrator and determines the username used for creating processes, files, and folders.
For more details see Job Submission Impersonation in Traditional HPC Environments.
Ansys HPC Platform Services provides the ability to either use the methods together or independently of one another. The ability to provide static credentials to run without any impersonation is also available. Generally, these impersonation options are only applicable within traditional job scheduler scenarios.