환경은 테스트 및 프로덕션 목적으로 모두 사용할 수 있습니다.

배포 job은 서로 다른 역할을 가진 다양한 사용자가 실행할 수 있으므로, 권한이 없는 사용자의 영향으로부터 특정 환경을 보호하는 것이 중요합니다.

기본적으로 보호된 환경은 적절한 권한을 가진 사용자만 배포할 수 있도록 보장하여 환경을 안전하게 유지합니다.

환경을 보호하거나 보호를 해제하려면 최소 Maintainer 권한이 필요합니다. 또한 external_url, tier, description과 같은 환경 속성을 업데이트하려면 Allowed to deploy 목록에도 포함되어 있어야 합니다.

환경 보호#

사전 준비 사항:

• 승인자 그룹에 Allowed to deploy 권한을 부여할 때, 보호된 환경을 설정하는 사용자가 해당 승인자 그룹의 직속 멤버여야 추가할 수 있습니다. 그렇지 않으면 드롭다운 목록에 그룹이나 하위 그룹이 표시되지 않습니다. 자세한 내용은 이슈 #345140을 참고합니다.
• 승인자 그룹이나 프로젝트에 Approvers 권한을 부여할 때, 기본적으로는 해당 승인자 그룹이나 프로젝트의 직속 멤버만 이 권한을 받습니다. 승인자 그룹이나 프로젝트의 상속된 멤버에게도 이 권한을 부여하려면 다음과 같이 합니다.
  • Enable group inheritance 확인란을 선택합니다.
  • API를 사용합니다.

환경을 보호하려면 다음과 같이 합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.

3. Protected environments를 펼칩니다.

4. Protect an environment을 선택합니다.

5. Environment 목록에서 보호할 환경을 선택합니다.

6. Allowed to deploy 목록에서 배포 권한을 부여할 역할, 사용자, 또는 그룹을 선택합니다. 다음 사항에 유의합니다.

   • 두 가지 역할 중에서 선택할 수 있습니다.
     • Maintainers: Maintainer 권한을 가진 프로젝트의 모든 사용자에게 접근을 허용합니다.
     • Developers: Maintainer 및 Developer 권한을 가진 프로젝트의 모든 사용자에게 접근을 허용합니다.
   • 이미 프로젝트에 초대된 그룹도 선택할 수 있습니다. Reporter 권한으로 프로젝트에 추가된 초대 그룹은 배포 전용 접근의 드롭다운 목록에 표시됩니다.
   • 특정 사용자도 선택할 수 있습니다. 사용자가 Allowed to deploy 목록에 표시되려면 Developer, Maintainer, Owner 권한 중 하나를 가지고 있어야 합니다.

7. Approvers 목록에서 배포 권한을 부여할 역할, 사용자, 또는 그룹을 선택합니다. 다음 사항에 유의합니다.

   • 두 가지 역할 중에서 선택할 수 있습니다.
     • Maintainers: Maintainer 권한을 가진 프로젝트의 모든 사용자에게 접근을 허용합니다.
     • Developers: Maintainer 및 Developer 권한을 가진 프로젝트의 모든 사용자에게 접근을 허용합니다.
   • 이미 프로젝트에 초대된 그룹만 선택할 수 있습니다.
   • 사용자가 Approvers 목록에 표시되려면 Developer, Maintainer, Owner 권한 중 하나를 가지고 있어야 합니다.

8. Approval rules 섹션에서 다음을 확인합니다.

   • 이 숫자가 규칙에 포함된 멤버 수보다 작거나 같은지 확인합니다.
   • 이 기능에 대한 자세한 내용은 Deployment Approvals를 참고합니다.

9. Protect를 선택합니다.

이제 보호된 환경 목록에 해당 환경이 표시됩니다.

API를 사용하여 환경 보호하기#

또는 API를 사용하여 환경을 보호할 수도 있습니다.

1. 환경을 생성하는 CI가 설정된 프로젝트를 사용합니다. 예를 들면 다음과 같습니다.

   stages:
     - test
     - deploy
   
   test:
     stage: test
     script:
       - 'echo "Testing Application: ${CI_PROJECT_NAME}"'
   
   production:
     stage: deploy
     when: manual
     script:
       - 'echo "Deploying to ${CI_ENVIRONMENT_NAME}"'
     environment:
       name: ${CI_JOB_NAME}
   

2. UI를 사용하여 새 그룹을 생성합니다. 예를 들어 이 그룹의 이름은 protected-access-group이고 그룹 ID는 9899826입니다. 이후 단계의 예시에서는 이 그룹을 계속 사용합니다.

   

