Description of problem:

At the latest level of Satellite 6 it is possible to set the effective user for a remote command. This allows remote commands to be scheduled as different users and rely on the client's elevation mechanism to permit or deny the job.
What is required for a large number of customers is the ability to restrict Satellite users/roles to being able to use specific effective users for any remote commands that they schedule.

Remote Execution in it's current form is not useable by UBS due to the monolithic nature of the effective user. This functionality cannot be used at UBS

Specific use-case details for this are as follows:

User elevation is managed by pbrun on client systems. Whilst it is possible, it is not acceptable to build pbrun rules to allow all Satellite remote execution scripts to be elevated. As such, individual commands within these scripts need to be elevated on requirement.

We require a method to be able to assign Satellite roles/users to specific effective users for remote execution. At the moment this is restricted by the use of a single ssh_user for all Satellite roles/users. We need the ability to set the ssh_user depending on the role or user scheduling the remote execution. This will allow us to escalate to the relevant authorisation level depending on the Satellite user. e.g.

Read-only Satellite user schedules commands via Satellite. These are distributed as a "read-only" ssh user, which then runs the command as a read-only user on the client. This user has pbrun privileges to run specific read-only commands as root (df -h, cat specific /var/log/ files, ip a s, etc).

Ops Satellite user schedules commands via Satellite. These are distributed via the Ops ssh user, which then runs the commands as the Ops user on the client. This has more expansive pbrun privileges on the client and can runs certain write commands such as yum install specific packages, restart certain services, etc.

Patching user schedules commands via Satellite. These are distributed via the Patching ssh user, which then runs the commands as the Patching user on the client. This has pbrun privileges to allow yum update, but cannot run yum install so that the Patching user cannot expand the installed packages on a client.

Break-glass user schedules commands via Satellite. These are distributed via the Break-glass user, which then runs the commands as root? This is a hypothetical example, but the previous 3 are not.

There needs to be a way to segregate different job roles in the Satellite. Whilst this is possible at the Satellite end, we are unable to use remote execution until there is an ability within the Satellite to assign specific ssh users to specific Satellite roles/users.