라벨이 지정된 프로젝트에 미치는 영향
컴플라이언스 파이프라인 구성
- 예제 구성
컴플라이언스 작업이 항상 실행되도록 보장
문제 해결
- 컴플라이언스 작업이 대상 리포지터리에 덮어씌워짐
- 미리 설정된 변수가 표시되지 않음

컴플라이언스 파이프라인

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

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

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

컴플라이언스 파이프라인은 라벨이 지정된 프로젝트 파이프라인의 작업도 실행할 수 있습니다. 이로써 파이프라인 구성을 중앙에서 통제할 수 있습니다.
라벨이 지정된 프로젝트의 .gitlab-ci.yml 파일에서 정의한 변수도 컴플라이언스 파이프라인에서 정의한 작업 및 변수를 변경할 수 없습니다.

알려진 이슈로 인해 프로젝트 파이프라인은 하위 설정을 오버라이딩하지 않도록 컴플라이언스 파이프라인 구성 맨 위에 반드시 포함되어야 합니다.

자세한 내용은 아래를 참조하세요:

예제 구성을 참고하여 라벨이 지정된 프로젝트 파이프라인에서 작업을 실행하는 컴플라이언스 파이프라인을 구성하는 데 도움을 얻으세요.
컴플라이언스 파이프라인 생성 튜토리얼.

라벨이 지정된 프로젝트에 미치는 영향

사용자들은 컴플라이언스 파이프라인이 구성되었음을 알 방법이 없으며, 자신의 파이프라인이 전혀 실행되지 않거나 직접 정의하지 않은 작업이 포함된 이유를 혼란스러워할 수 있습니다.

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

따라서 프로젝트 사용자들에게 컴플라이언스 파이프라인 구성에 대해 의문과 혼란을 줄이기 위해 소통하세요.

컴플라이언스 파이프라인 구성

컴플라이언스 파이프라인을 구성하려면:

왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
설정 > 일반을 선택합니다.
컴플라이언스 프레임워크 섹션을 확장합니다.
컴플라이언스 파이프라인 구성(선택 사항) 에 컴플라이언스 프레임워크 구성 경로를 추가합니다. 파일 경로/yaml@그룹-이름/프로젝트-이름 형식을 사용합니다. 예:
- .compliance-ci.yml@gitlab-org/gitlab.
- .compliance-ci.yaml@gitlab-org/gitlab.

이 구성은 컴플라이언스 프레임워크 라벨이 적용된 프로젝트에서 상속됩니다. 적용된 컴플라이언스 프레임워크 라벨이 지정된 프로젝트에서는 컴플라이언스 파이프라인 구성이 라벨이 지정된 프로젝트의 파이프라인 구성 대신 실행됩니다.

라벨이 지정된 프로젝트에서 파이프라인을 실행하는 사용자는 적어도 컴플라이언스 프로젝트에 기록자 역할을 가지고 있어야 합니다.

스캔 실행을 강제하기 위해 사용하는 경우 이 기능은 스캔 실행 정책과 일부 중복됩니다. 이 두 기능에 대한 사용자 경험을 통합하지 않았습니다. 이러한 기능 사이의 유사성과 차이에 대한 자세한 내용은 스캔 실행 강제를 참조하세요.

예제 구성

다음 예제 .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 구성은 컴플라이언스 파이프라인이 호스트 프로젝트에서 실행될 필요가 있는 경우에 대비하여 순환 포함을 피합니다. 컴플라이언스 파이프라인이 라벨이 지정된 프로젝트에서만 실행되는 경우 이 부분을 생략할 수 있습니다.

컴플라이언스 파이프라인 및 외부에 호스트된 사용자 지정 파이프라인 구성

위 예제는 모든 프로젝트가 자신의 파이프라인 구성을 동일한 프로젝트에 호스팅한다고 가정합니다. 프로젝트가 프로젝트 외부에 호스팅된 설정을 사용하는 경우:

예제 컴플라이언스 파이프라인 구성의 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: 구성 파일을 검색하는 데 사용할 ref, 예: main.

프로젝트 포크에서 시작된 Merge Request의 컴플라이언스 파이프라인

Merge Request이 포크에서 시작된 경우, Merge되어야 하는 브랜치는 보통 포크에만 존재합니다. 이러한 Merge Request을 컴플라이언스 파이프라인을 갖는 프로젝트에 대해 생성할 때, 위 스니펫은 다음 오류 메시지와 함께 실패합니다: 프로젝트 <프로젝트-이름> 참조 <브랜치-이름>이(가) 존재하지 않습니다! 이 오류는 대상 프로젝트의 컨텍스트에서 $CI_COMMIT_REF_NAME이(가) 존재하지 않는 브랜치 이름으로 평가되기 때문에 발생합니다.

올바른 컨텍스트를 얻으려면 $CI_PROJECT_PATH 대신 $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH를 사용하세요. 이 변수는 Merge Request 파이프라인에서만 사용할 수 있습니다.

