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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality 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 작업을 강제 실행하고 보안 정책 및 컴플라이언스 프레임워크를 사용하여 해당 작업을 프로젝트에 링크/범위 설정할 수 있는 비전의 현재 상태를 대표합니다.

요약

사용자들은 프로젝트 파이프라인의 일부로 작업을 강제 실행시키기 위한 단일 솔루션이 필요합니다. 컴플라이언스 프레임워크 파이프라인의 유연성과 스캔 실행 정책의 간편함을 결합하는 방법이 필요합니다.

파이프라인 실행 정책을 사용하여 정책 규칙을 정의하는 데 사용될 수 있는 많은 경우가 있지만, 지금까지 가장 흔한 몇 가지는 다음과 같습니다:

  1. include 문을 사용하여 CI 템플릿을 포함하고 .latest 보안 스캐너 템플릿과 같은 템플릿을 풀 수 있도록 하려고 합니다. CI 템플릿을 참조하세요.
  2. 3rd party 스캐너의 실행을 강제하여 GitLab 스캐너의 결과와 함께 추가 보안 결과를 포착하고 관리하려 합니다.
  3. 컴플라이언스를 위해 사용자 정의 스크립트/검사를 강제하려고 합니다.
  4. GitLab에 저장된 코드를 분석하기 위해 스캐너를 강제로 실행시키고, 그러나 파이프라인을 계속하기 위해 3rd party CI 도구를 호출하려고 합니다. 이곳에서의 일반적인 사례는 사용자가 GitLab로 이관 중이지만 어떤 팀들은 여전히 일시적으로 3rd party CI 도구를 사용할 수 있는 상황입니다.
  5. 스캐너에서 결과를 3rd party 도구로 내보내려고 합니다.
  6. UAT(사용자 수용 테스트)가 완료될 때까지 MR(Merge Request)을 차단하고(품질 게이트) 프로덕션 코드의 변경 사항의 품질을 보장할 수 있도록 하려고 합니다.
  7. 프로젝트에 사용자 지정 보안 정책이 활성화되었는지, 파이프라인이 특정 스캔 결과에 의해 차단되었는지 빠르게 사용자에게 전달할 수 있는 사용자 정의 프로젝트 뱃지를 표준화하려고 합니다. 이를 통해 보안 팀 및 개발 팀이 프로젝트의 보안 상태를 쉽게 이해할 수 있습니다.
  8. 팀 멤버들이 점수를 높이도록 동기부여되도록 프로젝트에서 보안 등급을 전달하기 위해 사용자 정의 뱃지를 만들려고 합니다.

동기

목표

  1. 16.9에서 컴플라이언스 파이프라인을 사용 중단하고 17.0에서 완전히 삭제할 목적으로 컴플라이언스 파이프라인의 적절한 대체품을 제공합니다.
  2. 기능을 향상하여 알려진 컴플라이언스 파이프라인 문제들과 조직 전반에 걸친 스캔 실행을 강제하는 데 필요한 고객 고통점을 해결할 수 있도록 아키텍처를 설정합니다.

알려진 컴플라이언스 파이프라인 문제점은 다음과 같습니다:

  • 외부 구성 파일이나 구성 파일 없는 프로젝트를 지원할 수 없음
  • 컴플라이언스 구성 내의 CI 변수를 덮어쓸 수 있음
  • 타깃 저장소에 의해 컴플라이언스 작업을 덮어쓸 수 있음
  • 최상위 전역 키워드와의 충돌(예: 단계)
  • 컴플라이언스 작업이 항상 실행되도록 보장해야 함
  • 수동으로 파이프라인을 시작할 때 미리 채워진 변수가 표시되지 않음
  • 스캔 실행 정책과 컴플라이언스 프레임워크를 통합해야 함
  • 컴플라이언스 프레임워크를 찾을 수 없거나 액세스를 거부함
  • 특정 상황에서 컴플라이언스 파이프라인 작업이 GitLab이 프로젝트의 파이프라인 구성만 확인하도록 하기 때문에 실행되지 않음
  • 빈 파이프라인에서 .pre/.post 작업이 선택적으로 허용되어야 함
  • include 파일에서 설정된 값들을 컴플라이언스 파이프라인에서 일정하게 유지할 수 있어야 함
  • CF-labeled 프로젝트의 fork에서 시작된 MR에서 컴플라이언스 프레임워크 파이프라인 실행
  • 병합된 YAML에 노출되지 않은 컴플라이언스 파이프라인 구성

제안

현재 보안 정책에는 여러 스캔 작업이 포함될 수 있습니다. 각 스캔 작업은 프로젝트 CI 파이프라인에 주입될 CI 작업을 실행합니다. 새로운 기능을 통해 프로젝트 CI 파이프라인에 주입될 사용자 정의 CI 작업을 정의할 수 있습니다. 저희는 컴플라이언스 프레임워크가 필요로 하는 같은 유연성을 제공하기 위해 보안 정책 접근법을 일반화하고자 합니다. 두 가지 기능의 결합은 보안 정책을 컴플라이언스 프레임워크에 적용하여 사용자 정의 CI 작업의 존재를 강제화할 수 있게 만듭니다.

스캔 실행 정책과 마찬가지로 사용자 정의 CI 작업은 특정 브랜치 이름, 브랜치 유형 또는 프로젝트에 적용된 컴플라이언스 프레임워크에 적용될 수 있습니다. 사용자는 사전 정의된 보안 정책 스테이지 중 하나를 활용하여 파이프라인에서 작업을 필요에 따라 위치시킬 수 있습니다. 컴플라이언스 파이프라인에서 새로운 기능으로의 전환은 최대한 부드럽게 이루어져야 합니다.

디자인 및 구현 세부 정보

파이프라인 실행 정책 MVC

파이프라인 실행 정책 MVC를 통해 컴플라이언스 파이프라인으로의 전환을 허용할 것입니다.

  • 보안 정책에 사용자 정의 CI YAML을 추가하는 것이 가능해야 합니다. CI YAML은 .gitlab-ci.yml 파일과 동일한 스키마를 따라야 합니다. 파이프라인이 시작되면 사용자 정의 CI가 프로젝트 CI와 병합될 것입니다.
  • 보안 정책 스키마는 프로젝트 및 파일 경로를 추가할 수 있도록 하여 외부 파일에 사용자 정의 CI를 정의할 수 있어야 합니다.
  • 스캔 실행 정책은 기존 정책과 유사하게 사용자 정의 CI YAML을 실행해야 하며, 해당 작업을 대상 프로젝트의 GitLab CI YAML에 주입해야 합니다.
  • 최소한 파이프라인 실행 정책 작업은 기존 CI 변수 우선순위에 맞추어야 합니다. 이상적으로, 스캔 실행 정책 작업에서 정의된 모든 CI 변수는 최우선순위로 실행되어야 합니다. 특히, 스캔 실행 작업 변수는 프로젝트, 그룹 및 인스턴스 변수, 컴플라이언스 프로젝트 변수 등을 우선합니다.
  • 작업은 스캔 실행 정책에서 사용자에게 가시적이며, 프로젝트 작업이 SEP(스캔 실행 정책) 작업을 덮어쓰지 못하도록 해야 합니다. 현재 스캔 실행 정책에서는 동일한 이름의 작업이 이미 존재할 경우 이름에 인덱스 패턴(-0, -1, -2,…)을 사용하여 작업의 이름을 증가시킵니다. 이는 또한 보안 정책으로 실행되는 작업을 약간 나타냅니다. 사용자 정의 YAML 작업의 경우에도 동일한 패턴을 활용해야 합니다.
  • 사용자는 작업이 실행될 스테이지를 정의할 수 있어야 하며, 스캔 실행 정책에는 우선 순위를 처리할 수 있는 방법이 있어야 합니다. 예를 들어, 보안/컴플라이언스 팀은 빌드 후에 일반적으로 실행되는 작업을 강제화하고자 할 수 있습니다. 빌드 후(예: build_after)를 사용하여 스캔 실행 정책이 빌드 후 스테이지에 주입하고 이 스테이지에서 정의된 파이프라인 실행 정책 내의 사용자 정의 CI YAML을 강제화할 수 있어야 합니다. 스테이지 및 작업은 스캔 실행 정책에 의해 강제화된 후 개발 팀에 의해 간섭 받지 않아야 합니다. 모든 강제화된 프로젝트에 깔끔하게 스테이지를 주입할 수 있는 규칙을 정의해야 하지만 프로젝트 CI에는 최소한의 침투를 허용해야 합니다.
  • 파이프라인 실행 정책은 기존 CI 구성이 없는 프로젝트에서도 사용자 정의 CI YAML을 실행해야 합니다. 이는 현재 표준 스캔 실행 정책이 작동하는 방식과 동일합니다.

스테이지 관리 전략

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

  1. .pipeline-policy-pre 스테이지는 .pre 스테이지 앞에서 파이프라인의 맨 처음에 실행될 것입니다.
  2. .pipeline-policy 스테이지는 test 스테이지 뒤에 주입될 것입니다. test 스테이지가 존재하지 않는 경우 build 스테이지 뒤에 주입될 것입니다. build 스테이지가 없는 경우 .pre 스테이지 뒤에 파이프라인의 맨 처음에 주입될 것입니다.
  3. .pipeline-policy-post 스테이지는 파이프라인의 맨 끝에서 .post 스테이지 뒤에 실행될 것입니다.

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

저희는 실험 단계의 일환으로 이 접근 방식을 시도해 볼 것입니다. 또한 다음과 같은 전략에 대해 논의해 보고자 합니다:

1. 보안 정책 스테이지 순서 우선 순위 부여

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

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

stages:
  - test
  - policy_after_test

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

2. prepost 키워드 소개

보안 정책은 pre_[stage_name]post_[stage_name] 단계를 사용하여 특정 단계 앞이나 뒤에 작업을 주입할 수 있습니다. 예를 들어 pre_testtest 단계 앞에서 실행됩니다. 이렇게 함으로써 보안 정책이 프로젝트 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 단계가 없는 경우 파이프라인의 처음에 주입됩니다.

링크