3. API를 사용하여 그룹에 사용자를 Reporter로 추가합니다.

   $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
          --data "user_id=3222377&access_level=20" "https://gitlab.com/api/v4/groups/9899826/members"
   
   {"id":3222377,"name":"Sean Carroll","username":"sfcarroll","state":"active","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/3222377/avatar.png","web_url":"https://gitlab.com/sfcarroll","access_level":20,"created_at":"2020-10-26T17:37:50.309Z","expires_at":null}
   

4. API를 사용하여 프로젝트에 그룹을 Reporter로 추가합니다.

   $ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" \
          --request POST "https://gitlab.com/api/v4/projects/22034114/share?group_id=9899826&group_access=20"
   
   {"id":1233335,"project_id":22034114,"group_id":9899826,"group_access":20,"expires_at":null}
   

5. API를 사용하여 그룹에 보호된 환경 접근 권한을 추가합니다.

   curl --header 'Content-Type: application/json' --request POST --data '{"name": "production", "deploy_access_levels": [{"group_id": 9899826}]}' \
        --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
   

이제 그룹이 접근 권한을 가지며 UI에서 확인할 수 있습니다.

그룹 멤버십을 통한 환경 접근#

사용자는 그룹 멤버십의 일부로 보호된 환경에 대한 접근 권한을 부여받을 수 있습니다. Reporter 권한을 가진 사용자는 이 방법으로만 보호된 환경에 대한 접근 권한을 부여받을 수 있습니다.

배포 브랜치 접근#

Developer 권한을 가진 사용자는 다음 방법 중 하나를 통해 보호된 환경에 대한 접근 권한을 부여받을 수 있습니다.

• 개별 기여자로서, 역할을 통해.
• 그룹 멤버십을 통해.

사용자가 프로덕션에 배포되는 브랜치에 대한 push 또는 머지 접근 권한도 가지고 있는 경우 다음 권한을 갖습니다.

• 환경 중지.
• 환경 삭제.
• 환경 터미널 생성.

보호된 환경에 대한 배포 전용 접근#

보호된 환경에 대한 접근 권한은 부여받았지만 해당 환경에 배포되는 브랜치에 대한 push 또는 머지 접근 권한은 없는 사용자는 환경 배포 권한만 부여받습니다. Reporter 권한으로 프로젝트에 추가된 초대된 그룹은 배포 전용 접근의 드롭다운 목록에 표시됩니다.

배포 전용 접근을 추가하려면 다음과 같이 합니다.

1. 보호된 환경에 대한 접근 권한을 부여받을 멤버로 구성된 그룹을 아직 없다면 생성합니다.
2. Reporter 권한으로 프로젝트에 그룹을 초대합니다.
3. 환경 보호의 단계를 따릅니다.

환경 수정 및 보호 해제#

Maintainer는 다음을 수행할 수 있습니다.

• Allowed to deploy 목록과 승인 규칙을 포함한 보호 설정을 언제든지 업데이트할 수 있습니다.
• 해당 환경에서 Unprotect를 선택하여 보호된 환경의 보호를 해제할 수 있습니다.

보호된 환경에서 external_url, tier, description과 같은 환경 속성을 업데이트하려면 사용자가 Allowed to deploy 목록에도 포함되어 있어야 합니다.

환경의 보호가 해제되면 모든 접근 항목이 삭제되며, 환경을 다시 보호할 경우 다시 입력해야 합니다.

승인 규칙이 삭제되면 이전에 승인된 배포에서 누가 배포를 승인했는지 표시되지 않습니다. 누가 배포를 승인했는지에 대한 정보는 프로젝트 감사 이벤트에서 계속 확인할 수 있습니다. 새 규칙이 추가되면 이전 배포에는 배포를 승인하는 옵션 없이 새 규칙이 표시됩니다. 이슈 506687은 승인 규칙이 삭제되더라도 배포의 전체 승인 이력을 표시하도록 제안합니다.

자세한 내용은 Deployment safety를 참고합니다.

그룹을 위한 보호된 환경#

일반적으로 대규모 엔터프라이즈 조직은 개발자와 운영자 사이에 명확한 권한 경계를 두고 있습니다. 개발자는 코드를 빌드하고 테스트하며, 운영자는 애플리케이션을 배포하고 모니터링합니다. 그룹을 위한 보호된 환경을 사용하면 운영자는 개발자의 중요 환경 접근을 제한할 수 있습니다. 이 기능은 프로젝트를 위한 보호된 환경을 그룹으로 확장한 것입니다.

