보호된 환경
환경은 테스트와
프로덕션을 위해 사용할 수 있습니다.
배포 작업은 다양한 역할을 가진 다양한 사용자가 수행할 수 있기 때문에,
무단 사용자의 영향을 받지 않도록 특정 환경을 보호할 수 있는 것이 중요합니다.
기본적으로, 보호된 환경은 적절한 권한을 가진 사람만 배포할 수 있도록
보장하여 환경을 안전하게 유지합니다.
환경을 보호, 업데이트 또는 보호 해제하려면 최소한
유지 관리자(Maintainer) 역할이 필요합니다.
환경 보호하기
사전 요구 사항:
- 승인자 그룹에 배포 허용 권한을 부여할 때,
보호된 환경을 구성하는 사용자가 추가될 승인자 그룹의 직접 구성원이어야 합니다.
그렇지 않으면 그룹이나 하위 그룹이 드롭다운 목록에 나타나지 않습니다.
자세한 내용은 이슈 #345140을 참조하세요. - 승인자 그룹이나 프로젝트에 승인자 권한을 부여할 때,
기본적으로 승인자 그룹 또는 프로젝트의 직접 구성원만 이러한
권한을 받습니다. 이러한 권한을 승인자 그룹 또는 프로젝트의 상속된
구성원에게도 부여하려면:- 그룹 상속 활성화 체크박스를 선택합니다.
- API 사용.
환경을 보호하려면:
-
왼쪽 사이드바에서 검색 또는 이동을 선택하고
프로젝트를 찾습니다. -
설정 > CI/CD를 선택합니다.
-
보호된 환경을 확장합니다.
-
환경 보호를 선택합니다.
-
환경 목록에서 보호하려는 환경을 선택합니다.
-
배포 허용 목록에서 배포 액세스를 부여할 역할, 사용자 또는
그룹을 선택합니다. 다음 사항을 유의하세요: -
승인자 목록에서 배포 액세스를 부여할 역할, 사용자 또는
그룹을 선택합니다. 다음 사항을 유의하세요:- 선택할 수 있는 두 가지 역할이 있습니다:
-
유지 관리자(Maintainers): 유지 관리자 역할을 가진 모든
프로젝트 사용자가 액세스할 수 있도록 합니다. -
개발자(Developers): 유지 관리자 및 개발자 역할을 가진 모든
프로젝트 사용자가 액세스할 수 있도록 합니다.
-
유지 관리자(Maintainers): 유지 관리자 역할을 가진 모든
- 프로젝트에 이미 초대된
그룹만 선택할 수 있습니다. - 사용자는 승인자 목록에 나타나려면 최소한 개발자 역할이 있어야 합니다.
- 선택할 수 있는 두 가지 역할이 있습니다:
-
승인 규칙 섹션에서:
- 이 숫자가 규칙에 있는 구성원의 수보다 작거나 같도록
해야 합니다. - 이 기능에 대한 자세한 내용은 배포 승인을 참조하세요.
- 이 숫자가 규칙에 있는 구성원의 수보다 작거나 같도록
- 보호를 선택합니다.
보호된 환경이 이제 보호된 환경 목록에 나타납니다.
API를 사용하여 환경 보호하기
대안으로, API를 사용하여 환경을 보호할 수 있습니다:
-
환경을 생성하는 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} -
UI를 사용하여 새 그룹 만들기를 선택하세요.
예를 들어, 이 그룹은protected-access-group이라고 하며 그룹 ID는9899826입니다.
이 단계의 나머지 예제는 이 그룹을 사용합니다.
-
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} -
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} -
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 role로 프로젝트에 추가되면 배포 전용 액세스를 위한 드롭다운 목록에 표시됩니다.
배포 전용 액세스를 추가하려면:
- 보호된 환경에 대한 액세스 권한이 부여된 멤버로 그룹을 생성합니다(아직 존재하지 않는 경우).
- 그룹 초대를 Reporter 역할로 프로젝트에 초대합니다.
- 환경 보호에서 설명하는 단계를 따릅니다.
환경 수정 및 보호 해제
유지 관리자는 다음 작업을 수행할 수 있습니다:
-
Allowed to Deploy 드롭다운 목록에서 액세스를 변경하여 기존 보호된 환경을 언제든지 업데이트합니다.
-
해당 환경에 대해 Unprotect 버튼을 선택하여 보호된 환경의 보호를 해제합니다.
환경의 보호가 해제되면 모든 액세스 항목이 삭제되며, 환경이 다시 보호될 때 재입력해야 합니다.
자세한 내용은 배포 안전성을 참조하세요.
그룹 수준의 보호된 환경
일반적으로 대규모 기업 조직은 개발자와 운영자 간의 명확한 권한 경계가 있습니다.
개발자는 코드를 빌드하고 테스트하며, 운영자는 애플리케이션을 배포하고 모니터링합니다.
그룹 수준의 보호된 환경을 사용하면 운영자는 개발자로부터 중요한 환경에 대한 액세스를 제한할 수 있습니다.
그룹 수준의 보호된 환경은 프로젝트 수준의 보호된 환경을
그룹 수준으로 확장합니다.
배포 권한은 다음 표로 설명할 수 있습니다:
| 환경 | 개발자 | 운영자 | 범주 |
|---|---|---|---|
| 개발 | 허용됨 | 허용됨 | 하위 환경 |
| 테스트 | 허용됨 | 허용됨 | 하위 환경 |
| 스테이징 | 허용되지 않음 | 허용됨 | 상위 환경 |
| 프로덕션 | 허용되지 않음 | 허용됨 | 상위 환경 |
(참조: 위키피디아의 배포 환경)
그룹 수준의 보호된 환경 이름
프로젝트 수준의 보호된 환경과는 달리, 그룹 수준의 보호된 환경은 배포 등급을 이름으로 사용합니다.
그룹은 고유한 이름을 가진 여러 프로젝트 환경으로 구성될 수 있습니다.
예를 들어, Project-A는 gprd 환경을 가지고 Project-B는 Production 환경을 가지고 있으므로 특정 환경 이름을 보호하는 것은 잘 확장되지 않습니다.
배포 등급을 사용하면 두 환경 모두 production 배포 등급으로 인식되며 동시에 보호됩니다.
그룹 수준의 멤버십 구성
그룹 수준의 보호된 환경의 효과를 극대화하려면,
group-level memberships를 올바르게 구성해야 합니다:
-
운영자는 최상위 그룹에 대해 Owner 역할을 부여받아야 합니다.
그들은 그룹 수준 설정 페이지에서 상위 환경(예: 프로덕션)의 CI/CD 설정을 유지 관리할 수 있으며,
여기에는 그룹 수준의 보호된 환경, 그룹 수준의 러너,
그룹 수준의 클러스터가 포함됩니다. 이 설정은 하위 프로젝트에 읽기 전용 항목으로 상속됩니다.
이는 오직 운영자만이 조직 전체의 배포 규칙 세트를 구성할 수 있도록 보장합니다. -
개발자는 최상위 그룹에 대해 Developer 역할 이하로만 부여받아야 하거나
하위 프로젝트에 대해 명시적으로 Owner 역할을 부여받아야 합니다.
그들은 최상위 그룹의 CI/CD 설정에 접근할 수 없으므로, 운영자는
중요한 구성이 개발자에 의해 우연히 변경되지 않도록 보장할 수 있습니다. -
하위 그룹 및 하위 프로젝트에 대한 경우:
-
하위 그룹에 관해서는,
상위 그룹이 그룹 수준의 보호된 환경을 구성한 경우 하위 그룹은 이를 무시할 수 없습니다. -
프로젝트 수준의 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다.
그룹 수준 및 프로젝트 수준 환경 구성이 모두 존재하는 경우, 배포 작업을 실행하기 위해서는
사용자 모두의 둘 규칙 세트에서 허용되어야 합니다. -
최상위 그룹의 프로젝트나 하위 그룹에서는 개발자에게
하위 환경(예:testing)을 조정하기 위해 Maintainer 역할을 안전하게 부여할 수 있습니다.
-
이러한 구성을 갖추면:
-
사용자가 프로젝트에서 배포 작업을 실행하려고 하고
환경에 배포할 수 있는 권한이 있는 경우, 배포 작업이 진행됩니다. -
사용자가 프로젝트에서 배포 작업을 실행하려고 하지만
환경에 배포할 수 없는 경우, 배포 작업이 오류 메시지와 함께 실패합니다.
그룹에 대한 중요한 환경 보호
그룹 수준의 환경을 보호하려면, .gitlab-ci.yml 파일에서 올바른
deployment_tier가 정의되어 있는지 확인하십시오.
UI 사용하기
- Introduced in GitLab 15.1.
- 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
- Settings > CI/CD를 선택합니다.
- Protected environments를 확장합니다.
- Environment 목록에서 보호할 환경의 배포 등급을 선택합니다.
- Allowed to deploy 목록에서 배포 액세스를 부여할 하위 그룹을 선택합니다.
- Protect를 선택합니다.
API 사용하기
REST API를 사용하여 그룹 수준의 보호된 환경을 구성합니다.
배포 승인
보호된 환경은 배포 전에 수동 승인을 요구하는 데 사용할 수도 있습니다. 추가 정보는 Deployment approvals를 참조하십시오.
문제 해결
리포터가 하위 파이프라인의 보호된 환경에 배포하는 트리거 작업을 실행할 수 없음
Protected environments에 대한 배포 전용 액세스가 있는 사용자는 trigger 키워드가 있는 작업을 실행할 수 없을 수 있습니다.
이는 작업이 보호된 환경과 작업을 연결하는 environment 키워드 정의가 부족하기 때문에 발생합니다.
따라서 이 작업은 정기 CI/CD 권한 모델을 사용하는 표준 작업으로 인식됩니다.
trigger 키워드와 함께 environment 키워드 지원에 대한 자세한 내용은 이 문제를 참조하십시오.
도움말