컴플라이언스 파이프라인

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

이 기능은 사용 중단 되었으며 GitLab 17.3에서 제거될 예정입니다. 대신 파이프라인 실행 정책 유형을 사용하십시오.
이 변경은 파괴적인 변경입니다. 더 많은 정보를 보려면 마이그레이션 가이드를 참조하십시오.

그룹 소유자는 다른 프로젝트와 별도로 프로젝트에서 컴플라이언스 파이프라인을 구성할 수 있습니다. 기본적으로, 컴플라이언스
파이프라인 구성(예: .compliance-gitlab-ci.yml)은 레이블이 지정된 프로젝트의 파이프라인 구성(예: .gitlab-ci.yml) 대신 실행됩니다.

그러나 컴플라이언스 파이프라인 구성은 레이블이 지정된 프로젝트의 .gitlab-ci.yml 파일을 참조할 수 있습니다. 따라서:

컴플라이언스 파이프라인은 레이블이 지정된 프로젝트 파이프라인의 작업을 실행할 수 있습니다. 이를 통해
파이프라인 구성을 중앙 집중식으로 제어할 수 있습니다.
컴플라이언스 파이프라인에서 정의된 작업 및 변수는 레이블이 지정된 프로젝트의 .gitlab-ci.yml 파일의 변수를 통해 변경될 수 없습니다.

알려진 문제로 인해, 프로젝트 파이프라인은 컴플라이언스 파이프라인 구성의
맨 위에 포함되어야 하며, 이를 통해 프로젝트가 다운스트림에서 설정을 무시하지 않도록 해야 합니다.

더 많은 정보를 보려면:

예제 구성을 참조하여 레이블이 지정된 프로젝트 파이프라인 구성에서 작업을 실행하는 컴플라이언스 파이프라인을 구성하는 방법에 대해 알아보세요.
컴플라이언스 파이프라인 생성하기 튜토리얼을 참조하세요.

파이프라인 실행 정책 마이그레이션

스캔 및 파이프라인 시행을 통합하고 단순화하기 위해 파이프라인 실행 정책을 도입했습니다. 우리는
GitLab 17.3에서 컴플라이언스 파이프라인을 사용 중단하였으며 GitLab 18.0에서 컴플라이언스 파이프라인을 제거할 예정입니다.

파이프라인 실행 정책은 프로젝트의 .gitlab-ci.yml 파일을 별도의 YAML 파일에서 제공된 구성으로 확장합니다
(예: pipeline-execution.yml). 이 파일은 파이프라인 실행 정책에 연결되어 있습니다.

기본적으로, 새로운 컴플라이언스 프레임워크를 생성할 때, 컴플라이언스 파이프라인 대신 파이프라인 실행 정책 유형을 사용하도록 안내받습니다.

기존의 컴플라이언스 파이프라인은 마이그레이션해야 합니다. 고객은 가능한 한 빨리 컴플라이언스 파이프라인에서
새로운 파이프라인 실행 정책 유형으로 마이그레이션해야 합니다.

기존 컴플라이언스 프레임워크 마이그레이션

기존의 컴플라이언스 프레임워크를 파이프라인 실행 정책 유형을 사용하도록 마이그레이션하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
보안 > 컴플라이언스 센터를 선택합니다.
기존의 컴플라이언스 프레임워크를 편집합니다.
나타나는 배너에서 정책으로 파이프라인 마이그레이션을 선택하여 보안 정책에서 새로운 정책을 생성합니다.
컴플라이언스 파이프라인을 제거하기 위해 컴플라이언스 프레임워크를 다시 편집합니다.

더 많은 정보를 보려면 보안 정책 프로젝트를 참조하십시오.

마이그레이션 중에 파이프라인 실행 정책 오류: 작업 이름은 고유해야 합니다 오류가 발생하면, 해당 문제 해결 정보를 확인하십시오.

레이블이 지정된 프로젝트에 미치는 영향

사용자는 컴플라이언스 파이프라인이 구성되었는지 알 수 있는 방법이 없으며, 본인의 파이프라인이 전혀 실행되지 않거나
자신이 정의하지 않은 작업이 포함되어 있는 이유에 대해 혼란스러울 수 있습니다.

레이블이 지정된 프로젝트에서 파이프라인을 작성할 때, 컴플라이언스 파이프라인이 구성되었다는 표시가 없습니다.
프로젝트 수준에서 유일한 표시는 컴플라이언스 프레임워크 레이블 자체이지만, 이 레이블은 프레임워크에
컴플라이언스 파이프라인이 구성되었는지 여부를 나타내지 않습니다.

따라서, 불확실성과 혼란을 줄이기 위해 프로젝트 사용자에게 컴플라이언스 파이프라인 구성에 대해 의사 소통하십시오.

