Hi there!

Feature Request

What challenge are you facing?

Our organization enforces strict separation of duties policies which stipulate that no user with permission to trigger jobs which affects our non-production environments can be allowed to trigger a job which affects our production environments, and vice versa.

There is an internal change order management system which we must use to create a change order (e.g: deploy version next) which is then approved by a designated approver. The CO system then makes an HTTP call to a URL we specify (currently a Jenkins build trigger endpoint) to kick off the production job. No users have permissions to trigger that job in any other way. All of this is required to satisfy auditing and legal requirements. We can tweak that process but we can't do away with it.

Currently pretty much everyone is using a Jenkins server managed by another team (we have tens of thousands of devs in our org). There are non-prod and prod folders there which enforce the SoD policies. So we have separate Jenkins jobs for build, test etc and for our production deployment. It's a nightmare. I want to bring a real pipeline-based build tool like Concourse to the organization but we can only do that if we can implement RBAC which satisfies our SoD policy.

There are similarities here with other issues:

• Proposal: being able to temporarily expose information to another team #1209
• Read-only access for authenticated users #769

However this is a slightly different use case where we want to be able to configure RBAC at the job level so that users in certain roles are only able to trigger certain jobs within a deployment.

A Modest Proposal

A team would be able to configure RBAC at the job level.

• Team 'Security' create a build pipeline for Team A with jobs 'build', 'test', 'deploy'
• Team A are added to the 'team_a_dev' role, except for one member who is added to the 'team_a_approver' role
• Users in the 'team_a_dev' role can trigger the 'build' and 'test' jobs but not 'deploy'
• Users in the 'team_a_approver' role can trigger the 'deploy' job only

Where it gets complicated is how jobs are configured. We could live with a scenario where pipeline configuration changes are submitted to the 'Security' team to be reviewed and applied.