배포 권한은 다음 표와 같이 나타낼 수 있습니다.

(참고: 위키백과의 배포 환경)

그룹을 위한 보호된 환경 이름#

프로젝트를 위한 보호된 환경과 달리, 그룹을 위한 보호된 환경은 배포 티어를 이름으로 사용합니다.

그룹은 고유한 이름을 가진 여러 프로젝트 환경으로 구성될 수 있습니다. 예를 들어 Project-A에는 gprd 환경이 있고 Project-B에는 Production 환경이 있으므로, 특정 환경 이름을 보호하는 방식은 확장성이 떨어집니다. 배포 티어를 사용하면 두 환경 모두 production 배포 티어로 인식되어 동시에 보호됩니다.

그룹 멤버십 구성#

그룹을 위한 보호된 환경의 효과를 극대화하려면 그룹 멤버십이 올바르게 구성되어 있어야 합니다.

• 운영자에게는 최상위 그룹에 대한 Owner 권한을 부여해야 합니다. 운영자는 그룹 설정 페이지에서 상위 환경(예: production)에 대한 CI/CD 설정을 유지 관리할 수 있으며, 여기에는 그룹을 위한 보호된 환경, 그룹의 러너, 그룹의 클러스터가 포함됩니다. 이러한 설정은 하위 프로젝트에 읽기 전용 항목으로 상속됩니다. 이를 통해 조직 전체의 배포 규칙 집합을 운영자만 구성할 수 있도록 보장합니다.
• 개발자에게는 최상위 그룹에 대해 Developer 권한을 초과하는 권한을 부여하지 않아야 하며, 하위 프로젝트에 대해서는 명시적으로 Owner 권한을 부여할 수 있습니다. 개발자는 최상위 그룹의 CI/CD 설정에 접근할 수 없으므로, 운영자는 개발자가 실수로 중요한 설정을 변경하지 못하도록 보장할 수 있습니다.
• 하위 그룹 및 하위 프로젝트의 경우:
  • 상위 그룹이 자체적으로 보호된 환경을 구성한 경우, 해당 하위 그룹은 이를 재정의할 수 없습니다.
  • 프로젝트를 위한 보호된 환경은 그룹 설정과 결합할 수 있습니다. 두 설정이 모두 존재하는 경우, 배포 job을 실행하려면 사용자가 두 규칙 집합 모두에서 허용되어야 합니다.
  • 최상위 그룹의 프로젝트나 하위 그룹에서는 개발자에게 하위 환경(예: testing)을 조정할 수 있도록 안전하게 Maintainer 권한을 할당할 수 있습니다.

이 구성이 적용되면 다음과 같이 동작합니다.

• 사용자가 프로젝트에서 배포 job을 실행하려 하고 해당 환경에 배포가 허용된 경우, 배포 job이 진행됩니다.
• 사용자가 프로젝트에서 배포 job을 실행하려 하지만 해당 환경에 배포가 허용되지 않은 경우, 배포 job이 오류 메시지와 함께 실패합니다.

그룹 아래에서 중요 환경 보호하기#

그룹의 환경을 보호하려면 환경에 올바른 deployment_tier가 .gitlab-ci.yml에 정의되어 있는지 확인합니다.

UI 사용하기#

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Protected environments를 펼칩니다.
4. Environment 목록에서 보호할 환경의 배포 티어를 선택합니다.
5. Allowed to deploy 목록에서 배포 권한을 부여할 하위 그룹을 선택합니다.
6. Protect를 선택합니다.

API 사용하기#

REST API를 사용하여 그룹을 위한 보호된 환경을 구성합니다.

배포 승인#

보호된 환경을 사용하여 배포 전에 수동 승인을 요구할 수도 있습니다. 자세한 내용은 Deployment approvals를 참고합니다.

문제 해결#

Reporter가 다운스트림 파이프라인에서 보호된 환경에 배포하는 트리거 job을 실행할 수 없음#

trigger 키워드를 사용하는 job은 보호된 환경에 대한 배포 전용 접근 권한이 있더라도 실행되지 않을 수 있습니다.

이 문제는 트리거 job에 environment 키워드가 설정되어 있지 않을 때 발생합니다. 이 키워드가 없으면 GitLab이 job을 보호된 환경과 연결할 수 없으므로, job은 일반 CI/CD 권한 모델로 대체되며, 이 모델은 사용자의 배포 전용 역할에 job을 실행할 권한을 부여하지 않습니다.

이 문제를 해결하려면 트리거 job에 environment 키워드를 직접 추가합니다.