GitLab 컴플라이언스 파이프라인은 해당 프로젝트의 보안과 컴플라이언스 관련 job이 컴플라이언스 프레임워크에 따라 실행되도록 합니다. 마찬가지로 스캔 실행 정책은 GitLab 보안 스캔이 규정을 준수하는 방식으로 파이프라인에서 실행되도록 보장합니다.
GitLab이 사용자에게 배운 것은 ‘사용자가 각 기능이 제공하는 이점을 하나의 간단한 솔루션으로 활용하고 싶어 한다’는 것입니다. 사용자는 컴플라이언스 파이프라인의 유연성과 보안 정책의 단순성, 다양성을 결합하길 원합니다.
GitLab은 이러한 요구사항을 충족하고자 새로운 기능인 ‘파이프라인 실행 정책’을 개발해 사용자가 적용 가능한 모든 프로젝트에 맞춤형 CI/CD job을 시행하도록 지원했습니다. 파이프라인 실행 정책은 컴플라이언스 파이프라인과 비슷한 기능을 수행하지만 컴플라이언스 시행, 유연성, 향후 더 많은 사용 사례를 구축하고 해결하는 기반에 더 중점을 둡니다.
이제 파이프라인 실행 정책을 사용할 수 있게 되면서, 혼란을 줄이기 위해 컴플라이언스 파이프라인을 GitLab 17.3에서 더 이상 사용하지 않습니다. 사용 중단의 일환으로 GitLab 17.5에서는 컴플라이언스 파이프라인에서 파이프라 인 실행 정책 유형으로 마이그레이션 하는 단계별 워크플로를 제공합니다.
이 에픽에서 사용 중단과 관련된 작업을 따라갈 수 있습니다.
컴플라이언스 파이프라인을 사용하지 않는 이유
이러한 변경의 이유를 이해하려면, 먼저 GitLab의 컴플라이언스 관리와 정책 관리 기능의 차이점을 이해해야 합니다. GitLab은 컴플라이언스 관리로 컴플라이언스 상태를 이해하도록 돕고, 감사자에게 보고하는 도구를 제공하며, 사용자가 조치를 취하는 데 도움이 되는 방식으로 컴플라이언스 위험을 드러내는 데 중점을 둡니다.
아울러 GitLab은 전체 DevSecOps 라이프사이클 동안 프레임워크 요구 사항, 위반, 감사 이벤트의 컴플 라이언스 가시성을 높이는 데 주력합니다. 또 GitLab의 컴플라이언스 관리 서비스는 정책으로 구성된 제어와 자동화를 컴플라이언스 프레임워크로 설정된 컴플라이언스 요구사항에 직접 연결합니다.
정책 관리는 컴플라이언스 프로그램과 함께 작동하며, 확장 가능한 보안 이니셔티브를 지원합니다. 정책은 조직에 보안 제어, 컴플라이언스 제어를 전 세계적으로 시행하고 보안과 컴플라이언스 워크플로를 자동화하는 중앙 위치를 제공합니다. 보안 정책은 CI/CD 컴포넌트 사용의 시행 정의, 의존성, 패키지 관리와 관련된 위험 차단, 보안과 컴플라이언스 제어를 다루는 취약점 관리 워크플로 자동화와 같은 라이프사이클 전반의 핵심 사용 사례를 지속적으로 처리할 예정입니다.
따라서 GitLab은 보안과 컴플라이언스 사용자에게 최고의 가치를 제공하기 위해 컴플라이언스 파이프라인을 더 이상 사용하지 않고, 사용자에게 보안 정책으로 마이그레이션 경로를 제공합니다. 이로써 사용자는 프로젝트 파이프라인 일부로 ‘job 시행 방법과 시기’를 명확하고 간단하게 알 수 있고, GitLab에서 컴플라이언스 관리와 정책 관리를 더 명확하게 구분할 수 있습니다. 컴플라이언스 관리는 컴플라이언스 가시성에 초점을 두고, 정책 관리는 전체 GitLab 인스턴스에서 컴플라이언스와 보안 시행에 중점을 둡니다.
컴플라이언스 파이프라인 사용 중단, 제거 일정
아래 이터래이션 계획은 컴플라이언스 파이프라인을 사용 중단하고 제거하기 위해 GitLab이 수행 중인 작업을 자세히 다룬 이슈에서 찾을 수 있습니다.
- 컴플라이언스 파이프라인 사용 중단, 제거는 GitLab 17.3에서 발표됐습니다.
- 배너와 마이그레이션 워크플로, 문서 추가
- GitLab 17.5에 릴리즈
- 새 파이프라인에 경고 배너 추가
- 사용자가 대신 파이프라인 실행 정책을 시도하도록 권장
- GitLab 17.6에서 작업 시작 예정
- GitLab 17.8 릴리즈 예정
- 제거를 시도하고 오류를 검증하는 도구 제공
- GitLab 17.8에서 작업 시작 예정
- GitLab 18.0 릴리즈 예정
보다시피 GitLab 17.3 릴리즈에서는 컴플라이언스 파이프라인의 사용 중단과 파이프라인 실행 정책의 도입을 시작합니다.
GitLab 18.0 릴리즈에서 컴플라이언스 파이프라인을 제거하기 전에, GitLab은 사용자에게 ‘기능을 곧 제거할 예정임’을 새로운 방식으로 알리고 경고합니다. GitLab은 새로운 파이프라인의 경고 배너와 컴플라이언스 파이프라인을 파이프라인 실행 정책에 마이그레이션 하는 데 사용하는 워크플로를 제공합니다.
GitLab 18.0 릴리즈에서 컴플라이언스 파이프라인을 제거하지만, 제거일 이전에 사용자가 제거를 테스트하고 영향을 이해하도록 돕는 마일스톤에 reverse 피처 플래그를 제공할 예정입니다.
컴플라이언스 파이프라인→파이프라인 실행 정책 마이그레이션 방법
사용자가 컴플라이언스 파이프라인을 파이프라인 실행 정책에 마이그레이션 하는 워크플로에 액세스하는 방법은 두 가지입니다.
-
새 컴플라이언스 프레임워크를 만들 때, 이제 사용자가 컴플라이언스 프레임워크 대신 파이프라인 실행 정책 유형을 사용하도록 안내하는 경고 배너가 표시됩니다.
새 컴플라이언스 프레임워크 생성 페이지에 뜬 ‘컴플라이언스 파이프라인 사용 중단’ 메시지. 출처=GitLab
-
기존 컴플라이언스 프레임워크를 편집할 때, 사용자가 컴플라이언스 파이프라인을 파이프라인 실행 정책 유형에 마이그레이션 하도록 안내하는 경고 배너가 표시됩니다(컴플라이언스 파이프라인이 구성될 때).
컴플라이언스 프레임워크 편집 페이지에 뜬 ‘컴플라이언스 파이프라인 사용 중단’ 메시지. 출처=GitLab
두 워크플로에서 “Create policy” 또는 “Migrate pipeline to a policy”를 선택하면, “Security Policies” 섹션의 “New policy” 생성 페이지로 이동합니다. 여기서 사용자는 컴플라이언스 파이프라인 대신 새로운 보안 정책을 만들 수 있습니다. 또는 기존 컴플라이언스 파이프라인을 마이그레이션 할 때, 새 정책이 정책의 원격 소스인 컴플라이언스 파이프라인 YAML로 채워집니다. 또 정책 범위가 마이그레이션 하는 프레임워크로 채워집니다.
정책은 해당 레이블이 있는 모든 프로젝트를 시행 대상으로 지정하고 원격 파일(이제 파이프라인 실행 YAML)에 정의된 job의 시행을 적용합니다. 기본적으로 새 정책은 “override” 모드로 구성되며, 이는 다운스트림 프로젝트의 .gitlab-ci.yml을 사용자가 정의한 구성으로 override 합니다(컴플라이언스 파이프라인과 유사).
또는 “Inject” 모드를 사용할 수 있는데, 이는 프로젝트 파이프라인을 중단하지 않고, 파이프라인 구성에서 stage 이름을 정의하기 위해 프로젝트팀과 협력하지 않고도 변조 방지 방식으로 보안과 컴플라이언스 job을 격리해 실행하는 새로운 예약 stage 세트를 도입합니다.
이 접근 방식을 사용하면, 이 모드에 더 이상 필요하지 않은 include:project를 제거해야 합니다. 아울러 버전에 따라, job 이름이 고유한지 확인합니다(GitLab 17.2와 17.3에 필수). GitLab 17.4에서는 유연성을 높이기 위해 충돌을 관리하는 추가 개선 사항을 도입했습니다.
지금 마이그레이션 시작하기
GitLab은 컴플라이언스 파이프라인을 사용하는 모든 사용자가 GitLab 17.3에서 컴플라이언스 파이프라인의 사용 중단 사실과 18.0 릴리즈에서 해당 기능의 최종 제거 계획을 완전히 인지하도록 하고자 합니다.
GitLab 18.0에서 컴플라이언스 파이프라인이 제거되기 전에, 가능한 한 빨리 컴플라이언스 파이프라인을 파이프라인 실행 정책 유형에 마이그레이션 하도록 사용자에게 요청합니다.
궁금한 점이 있으면, 고객 서비스 담 당자 또는 인포그랩 또는 GitLab 지원팀에 문의해 도움을 받으세요.
(이 포스트는 GitLab의 동의를 받아 공식 블로그의 영문 포스트를 우리말로 번역한 글입니다.)
지금 이 기술이 더 궁금하세요? 인포그랩의 DevOps 전문가가 알려드립니다.