여러 준수 프레임워크

여러 준수 프레임워크를 단일 프로젝트에 적용할 수 있으며, 이는 구성된 준수 파이프라인이 포함되어 있습니다.

이 경우, 프로젝트에 적용된 첫 번째 준수 프레임워크만 해당 프로젝트 파이프라인에 포함됩니다.

프로젝트에 올바른 준수 파이프라인이 포함되도록 하려면:

프로젝트에서 모든 준수 프레임워크를 제거합니다.
올바른 준수 파이프라인을 가진 준수 프레임워크를 프로젝트에 적용합니다.
추가 준수 프레임워크를 프로젝트에 적용합니다.

준수 파이프라인 구성

도입됨 GitLab 15.11에서, 준수 프레임워크가 준수 센터로 이동했습니다.

준수 파이프라인을 구성하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
보안 > 준수 센터를 선택합니다.
프레임워크 섹션을 선택합니다.
새 프레임워크 섹션을 선택하고 준수 프레임워크 구성을 위한 경로를 포함하여 준수 프레임워크의 정보를 추가합니다. 형식은 path/file.y[a]ml@group-name/project-name입니다. 예를 들면:
- .compliance-ci.yml@gitlab-org/gitlab.
- .compliance-ci.yaml@gitlab-org/gitlab.

이 구성은 준수 프레임워크 라벨이 적용된 프로젝트에 상속됩니다. 준수 프레임워크 라벨이 적용된 프로젝트에서는 준수 파이프라인 구성이 라벨이 있는 프로젝트의 자체 파이프라인 구성 대신 실행됩니다.

라벨이 지정된 프로젝트에서 파이프라인을 실행하는 사용자는 준수 프로젝트에서 최소한 Reporter 역할을 가져야 합니다.

스캔 실행을 강제하는 데 사용될 때, 이 기능은 스캔 실행 정책과 약간의 겹침이 있습니다. 우리는 이 두 기능에 대한 사용자 경험을 통합하지 않았습니다. 이러한 기능의 유사점과 차이점에 대한 자세한 내용은 스캔 실행 강제를 참조하세요.

예제 구성

다음 예제 .compliance-gitlab-ci.yml에는 라벨이 있는 프로젝트의 파이프라인 구성이 실행되도록 보장하는 include 키워드가 포함되어 있습니다.

include:  # 개별 프로젝트의 구성 실행(프로젝트에 .gitlab-ci.yml이 포함된 경우)
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA' # 정의되어야 하며, 그렇지 않으면 MR 파이프라인은 항상 기본 브랜치를 사용합니다.
    rules:
      - if: $CI_PROJECT_PATH != "my-group/project-1" # 이 구성을 호스팅하는 프로젝트 이외의 프로젝트에서 실행되어야 합니다.

# 준수 팀이 단계/작업의 순서 및 상호작용을 제어할 수 있습니다.
# 작업이 정의되지 않은 단계는 숨겨진 상태로 유지됩니다.
stages:
  - pre-compliance
  - build
  - test
  - pre-deploy-compliance
  - deploy
  - post-compliance

variables:  # 프로젝트의 로컬 .gitlab-ci.yml에서 작업별 변수를 설정하여 오버라이드할 수 있습니다.
  FOO: sast

sast:  # 이 속성 중 어떤 것도 프로젝트의 로컬 .gitlab-ci.yml에서 오버라이드할 수 없습니다.
  variables:
    FOO: sast
  image: ruby:2.6
  stage: pre-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # 또는 when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

sanity check:
  image: ruby:2.6
  stage: pre-deploy-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # 또는 when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

audit trail:
  image: ruby:2.7
  stage: post-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # 또는 when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

include 정의의 rules 구성은 준수 파이프라인이 호스팅 프로젝트 자체에서 실행될 수 있는 경우 순환 포함을 방지합니다.

라벨이 지정된 프로젝트에서만 실행되는 준수 파이프라인의 경우 이를 생략할 수 있습니다.

외부에서 호스팅되는 준수 파이프라인 및 사용자 지정 파이프라인 구성

위의 예제는 모든 프로젝트가 동일한 프로젝트에 파이프라인 구성을 호스팅한다고 가정합니다.

외부에서 호스팅되는 구성을 사용하는 프로젝트가 있는 경우, 예제 구성은 작동하지 않습니다. 자세한 내용은 문제 393960을 참조하세요.

외부에서 호스팅되는 구성을 사용하는 프로젝트에서 다음과 같은 우회 방법을 시도할 수 있습니다:

예제 준수 파이프라인 구성의 include 섹션을 조정해야 합니다. 예를 들어, include:rules를 사용하여:

