보호된 환경
환경은 테스트 및 운영 목적으로 사용할 수 있습니다.
다양한 권한을 가진 다른 사용자들이 배포 작업을 수행할 수 있기 때문에, 특정 환경을 무단 사용자로부터 보호할 수 있어야 하는데요.
기본적으로 보호된 환경은 적절한 권한을 가진 사람들만 배포할 수 있도록 보호하여 환경을 안전하게 보관합니다.
보호, 업데이트 또는 보호 해제를 하려면 최소한 Maintainer 역할이 필요합니다.
환경 보호
전제 조건:
- 그룹 또는 하위 그룹에 배포 허용 권한을 부여할 때, 보호된 환경을 구성하는 사용자는 추가할 그룹이나 하위 그룹의 직접 멤버이여야 합니다. 그렇지 않으면, 그룹 또는 하위 그룹이 드롭다운 디렉터리에 표시되지 않습니다. 자세한 내용은 이슈 #345140를 참조하세요.
- 설정 UI를 사용하여 그룹이나 프로젝트에 배포 허용 권한을 부여할 때, 해당 설정을 상속 받은 멤버에게는 이러한 권한이 부여되지 않습니다. 상속 받은 멤버에게도 이러한 권한을 부여하려면 API를 사용하세요. 자세한 내용은 이슈 #422392를 참조하세요.
환경 보호를 위해:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Settings > CI/CD를 선택합니다.
- 보호된 환경을 확장합니다.
- 환경 보호를 선택합니다.
- 환경 디렉터리에서 보호할 환경을 선택합니다.
-
배포 허용 디렉터리에서 역할, 사용자 또는 그룹을 선택하여
배포 액세스를 부여합니다. 기억하세요:
- 선택할 수 있는 역할은 두 가지가 있습니다:
- Maintainers: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
- Developers: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
- 이미 초대된 그룹만 선택할 수 있습니다.
- 사용자는 최소한 Developer 역할을 가져야 배포 허용 디렉터리에 표시됩니다.
- 선택할 수 있는 역할은 두 가지가 있습니다:
-
승인자 디렉터리에서 역할, 사용자 또는 그룹을 선택하여
배포 액세스를 부여합니다. 기억하세요:
- 선택할 수 있는 역할은 두 가지가 있습니다:
- Maintainers: Maintainer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
- Developers: Maintainer 및 Developer 역할을 가진 모든 프로젝트 사용자에게 액세스를 허용합니다.
- 이미 초대된 그룹만 선택할 수 있습니다.
- 사용자는 최소한 Developer 역할을 가져야 승인자 디렉터리에 표시됩니다.
- 선택할 수 있는 역할은 두 가지가 있습니다:
-
승인 규칙 섹션에서:
- 이 숫자가 규칙의 멤버 수보다 작거나 같은지 확인합니다.
- 이 기능에 대한 자세한 내용은 배포 승인을 참조하세요.
- 보호를 선택합니다.
보호된 환경은 이제 보호된 환경 디렉터리에 표시됩니다.
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}], "required_approval_count": 0}' \ --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.com/api/v4/projects/22034114/protected_environments"
이제 해당 그룹이 액세스 권한을 가지고 UI에 표시됩니다.
그룹 멤버십에 따른 환경 액세스
사용자는 그룹 멤버십 일환으로 보호된 환경에 액세스 권한을 부여받을 수 있습니다. 리포터 역할을 가진 사용자는 이 방법으로만 보호된 환경에 액세스 권한을 받을 수 있습니다.
배포 브랜치 액세스
개발자 역할을 하는 사용자는 다음 중 하나의 방법을 통해 보호된 환경에 액세스를 얻을 수 있습니다:
- 개별 기여자로서 권한을 통해.
- 그룹 멤버십을 통해.
만약 사용자가 프로덕션에 배포된 브랜치에 push 또는 merge 액세스도 가지고 있다면, 다음의 권한을 얻게 됩니다:
보호된 환경에 대한 배포 전용 액세스
보호된 환경에 액세스 권한이 부여된 사용자 중에 프로덕션에 배포된 브랜치에 push 또는 merge 액세스가 없는 경우, 해당 사용자들은 환경을 배포하는 데에만 액세스 권한을 부여받습니다. 프로젝트에 기록자(Role) 권한으로 추가된 초대된 그룹은 배포 전용 액세스 디렉터리에서 표시됩니다.
배포 전용 액세스를 추가하려면:
- 해당 그룹이 존재하지 않은 경우, 보호된 환경에 액세스 권한이 부여된 멤버가 있는 그룹을 만듭니다.
- 그룹을 초대하여 해당 프로젝트에 기록자(Role)로 추가합니다.
- 환경 보호 단계를 따릅니다.
환경 수정 및 보호 해제
유지자(Maintainer)는 다음을 할 수 있습니다:
- 허용된 배포 드롭다운 디렉터리에서 언제든지 기존의 보호된 환경을 업데이트합니다.
- 해당 환경에 대해 보호 해제 버튼을 선택하여 보호된 환경을 보호 해제합니다.
한 번 환경이 보호 해제되면, 모든 액세스 항목이 삭제되고 환경이 다시 보호되면 다시 입력해야 합니다.
더 많은 정보는 배포 안전성을 참조하십시오.
그룹 수준 보호된 환경
- GitLab 14.0에서 group_level_protected_environments이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
- GitLab 14.3에서 피처 플래그가 제거되었습니다.
- GitLab 14.3에서 일반적으로 사용 가능해졌습니다.
일반적으로 대규모 기업 조직에서는 개발자 및 운영자 간에 명시적 권한 경계가 있습니다. 개발자는 코드를 작성하고 테스트하며, 운영자는 응용 프로그램을 배포하고 모니터링합니다. 그룹 수준 보호된 환경을 사용하면 운영자는 중요한 환경에 대한 개발자의 액세스를 제한할 수 있습니다. 그룹 수준 보호된 환경은 프로젝트 수준 보호된 환경을 그룹 수준으로 확장합니다.
배포 권한은 다음 표에 설명된 대로 이해할 수 있습니다:
환경 | 개발자 | 운영자 | 카테고리 |
---|---|---|---|
개발 | 허용됨 | 허용됨 | 하위 환경 |
테스트 | 허용됨 | 허용됨 | 하위 환경 |
스테이징 | 거부됨 | 허용됨 | 상위 환경 |
프로덕션 | 거부됨 | 허용됨 | 상위 환경 |
(참고: 위키백과의 배포 환경)
그룹 수준 보호된 환경 명칭
프로젝트 수준 보호된 환경과 달리, 그룹 수준 보호된 환경은 환경 배포 티어를 이름으로 사용합니다.
하나의 그룹에는 고유한 이름을 가진 여러 프로젝트 환경이 있을 수 있습니다. 예를 들어, Project-A는 gprd
환경을 가지고 있고, Project-B는 Production
환경을 가지고 있으므로, 특정 환경 이름을 보호하는 것은 잘 확장되지 않습니다. 배포 티어를 사용함으로써, 둘 다 production
배포 티어로 인식되어 동시에 보호됩니다.
그룹 수준 멤버십 설정
- 운영자는 기본 유지자(Maintainer) 역할에서 상위 그룹의 소유자(Owner) + 역할로 변경되어야 합니다. 이 권한 변경 사항은 GitLab 15.3부터 group_level_protected_environment_settings_permission이라는 플래그로 도입되었습니다. 기본적으로 활성화됩니다.
- GitLab 15.4에서 피처 플래그가 제거되었습니다.
그룹 수준 보호된 환경의 효과를 극대화하기 위해서는, 그룹 수준 멤버십을 올바르게 구성해야 합니다:
- 운영자는 상위 그룹에서 최상위 그룹의 소유자(Owner) 역할을 가져야 합니다. 그들은 상위 환경(예: 프로덕션)에 대한 CI/CD 구성을 그룹 수준 설정 페이지에서 유지할 수 있으며, 이 구성은 읽기 전용 항목으로 하위 프로젝트로 상속됩니다. 이를 통해 운영자만이 조직 전반의 배포 규칙을 구성할 수 있도록 보장합니다.
- 개발자는 최상위 그룹에 대해 Developer 역할을 넘어서거나 하위 프로젝트에 대해 명시적으로 Owner 역할을 부여받아서는 안 됩니다. 그들은 최상위 그룹의 CI/CD 구성에 액세스할 수 없으므로 운영자가 중요한 구성이 실수로 변경되는 것을 방지할 수 있습니다.
- 하위 그룹 및 하위 프로젝트의 경우:
- 하위 그룹에 대한 경우, 상위 그룹이 그룹 수준 보호된 환경을 구성한 경우에는 하위 그룹에서 이를 무시할 수 없습니다.
- 프로젝트 수준 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다. 그룹 수준 및 프로젝트 수준의 환경 구성이 모두 존재하는 경우, 배포 작업을 실행하려면 사용자가 모든 규칙 집합에서 허용되어야 합니다.
- 최상위 그룹의 프로젝트 또는 하위 그룹에서, 개발자들은 그들의 하위 환경(예:
testing
)을 조정하기 위해 안심하고 유지자(Maintainer) 역할을 부여받을 수 있습니다.
이러한 구성이 되어 있으면:
- 프로젝트에서 배포 작업을 실행하려는 사용자가 환경에 배포할 수 있는 경우, 배포 작업이 진행됩니다.
- 프로젝트에서 배포 작업을 실행하려는 사용자가 환경에 배포할 수 없는 경우, 배포 작업이 오류 메시지와 함께 실패합니다.
그룹의 중요한 환경 보호
그룹 수준의 환경을 보호하려면, 환경이 올바른 deployment_tier
가 .gitlab-ci.yml
에 정의되어 있는지 확인하십시오.
UI 사용
- GitLab 15.1에서 도입되었습니다.
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 설정 > CI/CD를 선택합니다.
- 보호된 환경을 확장합니다.
- 환경 디렉터리에서 배포 환경의 티어를 선택합니다.
- 배포할 수 있는 사용자 디렉터리에서 서브그룹을 선택하여 배포 액세스를 부여합니다.
- 보호를 선택합니다.
API 사용
REST API를 사용하여 그룹 수준의 보호된 환경을 구성합니다.
배포 승인
보호된 환경은 배포 전에 매뉴얼 승인을 요구하는 데 사용할 수 있습니다. 자세한 내용은 배포 승인을 참조하세요.
문제 해결
리포터가 하류 파이프라인에서 보호된 환경으로 배포하는 트리거 작업을 실행할 수 없음
보호된 환경에 대한 배포 전용 액세스가 있는 사용자는 trigger
키워드로 작업을 실행할 수 없을 수 있습니다. 이는 작업이 보호된 환경과 연결시키기 위한 environment
키워드 정의가 누락되어 있기 때문에 발생합니다. 따라서 해당 작업은 일반 CI/CD 권한 모델을 사용하는 표준 작업으로 인식됩니다.
trigger
키워드와 함께 environment
키워드를 지원하는 더 많은 정보는 이 이슈에서 확인하세요.