GitLab 접근 제어 및 정책 (Access Policy)¶
GitLab Project 의 접근 권한, 멤버 권한, CI/CD 접근 통제 기준을 정의함.
브랜치 전략, Protected Branch, Merge Request(MR), Default Branch, Force Push, hotfix 및 rollback 기준은 브랜치/MR 정책 기준을 따름.
1. 개요¶
본 정책은 다음을 보장하기 위해 정의됨:
- Project 접근 통제
- 권한 오남용 방지
- CI/CD 안정성 확보
- 브랜치 운영 정책 준수
- Release Storage / Polling Deploy 구조의 접근 통제
2. 브랜치/MR 정책 기준¶
다음 항목은 GitLab 브랜치 전략 및 운영 정책의 각 섹션을 기준으로 관리함:
- 16-브랜치 구조 및 흐름
- 16-브랜치 보호 정책
- 16-Merge Request 정책
- 16-Force Push 정책
- 16-금지 사항
- 16-Default Branch 정책
- 16-긴급 대응 및 Hotfix 기준
- 16-Rollback 기준
본 문서에서는 위 항목의 상세 설정값을 중복 정의하지 않음.
3. CI/CD 접근 통제¶
CI/CD는 반드시 통제된 브랜치와 pipeline rules 기준으로만 실행되도록 구성함.
Runner 상세 구성 및 등록 절차는 이후 20-GitLab Runner 구성 및 분리 정책에서 수행함.
3.1 Runner 실행 제한¶
- Runner는 tag 및 pipeline rules 를 통해 실행 범위를 제한함
- release publish job 은 release target branch 에서만 실행되도록 구성함
- release target branch 여부는
.ops/ci/release-branch-versions/{branch}.yaml존재 여부를 기준으로 판단함 develop및feature/*브랜치에서는 release publish job 을 실행하지 않음- MR pipeline 은 branch 승격 경로 검증만 수행하고 release publish job 을 실행하지 않음
3.2 환경 분리¶
환경 분리는 고정 브랜치 목록이 아니라 release target branch 기준으로 관리함.
| 구분 | 기준 |
|---|---|
| 개발 기준 브랜치 | develop |
| 기능 개발 브랜치 | feature/* |
| release target branch | .ops/ci/release-branch-versions/{branch}.yaml 이 존재하는 브랜치 |
| pre-production 예시 | pre-production |
| production 예시 | production |
운영 기준:
pre-production,production은 release target branch 의 대표 예시임- release target branch 는 필요한 환경에 따라 추가할 수 있음
- release target branch 추가 여부는 브랜치명 하드코딩이 아니라 release branch yaml 존재 여부로 판단함
3.3 운영 기준¶
- GitLab CI/CD 는 package build, package publish, release metadata publish 까지만 수행함
- GitLab CI/CD 가 운영 서버에 직접 접속하여 deploy 하지 않음
- 실제 deploy 는 운영 서버의 Polling Deploy 가 Release Storage 의 desired release state 를 감지하여 수행함
- production 관련 CI/CD variable 은 protected 상태로 관리함
- Release Storage 접근 credential 은 masked/protected variable 로 관리함
- 운영 서버 전용
.env파일은 GitLab 저장소 및 CI/CD variable 에 저장하지 않음
4. 접근 제어 정책¶
4.1 Project 접근¶
- 모든 Project 는 Private 으로 운영함
- 접근은 초대 기반으로만 허용함
- Project 는
PROJECT_NAME / SERVICE_PREFIX / SERVICE_NAME구조 기준으로 생성함 - 권한 관리 Group 과 서비스 Project Group 은 분리하여 운영함
4.2 권한 제한¶
- Project 멤버 권한은 업무에 필요한 최소 권한으로 부여함
- 일반 개발자는 권한 관리 Subgroup 을 통해
Developer이하 권한으로 접근함 - Project 운영 책임자만 개별
Maintainer로 지정함 - Owner 권한은 최소 인원으로 유지함
브랜치별 push/merge 가능 범위는 16-GitLab 브랜치 보호 정책을 따름.
4.3 외부 사용자¶
- 외부 사용자는
Reporter또는Developer로 제한함 - 외부 사용자에게
Maintainer/Owner권한 부여 금지 - 외부 사용자 접근은 기간과 목적을 명확히 기록함
- 작업 완료 후 외부 사용자 접근 권한을 회수함
5. 예외 정책 (긴급 대응)¶
5.1 원칙¶
- 긴급 상황에서도 권한 변경은 최소 범위와 기간으로 제한함
- 브랜치 보호 및 MR 우회 예외는 16-GitLab 브랜치 금지 사항을 따름
- hotfix 및 rollback 흐름은 16-긴급 대응 및 Hotfix 기준과 16-Rollback 기준을 따름
- 임시 권한 상승은 최소화하고 작업 완료 후 즉시 회수함
5.2 예외 상황¶
- 서비스 장애 발생 시
- 긴급 수정 필요 시
- CI/CD 접근 권한 조정이 필요한 경우
- Release Storage 접근 권한 조정이 필요한 경우
- 운영 서버 Polling Deploy 장애로 수동 확인이 필요한 경우
6. 금지 사항¶
- Project Public/Internal 전환 금지
- 승인 없는
Maintainer/Owner권한 부여 금지 - 외부 사용자에게
Maintainer/Owner권한 부여 금지 - production 환경 변수 무단 변경 금지
- Release Storage credential 무단 변경 금지
- CI/CD 설정 무단 변경 금지
- 운영 서버 전용
.env파일 commit 금지 - GitLab CI/CD 에서 운영 서버로 직접 deploy 하는 구조 금지
- MR 우회 금지 기준은 16-GitLab 브랜치 금지 사항을 따름
7. 결론¶
본 정책을 통해 다음을 확보함:
- 접근 통제 기반 운영
- 권한 오남용 방지
- 안정적인 CI/CD 환경
- 브랜치 운영 정책과 접근 정책의 분리 관리
- Release Storage / Polling Deploy 구조의 접근 통제