예를 들어, 프로젝트 포크에서 시작된 Merge Request 파이프라인과 브랜치 파이프라인을 모두 지원하는 구성의 경우, 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'

이 예에서 구성 파일은 exists:project: $CI_PROJECT_PATH에서 제공된 ref에 대해 프로젝트에서 존재하는 경우에만 포함됩니다.

이 문제를 해결하기 위해 rules:exists with include를 사용할 수 없습니다. 왜냐하면 include:rules:exists는 include가 정의된 프로젝트에서 파일을 검색하기 때문입니다. 컴플라이언스 파이프라인에서 위 예제의 include는 컴플라이언스 파이프라인 구성 파일을 호스팅하는 프로젝트에서 정의되었기 때문에 문제를 해결할 수 없습니다.

컴플라이언스 작업이 항상 실행되도록 보장

컴플라이언스 파이프라인은 GitLab CI/CD를 사용하여 사용자가 원하는 어떤 유형의 컴플라이언스 작업도 정의하는 데 놀라운 유연성을 제공합니다. 귀하의 목표에 따라 이러한 작업을 다음과 같이 구성할 수 있습니다:

사용자에 의해 수정될 수 있음.
수정할 수 없음.

일반적으로 컴플라이언스 작업의 값이:

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

사용 용도에 따라 원하는 대로 해야 할 수도 있고 아닐 수도 있습니다.

다음은 항상 귀하가 정의하는 대로 이러한 작업이 실행되고 하위 프로젝트 수준 파이프라인 구성이 그들을 변경하지 못하도록 하는 몇 가지 모범 사례입니다:

각 컴플라이언스 작업에 a rules:when:always block을 추가하세요. 이렇게 하면 그들이 수정될 수 없으며 항상 실행됩니다.
작업이 참조하는 변수를 명시적으로 설정하세요. 이렇게 하면 프로젝트 수준 파이프라인 구성이 그들을 설정하고 그들의 동작을 변경하지 않습니다. 예를 들어, 예제 구성의 before_script와 after_script 구성을 참고하세요.
작업을 실행할 컨테이너 이미지를 명시적으로 설정하세요. 이렇게 하면 스크립트 단계가 올바른 환경에서 실행됩니다.
관련된 GitLab 사전 정의 작업 키워드를 명시적으로 설정하세요. 이렇게 하면 원하는 설정을 사용하고 프로젝트 수준 파이프라인에 의해 재정의되지 않는지 확인할 수 있습니다.

문제 해결

컴플라이언스 작업이 대상 리포지터리에 덮어씌워짐

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

"컴플라이언스 작업":
  extends:
    - .compliance_template
  stage: build

.compliance_template:
  script:
    - echo "컴플라이언스 조치 수행"

다음과 같은 .gitlab-ci.yml 구성이 있는 경우:

"컴플라이언스 작업":
  stage: test
  script:
    - echo "컴플라이언스 조치 덮어씌움"

이러한 구성은 대상 리포지터리 파이프라인이 컴플라이언스 파이프라인을 덮어씌우고 컴플라이언스 조치 덮어씌움이라는 메시지가 표시됩니다.

컴플라이언스 작업을 덮어쓰지 않으려면 컴플라이언스 파이프라인 구성에서 extends 키워드를 사용하지 마세요. 예를 들어, 다음과 같은 .compliance-gitlab-ci.yml 구성이 있는 경우:

"컴플라이언스 작업":
  stage: build
  script:
    - echo "컴플라이언스 조치 수행"

다음과 같은 .gitlab-ci.yml 구성이 있는 경우:

"컴플라이언스 작업":
  stage: test
  script:
    - echo "컴플라이언스 조치 덮어씌움"

이러한 구성은 컴플라이언스 파이프라인을 덮어씌우지 않으며 컴플라이언스 조치 수행이라는 메시지가 표시됩니다.

미리 설정된 변수가 표시되지 않음

GitLab 15.3 및 이후의 컴플라이언스 파이프라인에서는 알려진 문제로 인해 매뉴얼으로 파이프라인을 시작할 때 미리 설정된 변수가 표시되지 않을 수 있습니다.

이 문제를 해결하기 위해, 매뉴얼으로 프로젝트의 구성을 실행하는 include: 문에 ref: '$CI_COMMIT_REF_NAME' 대신 ref: '$CI_COMMIT_SHA'를 사용하세요.

예제 구성은 이 변경 사항이 적용된 다음과 같이 업데이트되었습니다:

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

컴플라이언스 파이프라인

라벨이 지정된 프로젝트에 미치는 영향

컴플라이언스 파이프라인 구성

예제 구성

컴플라이언스 파이프라인 및 외부에 호스트된 사용자 지정 파이프라인 구성

프로젝트 포크에서 시작된 Merge Request의 컴플라이언스 파이프라인

구성 파일이 없는 프로젝트에서의 컴플라이언스 파이프라인

컴플라이언스 작업이 항상 실행되도록 보장

문제 해결

컴플라이언스 작업이 대상 리포지터리에 덮어씌워짐

미리 설정된 변수가 표시되지 않음

도움말

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

도움받기