Stage Skip Control

[[Stage]] By default, there is no restriction on which users are allowed to skip stages in a pipeline; anyone can select stages they want to skip. This level of flexibility may allow users to inadvertently circumvent security requirements. The admin or any user with modify privileges on pipeline objects can specify users and user groups authorized to skip stages or can disable stage skipping all together.

Configuring Stage Skipping

At pipeline create time, set level of stage skip control in the New Pipeline dialog. At runtime, stage selection is disabled if the current user is not permitted to skip stages or if Skip Stages is disabled.

pipelinestage1

Three levels of stage skip control include:

  • Enabled —All users and groups can select stages to skip.

  • Disabled —No user or group is permitted to select stages to run.

  • Restricted —Only specific users and groups are permitted to pick stages to run. When this level is selected, you enter the list of permitted users and groups in the space provided.

Running a Pipeline

When configuring a pipeline run the user has the opportunity to configure stages to skip. If stage skipping is enabled, stage selection is disabled for users restricted from stage skipping, which is clearly denoted at pipeline runtime.

Restarting a Pipeline

If a user, who is not permitted to skip stages, restarts a pipeline run, they are not able to skip any stages which are after the stage being restarted. For the examples below consider a pipeline with five stages, skip stage mode is RESTRICTED for all users except UserA.

Example 1:

  • UserA starts the pipeline and selects stages 1, 2, and 3 to run.

  • The pipeline runs and the stops at stage 3 due to an error.

  • UserB attempts to restart the pipeline. Since User1 configured the pipeline to skip stage 4 and 5, User2 cannot restart the pipeline because he does not have stage skip privileges.

Example 2:

  • UserA starts pipeline and selects stages 2,3,4, and 5 to run.

  • The pipeline runs and the stops at stage 2 due to an error.

  • UserB is able to restart the pipeline because no stages are being skipped after stage 2.

Authentication Context Control

All stages in a pipeline run within the authentication context of the user who starts the pipeline and the owning project authentication context. The user who initiates the pipeline usually has access to the lower environments at the start of the pipeline, but as the pipeline progresses to more controlled environments, access is more limited, and the originator likely will not have the required access. In this case, the project principal is given the appropriate access so the pipeline can continue, within the context of the originator. This may not be appropriate for the project and can open security vulnerabilities.

As an illustration of this vulnerability, consider a pipeline with two stages, DEV and PROD.

  • UserD has access to run deployments only in DEV env, and UserP has access only in PROD.

  • UserD starts the pipeline to run in DEV; deployment runs with UserD’s access.

  • UserP approves entry gate to PROD. However, the stage runtime is still in UserD’s authentication context, which doesn’t have access, and therefore relies on the Project Principal’s access and context in order to execute in the PROD environment.

The admin or any user with modify privileges on a pipeline or release is able to specify the runtime authentication context for the stage, task, or gate rule instead of keeping the authentication of the original pipeline launcher.

  • When defining a gate rule or manual task, the user indicates if the authentication context should be switched to approver’s authentication context.

  • After the gate rule or manual task is approved, the authentication context of approving user is added to the session. The authentication context is switched in the pipeline and the currently active stage or gate and remains in force until it is switched again by downstream objects.

  • Authentication context does not switch if the task or gate rule is rejected or fails, even if error handling for the task is set to Continue on Error.

Configuring Authentication Context Control

Add authentication control to a task, ,gate on the task, or gate definition dialog.

pipelineauth

Specify users or groups that can approve, configure notification, and the check boxes for Minimum users to approve and Use approver’s permissions for the further Pipeline execution.

Make sure the following objects have execute privilege enabled:

  • The pipeline.

  • All stages until the stage or gate containing a task with Use approver’s permissions for the further Pipeline execution checked. If pre-gate has such a task then execute privilege on stage is not required.

  • All tasks before, and including the current task, with Use approver’s permissions for the further Pipeline execution checked.

And read priviledge enabled for:

  • All stages after the one containing a task with Use approver’s permissions for the further Pipeline execution checked.

  • All tasks after the one with Use approver’s permissions for the further Pipeline execution checked.

Restarting a Pipeline

When a pipeline run is restarted, the authentication context is reset and the restarting pipeline user authentication is added. For the examples below, the initial pipeline session primary authentication user is User1.

Example 1:

  • UserA runs a pipeline with stage 1 and stage 2.

  • The pipeline fails on stage 2 and UserB restarts stage 2: the pipeline session primary authentication user is now User2. The same for session 2.

Example 2:

  • UserA runs pipeline with stage 1 and stage 2. Stage 2 has a manual task requiring approval in stage 1.

  • UserB approves that task: the pipeline session primary authentication user is now UserB.

  • The pipeline fails on stage 2 and UserC restarts stage 2 . A new session is created with pipeline session primary authentication user as UserC.