include:
  # 사용자 정의 경로 변수가 정의된 경우, 프로젝트의 외부 구성 파일을 포함합니다.
  - project: '$PROTECTED_PIPELINE_CI_PROJECT_PATH'
    file: '$PROTECTED_PIPELINE_CI_CONFIG_PATH'
    ref: '$PROTECTED_PIPELINE_CI_REF'
    rules:
      - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH && $PROTECTED_PIPELINE_CI_CONFIG_PATH && $PROTECTED_PIPELINE_CI_REF
  # 사용자 정의 경로 변수가 정의되지 않은 경우, 프로젝트의 내부 구성 파일을 정상적으로 포함합니다.
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'
    rules:
      - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH == null || $PROTECTED_PIPELINE_CI_CONFIG_PATH == null || $PROTECTED_PIPELINE_CI_REF == null

외부 파이프라인 구성의 프로젝트에 CI/CD 변수를 추가해야 합니다. 이 예제에서:
- PROTECTED_PIPELINE_CI_PROJECT_PATH: 구성 파일을 호스팅하는 프로젝트의 경로, 예: group/subgroup/project.
- PROTECTED_PIPELINE_CI_CONFIG_PATH: 프로젝트 내 구성 파일의 경로, 예: path/to/.gitlab-ci.yml.
- PROTECTED_PIPELINE_CI_REF: 구성 파일을 검색할 때 사용할 참조, 예: main.

프로젝트 포크에서 발생하는 병합 요청의 준수 파이프라인

병합 요청이 포크에서 발생하는 경우, 병합할 브랜치는 일반적으로 포크에만 존재합니다.

이런 병합 요청을 준수 파이프라인이 있는 프로젝트에 대해 생성할 때, 위의 코드 조각은 Project <project-name> reference <branch-name> does not exist! 오류 메시지로 실패합니다.

이 오류는 대상 프로젝트의 맥락에서 $CI_COMMIT_REF_NAME이 존재하지 않는 브랜치 이름으로 평가되기 때문에 발생합니다.

정확한 맥락을 얻으려면 $CI_PROJECT_PATH 대신 $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH를 사용하세요.

이 변수는 병합 요청 파이프라인에서만 사용할 수 있습니다.

예를 들어, 프로젝트 포크에서 발생하는 병합 요청 파이프라인과 브랜치 파이프라인을 모두 지원하는 구성을 위해, 두 개의 include 지시문을 rules:if로 결합해야 합니다:

include:  # 개별 프로젝트의 구성을 실행합니다(프로젝트에 .gitlab-ci.yml이 포함된 경우)
  - project: '$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE != 'merge_request_event'

구성 파일이 없는 프로젝트의 준수 파이프라인

위의 예제 구성은 모든 프로젝트에 파이프라인 구성 파일(.gitlab-ci.yml 기본값)이 포함되어 있다고 가정합니다. 하지만 구성 파일이 없는 프로젝트(기본적으로 파이프라인이 없음)에서는 include:project에 지정된 파일이 필요하기 때문에 준수 파이프라인이 실패합니다.

구성 파일이 대상 프로젝트에 존재할 경우에만 포함하려면 rules:exists:project를 사용하세요:

include:  # 개별 프로젝트의 구성을 실행합니다.
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'
    rules:
      - exists:
          paths:
            - '$CI_CONFIG_PATH'
          project: '$CI_PROJECT_PATH'
          ref: '$CI_COMMIT_SHA'

이 예제에서는 주어진 ref가 프로젝트에 존재할 경우에만 구성 파일이 포함됩니다.

exists:project가 준수 파이프라인 구성에서 지정되지 않으면, include가 정의된 프로젝트에서 파일을 검색합니다. 준수 파이프라인에서 위의 예제의 include는 준수 파이프라인 구성 파일을 호스팅하는 프로젝트에 정의되어 있으며, 파이프라인을 실행하는 프로젝트에는 정의되어 있지 않습니다.

준수 작업이 항상 실행되도록 보장하기

준수 파이프라인은 GitLab CI/CD를 사용하여 원하는 모든 종류의 준수 작업을 정의하는 데 엄청난 유연성을 제공합니다. 목표에 따라 이러한 작업은 다음과 같이 구성될 수 있습니다:

사용자가 수정 가능.
수정 불가능.

일반적으로 준수 작업의 값이:

설정된 경우, 프로젝트 수준의 구성에 의해 변경되거나 재정의될 수 없습니다.
설정되지 않은 경우, 프로젝트 수준의 구성이 설정될 수 있습니다.

이것은 사용 사례에 따라 다를 수 있습니다.

