This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
ongoing	`@Andysoiron` `@g.hickman`	`@fabiopitino`	`@g.hickman`	devops govern	2023-11-23

파이프라인 실행 정책

이 문서는 진행 중인 작업으로, 사용자가 프로젝트 파이프라인의 일부로 CI 작업을 강제로 실행하고 보안 정책 및 규정 프레임워크를 사용하여 해당 작업을 프로젝트에 링크/범위 설정할 수 있는 시각의 현재 상태를 대변합니다.

요약

사용자들은 프로젝트 파이프라인의 일부로 작업을 실행할 수 있는 단일 솔루션이 필요합니다. 규정 프레임워크 파이프라인의 유연성과 스캔 실행 정책의 간편함을 결합하는 방법이 필요합니다.

파이프라인 실행 정책을 사용하여 정책 규칙을 정의하는 많은 경우가 있지만, 여기에는 지금까지 들어온 가장 흔한 몇 가지가 있습니다:

include 문을 사용하여 CI 템플릿을 포함하고 .latest 보안 스캐너 템플릿과 같은 템플릿을 끌어들일 수 있는 방법이 필요합니다. CI 템플릿을 참조하세요.
서드파티 스캐너를 실행하여 추가 보안 결과를 캡처하고 GitLab 스캐너에서 보고된 결과와 함께 관리할 수 있도록 실행을 강제하고 싶습니다.
커스텀 스크립트/규정을 강제하고 싶습니다.
GitLab에 저장된 코드를 분석하기 위해 스캐너를 실행하고, 동시에 파이프라인을 계속하는 서드파티 CI 도구를 호출하기를 원합니다. 여기서 일반적인 경우로는 GitLab로 이전 중인 사용자지만, 해당 팀 중 일부는 여전히 서드파티 CI 도구를 사용할 수 있습니다.
스캐너에서 결과를 서드파티 도구로 내보내고 싶습니다.
외부 도구에서 UAT가 완료될 때까지 MR을 차단하고자 하여(품질 게이트), 제품 코드의 변경 사항의 품질을 보증할 수 있도록 하고 싶습니다.
프로젝트내 사용자에게 보안 정책이 활성화되어 있는지, 파이프라인이 특정 스캔 결과에 의해 차단되었는지 빠르게 알릴 수 있는 커스텀 프로젝트 뱃지를 표준화하고자 합니다.
팀 구성원이 항상 높은 점수를 유지하도록 장려하기 위해 프로젝트에서 커스텀 뱃지를 만들어 보안 등급을 전달하고자 합니다.

동기

목표

규정 프레임워크를 적절하게 대체하고, 16.9에서는 규정 프레임워크의 사용을 폐기하고 17.0에서 삭제할 계획입니다.
기존의 규정 프레임워크의 문제점 및 고객의 스캔 실행을 권장하는 기술적 특이점을 해결하고 강화하는 방법을 위한 아키텍처를 설정하고자 합니다.

알려진 규정 프레임워크의 문제점은 다음과 같습니다:

제안

현재, 보안 정책은 여러 스캔 작업을 포함할 수 있습니다. 각 스캔 작업은 프로젝트 CI 파이프라인에 주입될 CI 작업 결과를 가져올 것입니다. 새로운 기능은 사용자가 프로젝트 CI 파이프라인에 주입되는 사용자 정의 CI 작업을 정의할 수 있게 합니다. 보안 정책 접근법을 사용하여 규정 프레임워크가 필요한 유연성과 동일한 유연성을 제공하고자 합니다. 이 두 가지 기능의 결합은 보안 정책이 규정 프레임워크에 범위를 지정하고 사용자 정의 CI 작업의 존재를 강제할 수 있도록 합니다.

스캔 실행 정책과 마찬가지로, 사용자 정의 CI 작업은 특정 브랜치 이름, 브랜치 유형 또는 프로젝트에 적용된 규정 프레임워크에 범위를 지정할 수 있습니다. 사용자는 사전 정의된 보안 정책 스테이지 중 하나를 활용하여 작업을 파이프라인에 위치시킴으로써 자신의 요구에 따라 작업을 설정할 수 있습니다. 규정 파이프라인에서 새 기능으로 전환하는 것은 가능한 한 원활하게 이루어져야 합니다.

