Access control scenarios for pipelines, releases, and procedures

This section outlines access control scenarios for pipelines, releases, and procedures, demonstrating how authentication contexts affect behavior. Reviewing these examples helps clarify access control mechanisms, resource pool management, and agent assignment with appropriate permissions.

In the following examples, there are two projects: projectA and projectB. These projects contain:

Table 1. **projectA** and **projectB**
projectA	projectB
procedureA	procedureB
pipelineA	pipelineB
releaseA	releaseB
applicationA	applicationB
environmentA	environmentB

The following non-admin users are defined:

Table 2. Groups and users
Groups	Users
groupA	userA userB
Everyone group	userA userB userC

Key points to note:

The access control list (ACL) permissions specified for the principals in the scenarios below can either be directly defined or inherited.
The ACL permissions mentioned could be presented for all principals in the context or could be one of the principals with either an Allow or Deny category. For example, a user can have an Allow permission via inheritance but the Everyone group, or a project of pipelineA, may not have any explicit ACLs defined.
When a user has an ACL defined, either explicitly or via inheritance, it always takes precedence over other principals, such as Group or Project.

Ensure you are familiar with the access control system before making changes. Incorrectly setting ACLs can severely impact CloudBees CD/RO behavior.
For schedule-invoked pipelines or releases that include command tasks, access control is defined by the plugin project EC-Core-<version>. In order to deny the invocation, the EC-Core-<version> project also needs to be given a Deny permission on the pipeline or release being invoked.
Access control behavior in the tables below is applicable for CloudBees CD/RO v10.3.1 and later. Before migrating from an earlier release, review access control settings at your site for pipelines, releases, and procedures. Make appropriate changes in access control based on the v10.3.1 and later behavior.

Pipeline examples

The pipeline examples below assume that projectA with pipelineA calls a procedure, procedureB.

Similar behavior exists when pipelineA calls:

A pipeline task, named pipelineB, from projectB.
An application process task, named applicationB-processB-environmentB, from projectB.

Pipeline example: All objects have allow permissions on projectB

Table 3. All objects have **Allow** permissions on **projectB**
Objects	Execute permissions on projectB	Run as	Result
projectA	allow	Run pipelineA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	allow	Run pipelineA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run pipelineA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run pipelineA from projectA as userC	procedureB is launched successfully by userC

Pipeline example: projectA has the deny permission on projectB

Table 4. **projectA** has the **Deny** permission on **projectB**
Objects	Execute permissions on projectB	Run as	Result
projectA	deny	Run pipelineA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run pipelineA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run pipelineA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run pipelineA from projectA as userC	procedureB is launched successfully by userC

Pipeline example: userA has the deny permission on projectB

Table 5. **userA** has the **Deny** permission on **projectB**
Objects	Execute permissions on projectB	Run as	Result
projectA	allow	Run pipelineA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	deny	Run pipelineA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run pipelineA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run pipelineA from projectA as userC	procedureB is launched successfully by userC

Pipeline example: groupA has the deny permission on projectB

Table 6. **groupA** has **Deny** permission on **projectB**
Objects	Execute permissions on projectB	Run as	Result
projectA	allow	Run pipelineA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	allow	Run pipelineA from projectA as userA	procedureB cannot be launched by userA
groupA	deny	Run pipelineA from projectA as userB	procedureB cannot be launched by userB
Everyone group	allow	Run pipelineA from projectA as userC	procedureB is launched successfully by userC

Pipeline example: The Everyone group has the deny permission on projectB

Table 7. The **Everyone** group has the **Deny** permission on **projectB**
Objects	Execute permissions on projectB	Run as	Result
projectA	allow	Run pipelineA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run pipelineA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run pipelineA from projectA as userB	procedureB cannot be launched by userB
Everyone group	deny	Run pipelineA from projectA as userC	procedureB cannot be launched by userC

Pipeline-level security

For robust security, assign a dedicated resource to each pipeline. Sharing resources across pipelines can allow unauthorized access to information from other pipelines. To prevent this, manage resources at the stage level and ensure each is isolated.

For more information on creating a resource pool and configuring agents, refer to Create or edit resource pools or Configure agents.

Resource pools can be configured at either the pipeline or stage level. When a resource pool is set at the pipeline level, all stages within that pipeline inherit the same resource pool. However, if a resource pool is defined at the stage level, it overrides the pipeline-level setting for that specific stage.

