How the Process Launcher Works

The Process Launcher configuration specifies an OAuth provider to validate tokens. This is connected to the Keycloak instance started in the services stack by referencing the “auth_url” in the configuration.

The Process Launcher exposes a REST API that allows an OAuth-authenticated user to request to generate a small text file or to run any generic command.

  • Upon receiving the request, the API validates the token using the keys found at the auth_url -> jwks endpoint.

  • After validation it parses the token for the username.

  • Using the username from the token it searches its configuration for an optional username mapping.

    Username mappings can be configured in the launcher configuration file for when the OAuth ID does not exactly match the local Linux UID.

  • Since the launcher is run as a special user with elevated permissions, it can use the Python process runner libraries to spawn a process as the user from the token (or token mapping), which performs the request of writing the requested file or running the requested command.

    Files written in this way typically are shell scripts for immediate use with the scheduler submission.

    Commands run this way are typically scheduler submission, abort, or monitoring requests.

Because the application is running as an elevated user, the service does not allow the root user or any user in the root group to run any jobs through the system.

Security Options

Optionally, the following security options are provided:

  • Allowed and disallowed users (empty by default)

  • Minimum UID and GID for users to be allowed to run jobs (default is 1000)

Requirement for a Mapped Service User

Some applications passing jobs to the launcher will need to have a mapped user to run those operations. To enable this, you must use the "user_mapping" section of the launcher configuration file.

A good example is the autoscaler querying the job scheduler properties.