컴플라이언스 파이프라인

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

이 기능은 GitLab 17.3에서 사용 중지되었습니다 및 18.0에서 제거 예정입니다. 대신 파이프라인 실행 정책 유형을 사용하십시오. 이 변경은 파급 효과가 있는 변경입니다. 자세한 정보는 마이그레이션 가이드를 참조하십시오.

그룹 소유자는 기본적으로 다른 프로젝트와 별도로 프로젝트 내에서 컴플라이언스 파이프라인을 구성할 수 있습니다. 예를 들어, 레이블이 지정된 프로젝트의 경우 컴플라이언스 파이프라인 구성(예: .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.

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

레이블된 프로젝트에서 파이프라인을 실행하는 사용자는 반드시 컴플라이언스 프로젝트에서 기본적으로 리포터 역할을 가져야 합니다.

스캔 실행을 강제하는 데 사용되는 경우 이 기능은 스캔 실행 정책과 일부 중복되는 기능이 있습니다. 이 두 기능에 대한 사용자 경험을 통합하지 않았습니다. 이러한 기능의 유사점과 차이점에 대한 자세한 내용은 스캔 실행 강제화를 참조하십시오.

예제 구성

다음은 .compliance-gitlab-ci.yml 예제 구성입니다. include 키워드를 사용하여 레이블된 프로젝트 파이프라인 구성도 실행되도록합니다.

include:  # 프로젝트의 구성 실행(프로젝트에 .gitlab-ci가 포함된 경우)
  - 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: 구성 파일을 검색할 때 사용할 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는 적합성 파이프라인을 호스팅하는 프로젝트에서 정의되었으므로 주로 해당 프로젝트에서 파일을 검색합니다.

적합성 작업이 항상 실행되도록 보장

적합성 파이프라인은 GitLab CI/CD를 사용하여 원하는 형태의 적합성 작업을 정의하는 놀라운 유연성을 제공합니다. 목표에 따라 이러한 작업은 다음과 같이 구성할 수 있습니다:

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

일반적으로, 적합성 작업의 값:

설정될 경우 프로젝트 수준의 구성에 의해 변경되지 않거나 재정의되지 않습니다.
설정되지 않으면 프로젝트 수준의 구성으로 설정할 수 있습니다.

사용 사례에 따라 원하는지 여부는 다릅니다.

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

각 적합성 작업에 a rules:when:always 블록을 추가합니다. 이를 통해 작업이 수정할 수 없고 항상 실행됩니다.
작업이 참조하는 모든 변수를 명시적으로 설정합니다. 이렇게 하면 프로젝트 수준 파이프라인 구성에서 설정되거나 동작이 변경되지 않습니다. 예를 들어, 예시 구성에서의 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'

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

컴플라이언스 파이프라인을 구성하기 위해, 예제 구성에서는 개별 프로젝트 구성을 include.project로 포함시키는 것을 권장합니다.

이 구성은 프로젝트 파이프라인을 실행할 때 오류가 발생할 수 있습니다: 파이프라인 실행 정책 오류: 잡 이름은 고유해야 합니다. 이 오류는 파이프라인 실행 정책이 프로젝트의 .gitlab-ci.yml를 포함하고 이미 파이프라인에서 작업이 선언되었을 때 발생합니다.

이 오류를 해결하기 위해, 파이프라인 실행 정책에서 링크된 별도의 YAML 파일에서 include.project를 제거하십시오.

컴플라이언스 파이프라인

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

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

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

다중 컴플라이언스 프레임워크

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

예제 구성

외부에서 호스팅된 적합성 파이프라인 및 사용자 정의 파이프라인 구성

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

구성 파일이 없는 프로젝트에서의 적합성 파이프라인

적합성 작업이 항상 실행되도록 보장

문제 해결

컴플라이언스 작업이 대상 저장소에 덮어씌워집니다

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

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

도움말

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

도움받기