보호된 환경
환경은 테스트 및 프로덕션 목적으로 모두 사용할 수 있습니다.
배포 작업은 서로 다른 역할을 가진 다른 사용자들에 의해 시작될 수 있기 때문에, 특정 환경을 무단 사용자의 영향으로부터 보호할 수 있는 능력이 중요합니다.
기본적으로 보호된 환경은 적절한 권한을 가진 사람들만 배포할 수 있도록하여 환경을 안전하게 보호합니다.
환경을 보호하거나 업데이트하거나 보호 설정을 해제하려면 Maintainer 역할 이상을 가지고 있어야 합니다.
환경 보호
필수 사항:
- Allowed to deploy 권한을 승인자 그룹에 부여할 때, 보호된 환경을 구성하는 사용자는 추가 할 권한 그룹의 직접 멤버 여야만 합니다. 그렇지 않으면 그룹 또는 서브 그룹이 드롭다운 목록에 표시되지 않습니다. 자세한 내용은 이슈 #345140을 참조하세요.
- 승인자 그룹 또는 프로젝트에 Approvers 권한을 부여할 때, 기본적으로 승인자 그룹이나 프로젝트의 직접 멤버만이 이러한 권한을 얻습니다. 승인자 그룹 또는 프로젝트의 상속 멤버에 대해 이러한 권한을 부여하려면:
- 그룹 상속 활성화 확인란을 선택하세요.
- API 사용하세요.
환경을 보호하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 설정 > CI/CD를 선택합니다.
- 보호된 환경을 확장합니다.
- 환경 보호를 선택합니다.
- 환경 목록에서 보호할 환경을 선택합니다.
-
Allowed to deploy 목록에서 배포 액세스를 부여하려는 역할, 사용자 또는 그룹을 선택합니다. 기억하세요:
- 선택할 수 있는 역할이 두 가지 있습니다:
- Maintainers: Maintainer 역할을 가진 해당 프로젝트의 모든 사용자에게 액세스를 허용합니다.
- Developers: Maintainer 및 Developer 역할을 가진 해당 프로젝트의 모든 사용자에게 액세스를 허용합니다.
- 프로젝트에 초대된 그룹도 선택할 수 있습니다. Reporter 역할로 프로젝트에 추가된 초대된 그룹은 보호된 환경의 배포 전용 목록에 표시됩니다.
- 특정 사용자도 선택할 수 있습니다. 사용자는 최소한 Developer 역할을 가지고 있어야 Allowed to deploy 목록에 나타납니다.
- 선택할 수 있는 역할이 두 가지 있습니다:
-
Approvers 목록에서 배포 액세스를 부여하려는 역할, 사용자 또는 그룹을 선택합니다. 기억하세요:
- 선택할 수 있는 역할이 두 가지 있습니다:
- Maintainers: Maintainer 역할을 가진 해당 프로젝트의 모든 사용자에게 액세스를 허용합니다.
- Developers: Maintainer 및 Developer 역할을 가진 해당 프로젝트의 모든 사용자에게 액세스를 허용합니다.
- 프로젝트에 초대된 그룹만 선택할 수 있습니다.
- 사용자는 최소한 Developer 역할을 가지고 있어야 Approvers 목록에 나타납니다.
- 선택할 수 있는 역할이 두 가지 있습니다:
-
Approval rules 섹션에서:
- 이 숫자가 규칙의 멤버 수보다 작거나 같은지 확인합니다.
- 이 기능에 대한 자세한 내용은 배포 승인을 확인하세요.
- 보호를 선택합니다.
보호된 환경이 이제 보호된 환경 목록에 나타납니다.
API 사용하여 환경 보호
대신, API를 사용하여 환경을 보호할 수 있습니다:
-
환경을 생성하는 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}
-
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에 나타납니다.
그룹 멤버십을 통한 환경 접근
사용자는 그룹 멤버십의 일환으로 보호된 환경에 액세스할 수 있습니다. 리포터 역할을 가진 사용자는 이 방법을 통해 보호된 환경에만 액세스할 수 있습니다.
배포 브랜치 접근
개발자 역할을 하는 사용자는 다음 중 하나의 방법으로 보호된 환경에 액세스할 수 있습니다:
- 개별 기여자로서 역할을 통해.
- 그룹 멤버십을 통해.
사용자가 프로덕션에서 배포된 브랜치에 푸시 또는 머지 액세스도 있는 경우 다음과 같은 권한이 있습니다:
보호된 환경에 대한 배포 전용 액세스
보호된 환경에 액세스를 허용받지만 해당 환경에 배포된 브랜치에 푸시 또는 머지 액세스가 없는 사용자는 환경을 배포할 수 있는 액세스만 허용받습니다. 프로젝트에 초대된 그룹은 리포터 역할로 추가되며, 배포 전용 액세스를 위한 드롭다운 목록에 나타납니다.
배포 전용 액세스를 추가하려면:
- 해당 그룹이 이미 존재하지 않는 경우 보호된 환경에 액세스할 수 있는 구성원으로 구성된 그룹을 만듭니다.
- 그룹을 프로젝트로 초대하여 리포터 역할로 추가합니다.
- 환경 보호 단계를 따릅니다.
환경 수정 및 보호 해제
유지자는 다음과 같은 권한이 있습니다:
- 허용된 배포 드롭다운 목록에서 언제든지 기존의 보호된 환경을 업데이트할 수 있습니다.
- 해당 환경의 Unprotect 버튼을 선택하여 보호된 환경을 보호 해제할 수 있습니다.
환경이 보호 해제된 후에는 모든 액세스 항목이 삭제되며, 환경이 다시 보호되면 다시 입력해야 합니다.
자세한 내용은 배포 안전성을 참조하십시오.
그룹 수준 보호된 환경
일반적으로 대규모 기업 조직은 개발자와 운영자 간에 명시적인 권한 경계를 가지고 있습니다. 개발자는 코드를 작성하고 테스트하고, 운영자는 응용 프로그램을 배포하고 모니터링합니다. 그룹 수준 보호된 환경을 사용하면 운영자는 개발자로부터 중요한 환경에 대한 액세스를 제한할 수 있습니다. 그룹 수준 보호된 환경은 프로젝트 수준 보호된 환경을 그룹 수준으로 확장합니다.
배포 권한은 다음 표에서 설명할 수 있습니다:
환경 | 개발자 | 운영자 | 카테고리 |
---|---|---|---|
개발 | 허용 | 허용 | 하위 환경 |
테스트 | 허용 | 허용 | 하위 환경 |
스테이징 | 거부 | 허용 | 상위 환경 |
프로덕션 | 거부 | 허용 | 상위 환경 |
(참고: Wikipedia의 배포 환경)
그룹 수준 보호된 환경 이름
프로젝트 수준 보호된 환경과는 달리, 그룹 수준 보호된 환경은 그들의 이름으로 배포 티어를 사용합니다.
하나의 그룹은 고유한 이름을 가진 여러 프로젝트 환경으로 구성될 수 있습니다. 예를 들어, Project-A는 gprd
환경을 가지고 있고, Project-B는 Production
환경을 가지고 있으므로 특정 환경 이름을 보호하는 것은 확장성이 떨어집니다. 배포 티어를 사용함으로써 두 환경이 production
배포 티어로 인식되어 동시에 보호됩니다.
그룹 수준 멤버십 구성
- 운영자는 원래 유지자 역할에서 Owner+ 역할이 필요하며, 이 역할 변경은 GitLab 15.3부터 도입된
group_level_protected_environment_settings_permission
이라는 플래그에 의해 소개되었습니다 (https://gitlab.com/gitlab-org/gitlab/-/issues/369873). 기본적으로 활성화됩니다.- GitLab 15.4에서 기능 플래그가 제거되었습니다.
그룹 수준 보호된 환경의 효과를 극대화하려면 그룹 수준 멤버십을 올바르게 구성해야 합니다:
- 운영자는 상위 그룹에 Owner 역할을 주어야 합니다. 그들은 상위 환경(예: 프로덕션)을 위한 CI/CD 구성을 그룹 수준 설정 페이지에서 유지할 수 있으며, 이는 그룹 수준 보호된 환경, 그룹 수준 러너 및 그룹 수준 클러스터를 포함합니다. 이러한 구성은 읽기 전용 항목으로 자식 프로젝트에 상속됩니다. 이로써 운영자만이 조직 전체 배포 규칙을 구성할 수 있도록 보장합니다.
- 개발자는 상위 그룹에 Developer 역할을 넘어서거나 하위 프로젝트에 대해 명시적으로 Owner 역할을 주어서는 안 됩니다. 이들은 상위 그룹의 CI/CD 구성에 액세스할 수 없으므로, 운영자가 중요한 구성이 실수로 변경되지 않도록 보장할 수 있습니다.
- 서브그룹 및 자식 프로젝트에 대해서:
- 서브그룹에 대해 상위 그룹이 그룹 수준 보호된 환경을 구성했을 경우, 하위 그룹은 이를 재정의할 수 없습니다.
- 프로젝트 수준 보호된 환경은 그룹 수준 설정과 결합될 수 있습니다. 그룹 수준 및 프로젝트 수준 환경 구성이 모두 존재하는 경우, 배포 작업을 실행하려면 사용자는 모든 규칙에 허용되어야 합니다.
- 상위 그룹 또는 하위 그룹에서, 개발자는 자신의 하위 환경(
testing
등)을 조정하기 위해 안전하게 Maintainer 역할을 할당받을 수 있습니다.
이러한 구성을 갖추고 있는 경우:
- 사용자가 프로젝트에서 배포 작업을 실행할 수 있고 해당 환경에 배포가 허용된 경우, 배포 작업을 진행합니다.
- 사용자가 프로젝트에서 배포 작업을 실행하려 하지만 해당 환경에 배포가 허용되지 않은 경우, 배포 작업이 오류 메시지와 함께 실패합니다.
그룹의 중요한 환경 보호
그룹 수준 환경을 보호하려면 .gitlab-ci.yml
에 정의된 올바른 deployment_tier
를 갖추도록 합니다.
UI 사용
- GitLab 15.1에 도입되었습니다.
- 왼쪽 사이드바에서 검색 또는 들어가기를 선택하여 그룹을 찾습니다.
- 설정 > CI/CD를 선택합니다.
- 보호된 환경을 펼칩니다.
- 환경 목록에서 배포 환경의 배포 티어를 선택합니다.
- 허용된 배포 목록에서 서브그룹에 배포 액세스를 부여하려는 그룹을 선택합니다.
- 보호를 선택합니다.
API 사용하기
REST API를 사용하여 그룹 레벨의 보호된 환경을 구성합니다.
배포 승인
보호된 환경은 배포 전에 수동 승인이 필요한 경우에도 사용할 수 있습니다. 자세한 정보는 배포 승인을(를) 참조하세요.
문제 해결
기자가 다운스트림 파이프라인에서 보호된 환경으로 배포하는 트리거 작업을 실행할 수 없음
보호된 환경에 대한 배포 전용 액세스를 갖고 있는 사용자는 trigger
키워드를 사용하는 작업을 실행할 수 없을 수 있습니다. 이는 작업이 보호된 환경과 연결되기 위한 environment
키워드 정의가 누락되어 있기 때문에 해당 작업이 일반적인 CI/CD 권한 모델을 사용하는 표준 작업으로 인식되기 때문입니다.
trigger
키워드와 함께 environment
키워드를 지원하는 상세 정보는 이 이슈를 참조하세요.