Assign a resource pool to a project

Navigate to DevOps essentials Projects and select Add project.
Select Create new or Copy existing based on the requirements.
If assigning a resource or resource pool to a new project:
1. Enter the name of project.
2. Select the appropriate resource or resource pool from Select resource or resource pool.
3. Select OK.
If assigning a resource or resource pool to an existing project;
1. Select the existing project.
2. Select the appropriate resource or resource pool from Select resource or resource pool.
Select OK.

Assign resource pool to a stage

Navigate to the desired pipeline.
Select the menu of desired stage.
Select Details.
Select Assign Resource or Resource Pool under Details.
Select the appropriate resource or resource pool from the list.
Select Save. The selected resource or resource pool is now assigned to the stage.
Select Save changes.

Release examples

The release examples below assume that projectA with releaseA calls a procedure task, procedureB.

Similar behavior exists when releaseA calls:

A pipeline task, pipelineB, from projectB.
An application process task, applicationB-processB-environmentB, from projectB.
A release task, releaseB, from projectB.

Release example: All objects have allow permissions on projectB

Table 8. All objects have **Allow** permissions on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run releaseA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	allow	Run releaseA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run releaseA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run releaseA from projectA as userC	procedureB is launched successfully by userC

Release example: projectA has the deny permission on projectB

Table 9. **projectA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	deny	Run releaseA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run releaseA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run releaseA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run releaseA from projectA as userC	procedureB is launched successfully by userC

Release example: userA has the deny permission on projectB

Table 10. **userA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run releaseA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	deny	Run releaseA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run releaseA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run releaseA from projectA as userC	procedureB is launched successfully by userC

Release example: groupA has the deny permission on projectB

Table 11. **groupA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run releaseA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	allow	Run releaseA from projectA as userA	procedureB cannot be launched by userA
groupA	deny	Run releaseA from projectA as userB	procedureB cannot be launched by userB
Everyone group	allow	Run releaseA from projectA as userC	procedureB is launched successfully by userC

Release example: The Everyone group has the deny permission on projectB

Table 12. The **Everyone** group has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run releaseA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run releaseA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run releaseA from projectA as userB	procedureB cannot be launched by userB
Everyone group	deny	Run releaseA from projectA as userC	procedureB cannot be launched by userC

Procedure examples

The procedure examples below assume that projectA with procedureA calls a procedure step, procedureB.

Similar behavior exists when procedureA calls:

A pipeline task,pipelineB, from projectB.
A release task, releaseB, from projectB.
An application process task, applicationB-processB-environmentB, from projectB.

Procedure example: All objects have allow permissions on projectB

Table 13. All objects have **Allow** permissions on **projectB**.
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run procedureA from projectA using projectA (schedule	procedureB is launched successfully by projectA]
userA	allow	Run procedureA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run procedureA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run procedureA from projectA as userC	procedureB is launched successfully by userC

Procedure example: projectA has the deny permission on projectB

Table 14. **projectA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	deny	Run procedureA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run procedureA from projectA as userA	procedureB is launched successfully by userA
groupA	allow	Run procedureA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run procedureA from projectA as userC	procedureB is launched successfully by userC

Procedure example: userA has the deny permission on projectB

Table 15. **userA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run procedureA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	deny	Run procedureA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run procedureA from projectA as userB	procedureB is launched successfully by userB
Everyone group	allow	Run procedureA from projectA as userC	procedureB is launched successfully by userC

Procedure example: groupA has the deny permission on projectB

Table 16. **groupA** has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run procedureA from projectA using projectA (schedule)	procedureB is launched successfully by projectA
userA	allow	Run procedureA from projectA as userA	procedureB cannot be launched by userA
groupA	deny	Run procedureA from projectA as userB	procedureB cannot be launched by userB
Everyone group	allow	Run procedureA from projectA as userC	procedureB is launched successfully by userC

Procedure example: The Everyone group has the deny permission on projectB

Table 17. The **Everyone** group has the **Deny** permission on **projectB**
Objects	Permissions on projectB	Run as	Result
projectA	allow	Run procedureA from projectA using projectA (schedule)	procedureB cannot be launched by projectA
userA	allow	Run procedureA from projectA as userA	procedureB cannot be launched by userA
groupA	allow	Run procedureA from projectA as userB	procedureB cannot be launched by userB
Everyone group	deny	Run procedureA from projectA as userC	procedureB cannot be launched by userC