디자인 및 구현 세부 정보

파이프라인 실행 정책 MVC

파이프라인 실행 정책 MVC는 규정 파이프라인으로 부터의 전환이 가능하게 해야 합니다.

보안 정책에 사용자 정의 CI YAML을 추가할 수 있어야 합니다. CI YAML은 .gitlab-ci.yml 파일과 동일한 스키마를 따라야 합니다. 사용자 정의 CI는 파이프라인이 시작될 때 프로젝트 CI와 Merge됩니다.
보안 정책 스키마는 프로젝트 및 파일 경로를 추가할 수 있도록 함으로써 사용자 정의 CI를 외부 파일에 정의할 수 있도록 합니다.
스캔 실행 정책은 기존 정책과 유사하게 사용자 정의 CI YAML을 실행하고, 해당 작업을 대상 프로젝트의 GitLab CI YAML에 주입합니다.
최소한 스테이지 파이프라인 실행 정책 작업은 기존의 CI 변수 우선 순위와 일치해야 합니다. 이상적으로, 스캔 실행 작업 변수는 프로젝트, 그룹 및 인스턴스 변수와 같은 프로젝트의 다른 CI 변수 보다 더 높은 우선 순위로 실행되어야 합니다. 특히, 스캔 실행 작업 변수는 project, group 및 instance 변수와 같은 규정 프레임워크 프로젝트 변수 등을 덮어써야 합니다.
작업은 파이프라인 내에서 사용자에게 보이는 방식으로 실행되어야 하며, 프로젝트 작업이 SEP(Scan Execution Policy) 작업을 덮어쓰는 것을 허용하지 않아야 합니다. 현재 스캔 실행 정책에서는 동일한 이름의 작업이 존재한다면 해당 작업 이름에 색인 패턴(-0, -1, -2,…)을 사용하여 증가시키는 방식을 이용합니다. 이는 또한 어떤 작업이 보안 정책에 의해 실행되는 것임을 약간 알 수 있게 합니다. 사용자 정의 YAML 작업에서도 동일한 패턴을 사용해야 합니다.
사용자는 작업이 실행될 스테이지를 정의할 수 있어야 하며, 스캔 실행 정책은 우선 순위를 처리하는 방법을 가져야 합니다. 예를 들어, 보안/규정 팀은 빌드 이후에 일반적으로 실행되는 작업을 강제로 실행하고자 할 수 있습니다. build_after(예시)를 사용하여 빌드 스테이지 이후에 build_after 스테이지를 주입하고, 해당 스테이지 내부에 정의된 파이프라인 실행 정책의 사용자 정의 CI YAML을 강제로 실행할 수 있게 되어야 합니다. 스테이지와 작업은 스캔 실행 정책에 의해 강제된 이후에 개발 팀에서는 간섭할 수 없어야 합니다. 강제된 프로젝트 CI에 프로젝트가 크게 침범당하지 않도록 하는 규칙을 정의해야 합니다.
파이프라인 실행 정책은 기존 CI 설정이 없는 프로젝트에서도 사용자 정의 CI YAML을 실행해야 합니다. 현재 스캔 실행 정책이 작동하는 방식과 동일하게 요구됩니다.

스테이지 관리 전략

프로젝트 파이프라인의 CI 스테이지 전 또는 후에 작업을 실행할 수 있도록 사용자가 작업을 배치할 수 있기를 원합니다. 이를 위해 파이프라인 실행 정책에서만 사용할 수 있는 3가지 예약된 스테이지를 도입하고 프로젝트 파이프라인에 주입할 계획입니다:

.pipeline-policy-pre 스테이지는 파이프라인 매우 처음에 실행되며 .pre 스테이지 전에 실행됩니다.
.pipeline-policy 스테이지는 test 스테이지 이후에 주입됩니다. test 스테이지가 없는 경우 build 스테이지 이후에 주입됩니다. build 스테이지도 없는 경우 파이프라인 맨 처음에 .pre 스테이지 다음에 주입됩니다.
.pipeline-policy-post 스테이지는 파이프라인 매우 마지막에 실행되며 .post 스테이지 이후에 실행됩니다.

