GitLabTech&Tips

GitLab을 사용하여 수동 파이프라인 게이트 및 배포에 대한 액세스를 제한하는 방법

Source: GitLab Blog | Author: Thao Yeager

자동화의 세계에서 무언가를 수동으로 하고 싶어하는 사람이 없습니다. Manual이라는 것은 비효율적인 것과 거의 동의어가 되었습니다. 그러나 CI/CD 파이프라인 경우에는 적절하게 구성된 수동 작업(job)이 배포를 제어하고 규정 준수 요건을 충족할 수 있는 강력한 방법이 될 수 있습니다. 배포할 수 있는 사용자 제어 및 수동 게이트 설정: 이 두 가지 중요한 사용 사례를 처리하는 데 수동 작업을 어떻게 정의하면 되는지 살펴보도록 합니다.

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

댓글 남기기