다음은 이러한 작업이 항상 정의한 대로 정확하게 실행되도록 하고, 하위의 프로젝트 수준 파이프라인 구성이 변경할 수 없도록 하기 위한 몇 가지 모범 사례입니다:

각 준수 작업에 rules:when:always 블록을 추가하세요. 이는 작업이 수정 불가능하며 항상 실행되도록 보장합니다.
작업이 참조하는 모든 변수를 명시적으로 설정하세요. 이렇게 하면:
- 프로젝트 수준 파이프라인 구성이 이를 설정하고 동작을 변경하지 않도록 보장합니다. 예를 들어, 예제 구성의 before_script 및 after_script 구성을 참조하세요.
- 작업의 논리를 주도하는 작업이 포함됩니다.
작업을 실행할 컨테이너 이미지를 명시적으로 설정하세요. 이는 스크립트 단계가 올바른 환경에서 실행되도록 보장합니다.
관련 GitLab 미리 정의된 작업 키워드를 명시적으로 설정하세요. 이는 작업이 의도한 설정을 사용하고, 프로젝트 수준 파이프라인에 의해 재정의되지 않도록 보장합니다.

문제 해결

준수 작업이 대상 리포지토리에 의해 덮어쓰기됨

준수 파이프라인 구성에서 extends 문을 사용하는 경우, 준수 작업이 대상 리포지토리 작업에 의해 덮어씌워집니다. 예를 들어, 다음과 같은 .compliance-gitlab-ci.yml 구성이 있다면:

"compliance job":
  extends:
    - .compliance_template
  stage: build

.compliance_template:
  script:
    - echo "take compliance action"

여기에 다음과 같은 .gitlab-ci.yml 구성이 있을 수 있습니다:

"compliance job":
  stage: test
  script:
    - echo "overwriting compliance action"

이 구성은 대상 리포지토리 파이프라인이 준수 파이프라인을 덮어쓰게 하며, 다음과 같은 메시지를 가져옵니다: overwriting compliance action.

준수 작업이 덮어쓰여지지 않도록 하려면 준수 파이프라인 구성에서 extends 키워드를 사용하지 마세요. 예를 들어, 다음과 같은 .compliance-gitlab-ci.yml 구성이 있을 수 있습니다:

"compliance job":
  stage: build
  script:
    - echo "take compliance action"

여기에 다음과 같은 .gitlab-ci.yml 구성이 있다면:

"compliance job":
  stage: test
  script:
    - echo "overwriting compliance action"

이 구성은 준수 파이프라인을 덮어쓰지 않으며, 다음과 같은 메시지를 가져옵니다: take compliance action.

미리 채워진 변수가 표시되지 않음

알려진 문제로 인해,

GitLab 15.3 이상에서 컴플라이언스 파이프라인은 수동으로 파이프라인을 시작할 때

미리 채워진 변수가 나타나지 않도록 할 수 있습니다.

이 문제를 해결하기 위해, 개별 프로젝트 구성을 실행하는 include: 문에서

ref: '$CI_COMMIT_SHA' 대신 ref: '$CI_COMMIT_REF_NAME'를 사용하세요.

예시 구성이 이 변경 사항으로 업데이트되었습니다:

include:
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'

오류: `작업 이름은 고유해야 합니다`

컴플라이언스 파이프라인을 구성하기 위해, 예시 구성은

include.project로 개별 프로젝트 구성을 포함할 것을 권장합니다.

이 구성은 프로젝트의 파이프라인을 실행할 때 Pipeline execution policy error: Job names must be unique 오류를 발생시킬 수 있습니다.

이 오류는 파이프라인 실행 정책이 프로젝트의 .gitlab-ci.yml을 포함하고,

작업이 이미 파이프라인에서 선언되어 있을 때 작업을 삽입하려고 하기 때문에 발생합니다.

이 오류를 해결하려면,

파이프라인 실행 정책에 링크된 별도의 YAML 파일에서 include.project를 제거하세요.

컴플라이언스 파이프라인

파이프라인 실행 정책 마이그레이션

기존 컴플라이언스 프레임워크 마이그레이션

레이블이 지정된 프로젝트에 미치는 영향

여러 준수 프레임워크

준수 파이프라인 구성

예제 구성

외부에서 호스팅되는 준수 파이프라인 및 사용자 지정 파이프라인 구성

프로젝트 포크에서 발생하는 병합 요청의 준수 파이프라인

구성 파일이 없는 프로젝트의 준수 파이프라인

준수 작업이 항상 실행되도록 보장하기

문제 해결

준수 작업이 대상 리포지토리에 의해 덮어쓰기됨

미리 채워진 변수가 표시되지 않음

오류: `작업 이름은 고유해야 합니다`

도움말

기능 사용 가능성과 제품 평가판

도움받기