- 중요한 환경에 대한 쓰기 액세스 제한
- 한 번에 한 개의 배포 작업만 실행하도록 보장
- 오래된 배포 작업 방지
- 배포 동결 기간 동안 배포 방지
- 프로덕션 비밀 정보 보호
- 배포용 별도 프로젝트
.gitlab-ci.yml변경 방지- 배포 전 승인 필요
배포 안전성
배포 작업은 특정 종류의 CI/CD 작업입니다. 다른 작업보다 민감할 수 있으며, 추가 주의가 필요할 수 있습니다. GitLab에는 배포 보안과 안정성을 유지하는 데 도움이 되는 여러 기능이 있습니다.
할 수 있습니다.
- 프로젝트에 적절한 역할을 설정할 수 있습니다. GitLab이 지원하는 다른 사용자 역할과 각 권한에 대해서는 프로젝트 구성원 권한을 참조하세요.
- 중요한 환경에 대한 쓰기 액세스 제한
- 배포 동결 창 동안 배포 방지
- 프로덕션 비밀 보호
- 배포용 프로젝트 분리
연속 배포 워크플로를 사용하고 동일한 환경으로 동시에 배포가 발생하지 않도록 하려면 다음 옵션을 활성화해야 합니다.
개요는 CD 파이프라인/워크플로 보안하는 방법을 참조하세요.
중요한 환경에 대한 쓰기 액세스 제한
기본적으로 환경은 최소 Developer 역할을 가진 팀원이 수정할 수 있습니다.
중요한 환경(예: 프로덕션 환경)에 대한 쓰기 액세스를 제한하려면 보호된 환경을 설정할 수 있습니다.
한 번에 한 개의 배포 작업만 실행하도록 보장
GitLab CI/CD의 파이프라인 작업은 병렬로 실행되므로 두 개의 배포 작업이 동시에 동일한 환경으로 배포를 시도할 수 있습니다. 이는 원하는 동작이 아니며, 배포는 순차적으로 발생해야 합니다.
.gitlab-ci.yml에서 resource_group 키워드를 사용하여 한 번에 한 개의 배포 작업만 실행하도록 보장할 수 있습니다.
예:
deploy:
script: deploy-to-prod
resource_group: prod
리소스 그룹을 사용하기 전의 문제가 있는 파이프라인 흐름 예시:
- Pipeline-A의
deploy작업이 실행을 시작합니다. - Pipeline-B의
deploy작업이 실행을 시작합니다. 이는 예상치 못한 결과를 초래할 수 있는 동시 배포입니다. - Pipeline-A의
deploy작업이 완료됩니다. - Pipeline-B의
deploy작업이 완료됩니다.
리소스 그룹을 사용한 후 향상된 파이프라인 흐름 예시:
- Pipeline-A의
deploy작업이 실행을 시작합니다. - Pipeline-B의
deploy작업이 실행을 시작하려고 하지만 첫 번째deploy작업이 완료될 때까지 기다립니다. - Pipeline-A의
deploy작업이 완료됩니다. - Pipeline-B의
deploy작업이 실행을 시작합니다.
자세한 정보는 리소스 그룹 문서를 참조하세요.
오래된 배포 작업 방지
파이프라인 작업의 유효한 실행 순서는 실행마다 다를 수 있으므로 원하지 않는 동작을 초래할 수 있습니다. 예를 들어, 새로운 파이프라인의 배포 작업이 이전 파이프라인의 배포 작업보다 먼저 완료될 수 있습니다. 이는 이전 배포가 더 늦게 끝나 “새로운” 배포를 덮어쓰는 경합 조건을 만들어냅니다.
오래된 배포 작업 방지 기능을 활성화하여 새로운 배포 작업이 시작될 때 이전 배포 작업이 실행되지 않도록 할 수 있습니다.
이전 배포 작업을 시작하는 경우 실행이 실패하며 파이프라인 보기에서 failed outdated deployment job으로 표시됩니다. 완료된 작업을 보는 경우 The deployment job is older than the latest deployment, and therefore failed.라는 메시지가 표시됩니다.
오래된 배포 작업이 수동인 경우, 실행 단추가 사용 중지되고 “이 배포 작업은 자동으로 실행되지 않으며 수동으로 시작해야 하지만, 최신 배포보다 더 오래되어 실행되지 않습니다.”라는 메시지가 표시됩니다.
작업 연령은 커밋 시간이 아니라 작업 시작 시간으로 결정되므로 일부 상황에서 새로운 커밋이 방지될 수 있습니다.
롤백 배포를 위한 작업 재시도
빠르게 안정적인 오래된 배포로 롤백해야 할 수 있습니다. 배포 롤백을 위한 파이프라인 작업 재시도는 기본적으로 활성화되어 있습니다.
파이프라인 재시도를 비활성화하려면 롤백 배포를 위한 작업 재시도 허용 확인란을 선택 해제하십시오. 민감한 프로젝트에서는 파이프라인 재시도를 비활성화해야 합니다.
롤백이 필요한 경우 이전 커밋으로 새로운 파이프라인을 실행해야 합니다.
예제
이전에 Prevent outdated deployment jobs를 활성화하기 전에 문제가 되는 파이프라인 흐름의 예:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 나중에 Pipeline-B가 더 최근 커밋 SHA로 기본 브랜치에 생성됩니다.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포합니다. - Pipeline-A의
deploy작업이 나중에 완료되어 더 오래된 코드를 배포하며, 더 최신(최신) 배포를 덮어씁니다.
Prevent outdated deployment jobs를 활성화한 후에 향상된 파이프라인 흐름의 예:
- Pipeline-A가 기본 브랜치에서 생성됩니다.
- 나중에 Pipeline-B가 더 최근 SHA로 기본 브랜치에 생성됩니다.
- Pipeline-B의
deploy작업이 먼저 완료되어 더 최신 코드를 배포합니다. - Pipeline-A의
deploy작업이 실패하여 더 최신 파이프라인의 배포를 덮어쓰지 않습니다.
배포 동결 기간 동안 배포 방지
특정 기간 동안 배포를 방지하려면 예를 들어 대부분의 직원이 휴가 중인 계획된 휴가 기간 중에, Deploy Freeze를 설정할 수 있습니다. 배포 동결 기간 동안에는 어떠한 배포도 실행할 수 없습니다. 이는 배포가 예상치 못하게 발생하는 것을 방지하는 데 도움이 됩니다.
다음 구성된 배포 동결이 환경 배포 목록 페이지 상단에 표시됩니다.
프로덕션 비밀 정보 보호
프로덕션 비밀 정보는 성공적으로 배포하기 위해 필요합니다. 예를 들어, 클라우드로 배포할 때, 클라우드 제공 업체는 서비스에 연결하기 위해 이러한 비밀 정보가 필요합니다. 프로젝트 설정에서 이러한 비밀 정보에 대한 CI/CD 변수를 정의하고 보호할 수 있습니다. 보호된 변수는 보호된 브랜치 또는 보호된 태그에서 실행 중인 파이프라인에만 전달됩니다. 다른 파이프라인은 보호된 변수를 받지 않습니다. 또한 특정 환경에 변수 적용할 수도 있습니다. 우리는 보호된 환경에서 보호된 변수를 사용하여 비밀 정보가 의도치 않게 노출되지 않도록 하는 것이 좋다고 권장합니다. 또한 프로덕션 비밀 정보를 런너 측면에서 정의할 수 있습니다. 이렇게 함으로써 Maintainer 역할을 가진 다른 사용자가 비밀 정보를 읽지 못하도록 하고 런너가 보호된 브랜치에서만 실행되도록 할 수 있습니다.
자세한 정보는 파이프라인 보안을 참조하십시오.
배포용 별도 프로젝트
프로젝트의 Maintainer 역할을 가진 모든 사용자는 프로덕션 비밀 정보에 액세스할 수 있습니다. 프로덕션 환경으로의 배포를 제한해야 하는 경우 별도의 프로젝트를 만들고 기존 프로젝트와는 CD 권한을 격리하는 새로운권한 모델을 구성할 수 있습니다. 또한 기존 프로젝트의 Maintainer 역할을 가진 사용자가 프로덕션 비밀 정보 및 CD 구성에 액세스하지 못하도록 할 수 있습니다. 다중 프로젝트 파이프라인을 사용하여 CD 프로젝트를 개발 프로젝트에 연결할 수 있습니다.
.gitlab-ci.yml 변경 방지
.gitlab-ci.yml에는 애플리케이션을 프로덕션 서버에 배포하기 위한 규칙이 포함될 수 있습니다. 이 배포는 일반적으로 병합 요청을 푸시한 후에 자동으로 실행됩니다. 개발자가 .gitlab-ci.yml을 변경하지 못하게 하려면 이를 다른 저장소에 정의할 수 있습니다. 설정에서 다른 프로젝트의 파일을 참조할 수 있으며, 이 프로젝트는 완전히 다른 권한 조합을 가진 파일을 참조할 수 있습니다(디플로이용 프로젝트를 분리하는 것과 유사).
이 시나리오에서 .gitlab-ci.yml은 공개적으로 액세스할 수 있지만 다른 프로젝트에서 적절한 권한을 가진 사용자만이 해당 파일을 편집할 수 있습니다.
자세한 정보는 사용자 정의 CI/CD 구성 경로를 참조하십시오.
배포 전 승인 필요
프로덕션 환경으로의 배포를 승인하기 전에 전문 테스트 그룹을 사용하여 교차 확인하는 것은 안전을 보장할 수 있는 효과적인 방법입니다. 자세한 정보는 배포 승인을 참조하십시오.
도움말