Feature Request: Role-based access control for invoking jobs

[MatthewWilkes]

Is your feature request related to a problem? Please describe.
When triggering a manual job, it's possible to override substantial parts of the definition, such as image or command. I would love to be able to delegate some actions on jobs to user accounts without giving the ability to exceed those definitions.

For example, we have a container app job defined using the same image as a running container app, but with a command override to run drush cache:rebuild rather than opening a fastcgi socket. This is a low-risk command that is the first step to fixing a service outage. I'd like to share with many people in the organisation, but there's also a drush sql:drop command which would cause a serious outage if run.

There are already some definitions, like microsoft.app/jobs/execution/read but these appear relatively minimal and per-job settings aren't yet exposed in portal.

Describe the solution you'd like.
I would like role-based access control of job definitions that limits individual functions. I envision a contributor would be able to edit a job definition, trigger it as currently, see executions, etc. I'd like to be able to delegate a role on a specific job that allows triggering but does not allow deviation from the defined version.

In the example above, I'd create a job for drush cache:rebuild and then assign a runner role to various people. They'd be able to see the job and view the command it runs, but not be able to view the secrets assigned to the job. They'd be able to trigger a manual job, but not override anything during the trigger.

Describe alternatives you've considered.
Event-based triggering is a way around this, for now. A job can be triggered using an event from a storage account queue, which allows RBAC to limit users to posting to the individual queue. They could then be given read access to the log analytics workspace and the job, so they're able to see outputs but not edit.

I believe this would work, but is somewhat unintuitive. We'd have to document that enqueueing a message triggers the output, but it would be easy to achieve through the various queue interfaces available.

Additional context.
N/A

[anthonychu]

Thanks @MatthewWilkes. We've been considering this and your scenarios above is super helpful for understanding what's needed here.

[zyofeng]

Can we get an update on this? Container jobs are sometimes manually executed so it's important to be able to grant user/group/app permissions based using rbac and not having to create custom roles.