이 3개의 스테이지 중 어느 것이든 작업을 주입하는 것이 항상 보장됩니다. 실행 정책 작업은 프로젝트 파이프라인에 존재하는 어떤 스테이지에도 할당할 수 있습니다. 그러나 이 경우에는 프로젝트 파이프라인에서 해당 스테이지를 선언했는지 여부에 따라 주입이 항상 작동하는 것이 보장되지는 않습니다. 파이프라인 실행 정책에서 사용자 정의 스테이지를 만드는 것은 불가능할 것입니다.

우리는 실험 단계의 일부로 이 접근 방식을 시도해 볼 것입니다. 또한 시도해 볼 수 있는 다음 전략을 논의했습니다:

1. 보안 정책 스테이지 순서 우선 적용

파이프라인 실행 정책은 stages 키워드를 사용하여 스테이지를 재정의하여 스테이지 순서를 변경할 수 있습니다. 파이프라인 실행 정책에 정의된 스테이지의 순서가 프로젝트 CI에 정의된 순서보다 우선될 것입니다.

파이프라인 실행 정책에서 test 스테이지 이후에 작업을 주입하려면 스테이지를 다음과 같이 재정의할 수 있습니다:

stages:
  - test
  - policy_after_test

이 솔루션은 사용자에게 사용자 정의 스테이지를 정의할 수 있는 유연성을 제공합니다. 그러나 스테이지의 순서에 대한 단일 정보원이 더는 없을 것입니다. 프로젝트 CI가 파이프라인 실행 정책에 정의되지 않은 사용자 정의 스테이지를 정의하는 경우, 해당 스테이지가 파이프라인 실행 정책 스테이지 이전 또는 이후에 실행되어야 하는지 알 수 없습니다.

2. `pre` 및 `post` 키워드 도입

보안 정책은 pre_[stage_name] 및 post_[stage_name] 스테이지를 사용하여 특정 스테이지 이전 또는 이후에 작업을 주입할 수 있습니다. 예를 들어, pre_test는 test 스테이지 이전에 실행됩니다. 이 방법으로 보안 정책은 프로젝트 CI를 방해하지 않을 것으로 예상됩니다. 그러나 단점은 정책 작성자가 프로젝트에서 사용하는 스테이지를 알고 있어야 하고 정책 스테이지가 test 스테이지를 예를 들어 test_2로 이름을 바꾸어 건너뛸 수 있다는 것입니다.

3. 고급 스테이지 규칙 도입

파이프라인 실행 정책 스테이지에 대한 고급 API를 도입하여 다른 스테이지의 존재에 따라 스테이지를 주입할 수 있는 기능을 제공합니다. 스키마 예시:

compliance_stages:
- stage_name: qa
  after:
  - release
  if:
  - stage_exist: deploy

이는 유연성을 제공하고 사용자가 다른 프로젝트 CI 스테이지 설정에 대한 동작을 정의할 수 있게 합니다.

4. 모든 작업을 기본 스테이지에서 실행

파이프라인 실행 정책에 정의된 작업은 pipeline-policy 스테이지에서 실행될 것입니다. 이 스테이지는 test 스테이지 이후에 주입될 것입니다. test 스테이지가 존재하지 않는 경우 build 스테이지 이후에 주입될 것입니다. build 스테이지도 존재하지 않는 경우 파이프라인 처음에 주입될 것입니다.

링크

파이프라인 실행 정책 MVC epic

파이프라인 실행 정책

요약

동기

목표

제안

디자인 및 구현 세부 정보

파이프라인 실행 정책 MVC

스테이지 관리 전략

1. 보안 정책 스테이지 순서 우선 적용

2. pre 및 post 키워드 도입

3. 고급 스테이지 규칙 도입

4. 모든 작업을 기본 스테이지에서 실행

링크

2. `pre` 및 `post` 키워드 도입