Blog Engineering How to limit access to manual pipeline gates and deployments using GitLab
February 20, 2020
4 min read

How to limit access to manual pipeline gates and deployments using GitLab

Let's look at how to use protected environments to set up access controls for production deployments and manual gates.

protect_manual_jobs.jpg

This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-02-21.

In our world of automation, why would anyone want to do something manually? Manual has become almost synonymous with inefficient. But, when it comes to CI/CD pipelines, a properly configured manual job can be a powerful way to control deployments and satisfy compliance requirements. Let’s take a look at how manual jobs can be defined to serve two important use cases: Controlling who can deploy, and setting up manual gates.

Limit access to deploy to an environment

Deploying to production is a mission-critical occurence that should be protected. Projects with a Kubernetes cluster could benefit from moving to a continuous deployment (CD) model in which a branch or merge request, once merged, is auto-deployed to production, and the absence of human intervention avoids mishaps. But for projects not yet configured for CD, let's consider this use case: Imagine a pipeline with a manual job to deploy to prod, which can be triggered by any user with access to push code. The risk of a unplanned, unintended production deployment is very real.

Fortunately, it’s possible to use protected environments to prevent just anyone from deploying to production. When configuring a protected environment, you can define the roles, groups, or users to whom deploy access is granted. The protected environment can then be defined in a manual job to deploy which limits who can run it. The configuration could look something like this:

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  environment:
    name: production
    url: https://example.com
  when: manual
  only:
    - master

In the example above, the keyword environment is used to reference a protected environment (as configured in project settings) with a list of users who can run the job, in this case deploy to the named environment. Users without access see a disabled play button and are unable to execute the job.

Add an approval step

Compliance rules may specify that approval is required for certain activities in a workflow, even if they aren't technically a deployment step themselves. In this use case, an approval step can also be added in the pipeline that prompts an authorized user to take action to continue. This can be achieved by structuring your pipeline with an "approve" stage containing a special manual job – for example, the YAML to insert an approval stage before deployment could look like this:

stages:
  - build
  - approve
  - deploy

build:
  stage: build
  script:
    - echo Hello!

approve:
  stage: approve
  script:
    - echo Hello!
  environment:
    name: production
    url: https://example.com
  when: manual
  allow_failure: false
  only:
    - master

deploy:
  stage: deploy
  script:
    - echo Hello!
  environment:
    name: production
    url: https://example.com
  only:
    - master

In the YAML above, allow_failure: false defines the manual job as "blocking", which will cause the pipeline to pause until an authorized user gives "approval" by clicking on the play button to resume. Only the users part of that environment list will be able to perform this action. In this scenario, the UI view of the pipeline in the example CI configuration above would look like this:

Pipeline view of approval stage manual job

Summary

As illustrated in the YAML examples and image above, manual jobs defined with protected environments and blocking attributes are effective tools for handling compliance needs as well as for ensuring there are proper controls over production deployments.

Tell us how using protected environments with manual jobs has secured your deployments or whether blocking manual jobs helps you meet compliance and auditing. Create an issue in the GitLab project issue tracker to share your feedback with us.

Cover image by Diane Walton on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert