보호된 환경

Tier: 프리미엄, 얼티밋 Offering: GitLab.com, 자체 관리형, GitLab Dedicated

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

다양한 사용자가 다른 역할로 배포 작업을 수행할 수 있기 때문에, 특정 환경을 무단 사용자의 영향으로부터 보호할 수 있어야 합니다.

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

참고: GitLab 관리자는 보호된 환경을 포함한 모든 환경을 사용할 수 있습니다.

환경을 보호하거나 업데이트하거나 보호 해제하려면 적어도 유지자 역할이 있어야 합니다.

환경 보호

전제 조건:

  • Deploy 허용 권한을 그룹이나 하위 그룹에 부여할 때, 보호된 환경을 구성하는 사용자는 추가할 그룹이나 하위 그룹의 직접 멤버여야만 합니다. 그렇지 않으면 그룹이나 하위 그룹이 드롭다운 목록에 표시되지 않습니다. 자세한 내용은 이슈 #345140을 참조하십시오.
  • 설정 UI를 사용하여 그룹이나 프로젝트에 Deploy 허용 권한을 부여할 때, 그룹이나 프로젝트의 직접 멤버만이 이러한 권한을 받습니다. 상속 멤버에게도 이러한 권한을 부여하려면 API를 사용하십시오. 자세한 내용은 이슈 #422392을 참조하십시오.

환경 보호 방법:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. 보호된 환경을 확장합니다.
  4. 환경 보호를 선택합니다.
  5. 환경 목록에서 보호하려는 환경을 선택합니다.
  6. Deploy 허용 목록에서 역할, 사용자 또는 그룹을 선택하여 배포 액세스를 부여합니다. 유의해야 할 사항은 다음과 같습니다.
    • 선택할 수 있는 두 가지 역할이 있습니다:
      • 유지자: 유지자 역할을 가진 프로젝트의 모든 사용자에게 액세스를 허용합니다.
      • 개발자: 유지자 및 개발자 역할을 가진 프로젝트의 모든 사용자에게 액세스를 허용합니다.
    • 이미 초대된 그룹만 선택할 수 있습니다.
    • 사용자는 Deploy 허용 목록에 나타나려면 적어도 개발자 역할이 있어야 합니다.
  7. 승인자 목록에서 역할, 사용자 또는 그룹을 선택하여 배포 액세스를 부여합니다. 유의해야 할 사항은 다음과 같습니다.
    • 선택할 수 있는 두 가지 역할이 있습니다:
      • 유지자: 유지자 역할을 가진 프로젝트의 모든 사용자에게 액세스를 허용합니다.
      • 개발자: 유지자 및 개발자 역할을 가진 프로젝트의 모든 사용자에게 액세스를 허용합니다.
    • 이미 초대된 그룹만 선택할 수 있습니다.
    • 사용자는 승인자 목록에 나타나려면 적어도 개발자 역할이 있어야 합니다.
  8. 승인 규칙 섹션에서:
    • 이 숫자를 해당 규칙의 멤버 수보다 작거나 같도록 합니다.
    • 이 기능에 대한 자세한 내용은 배포 승인을 참조하십시오.
  9. 보호를 선택합니다.

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

API를 사용하여 환경 보호

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

  1. 환경을 생성하는 CI가 있는 프로젝트를 사용하십시오. 예를들어: 

    stages:
  - test
  - deploy

test:
  stage: test
  script:
    - 'echo "애플리케이션 테스트 중: ${CI_PROJECT_NAME}"'

production:
  stage: deploy
  when: manual
  script:
    - 'echo "${CI_ENVIRONMENT_NAME}로 배포 중"'
  environment:
    name: ${CI_JOB_NAME}

  2. UI를 사용하여 새 그룹을 생성하십시오. 예를들어, protected-access-group이라는 이 그룹의 그룹 ID가 9899826인 것으로 하겠습니다. 나머지 단계 예시에서는 이 그룹을 사용합니다.

    Group Access

  3. API를 사용하여 사용자를 보고자로 추가하십시오: 

    $ 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를 사용하여 프로젝트에 그룹을 보고자로로 추가하십시오: 

    $ 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}], "required_approval_count": 0}' \
     --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"

이제 해당 그룹은 액세스 권한이 있으며 UI에서 볼 수 있습니다.

그룹 멤버십에 의한 환경 접근

사용자는 그룹 멤버십의 일부로 보호된 환경에 액세스할 수 있습니다. 리포터 역할을 하는 사용자는 이 메소드를 통해 보호된 환경에만 액세스할 수 있습니다.

배포 브랜치 액세스

개발자 역할을 하는 사용자는 보호된 환경에 액세스할 수 있습니다. 이를 위해 여러 방법 중 하나를 사용할 수 있습니다:

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

사용자가 프로덕션에 배포된 브랜치에 푸시하거나 머지할 수 있는 경우, 다음 권한이 있습니다:

보호된 환경에 대한 배포 전용 액세스

보호된 환경에 대한 액세스가 부여된 사용자이지만 해당 환경에 배포된 브랜치에 푸시하거나 머지할 수 없는 경우, 해당 사용자는 환경을 배포할 수 있는 권한만 부여됩니다. 초대된 그룹은 리포터 역할로 프로젝트에 추가되며, 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.

배포 전용 액세스를 추가하려면:

  1. 해당 그룹이 아직 존재하지 않은 경우 액세스 권한을 부여받은 회원으로 구성된 그룹을 생성합니다.
  2. 그룹을 초대하여 리포터 역할을 부여합니다.
  3. 환경 보호 단계를 따릅니다.

환경 수정 및 보호 해제

유지자는 다음을 수행할 수 있습니다:

  • 허용된 배포 드롭다운 목록에서 액세스를 언제든지 변경하여 기존의 보호된 환경을 업데이트할 수 있습니다.
  • 해당 환경의 보호 해제 버튼을 선택하여 보호된 환경을 해제할 수 있습니다.

보호를 해제한 후에는 모든 액세스 항목이 삭제되며, 환경을 다시 보호하려면 다시 입력해야 합니다.

추가 정보는 배포 안전성을 참조하십시오.

그룹 수준 보호된 환경

일반적으로 대규모 기업 조직은 개발자와 운영자 간 명시적인 권한 분리를 가지고 있습니다. 개발자는 코드를 작성하고 테스트하며, 운영자는 응용 프로그램을 배포하고 모니터링합니다. 그룹 수준 보호된 환경을 사용하면 운영자는 필수적인 환경에 대한 액세스를 개발자로부터 제한할 수 있습니다. 그룹 수준 보호된 환경은 프로젝트 수준 보호된 환경을 그룹 수준으로 확장합니다.

배포의 권한은 다음 표에 설명되어 있습니다:

환경 개발자 운영자 카테고리
개발 허용됨 허용됨 하위 환경
테스트 허용됨 허용됨 하위 환경
스테이징 허용되지 않음 허용됨 상위 환경
프로덕션 허용되지 않음 허용됨 상위 환경

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

그룹 수준 보호된 환경 이름

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

그룹은 고유한 이름을 가진 여러 프로젝트 환경으로 구성될 수 있습니다. 예를 들어, 프로젝트-A에는 gprd 환경이 있고, 프로젝트-B에는 Production 환경이 있으므로, 특정 환경 이름의 보호는 쉽지 않습니다. 배포 티어를 사용함으로써 두 환경이 production 배포 티어로 인식되어 동시에 보호됩니다.

그룹 수준 멤버십 구성

  • 운영자는 원래 유지자 이상 역할을 가져야 하고, 이 역할 변경은 GitLab 15.3에서 플래그인 ‘group_level_protected_environment_settings_permission’를 통해 도입되었습니다. 기본적으로 활성화됨.
  • GitLab 15.4에서 기능 플래그가 제거되었습니다.

그룹 수준 보호된 환경의 효과를 극대화하기 위해, 그룹 수준 멤버십을 올바르게 구성해야 합니다:

  • 운영자는 최상위 그룹에 대한 소유자 역할을 할당받아야 합니다. 그들은 그룹 수준 설정 페이지에서 상위 환경(예: 프로덕션)에 대한 CI/CD 구성을 관리할 수 있으며, 이는 그룹 수준 보호된 환경, 그룹 수준 러너, 및 그룹 수준 클러스터를 포함합니다. 이러한 구성은 읽기 전용 항목으로 하위 프로젝트에 상속됩니다. 이에 따라 운영자만이 조직 전반에 걸친 배포 규칙을 구성할 수 있습니다.
  • 개발자는 최상위 그룹에 대한 Developer 역할 이상을 할당받거나 하위 프로젝트에 대해 명시적으로 Owner 역할을 할당받아야 합니다. 이로써 그들은 최상위 그룹의 CI/CD 구성에 액세스하지 못하므로 운영자는 실수로 중요한 구성을 변경하지 못하도록 할 수 있습니다.
  • 하위 그룹 및 프로젝트의 경우:
    • 하위 그룹의 경우, 상위 그룹이 그룹 수준 보호된 환경을 구성한 경우 하위 그룹에서는 해당 환경을 무시할 수 없습니다.
    • 프로젝트 수준 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다. 그룹 수준 및 프로젝트 수준 환경 구성이 모두 존재하는 경우, 배포 작업을 실행하려면 사용자가 모두 규칙 세트에서 허용되어야 합니다.
    • 최상위 그룹이나 하위 그룹에서 개발자는 자신의 하위 환경(예: testing)을 조정하기 위해 안전하게 Maintainer 역할을 할당받을 수 있습니다.

위 구성이 완료된 경우:

  • 프로젝트에서 사용자가 배포 작업을 실행할 권한이 있다면, 배포 작업이 진행됩니다.
  • 프로젝트에서 사용자가 배포 작업을 실행할 권한이 없다면, 배포 작업은 오류 메시지와 함께 실패합니다.

그룹 내 중요한 환경 보호

그룹 수준의 환경을 보호하려면 .gitlab-ci.yml에서 올바른 deployment_tier이 정의되어 있는지 확인하세요.

UI 사용

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. 보호된 환경을 확장합니다.
  4. 환경 목록에서 보호하려는 배포 환경의 등급을 선택합니다.
  5. 배포 허용 대상 목록에서 하위 그룹에 배포 액세스 권한을 부여할 그룹을 선택합니다.
  6. 보호을(를) 선택합니다.

API 사용

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

배포 승인

보호된 환경은 배포 전 수동 승인이 필요할 때도 사용할 수 있습니다. 자세한 내용은 배포 승인을 참조하십시오.

문제 해결

리포터가 하위 파이프라인에서 보호된 환경으로 배포하는 트리거 작업을 실행할 수 없음

보호된 환경에 대한 배포 전용 액세스를 가진 사용자는 trigger 키워드로 작업을 실행하는 것이 어려울 수 있습니다. 이는 작업이 보호된 환경과 연결되도록 하는 environment 키워드 정의가 누락되어 있기 때문에 발생합니다. 따라서 해당 작업은 일반 CI/CD 권한 모델을 사용하는 표준 작업으로 인식됩니다.

tigger 키워드와 함께 environment 키워드를 지원하기 위한 자세한 내용은 이 문제를 참조하십시오.