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

다만 컴플라이언스 파이프라인 구성에서 레이블이 지정된 프로젝트의 .gitlab-ci.yml 파일을 참조하면 다음이 가능합니다:

• 컴플라이언스 파이프라인이 레이블이 지정된 프로젝트 파이프라인의 job도 실행할 수 있습니다. 이를 통해 파이프라인 구성을 중앙에서 통제할 수 있습니다.
• 컴플라이언스 파이프라인에 정의된 job과 변수는 레이블이 지정된 프로젝트의 .gitlab-ci.yml 파일에 있는 변수로 변경할 수 없습니다.

자세한 내용은 다음을 참고합니다:

• 레이블이 지정된 프로젝트 파이프라인 구성의 job을 실행하는 컴플라이언스 파이프라인 구성 방법은 구성 예시를 참고합니다.
• 컴플라이언스 파이프라인 만들기 튜토리얼.

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

파이프라인 실행 정책은 스캔과 파이프라인 강제 적용을 통합하고 단순화하는 것을 목표로 합니다. 컴플라이언스 파이프라인은 GitLab 17.3에서 더 이상 사용되지 않게 되었고 GitLab 19.0에서 제거됩니다.

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

새 컴플라이언스 프레임워크를 만들 때는 기본적으로 컴플라이언스 파이프라인 대신 파이프라인 실행 정책 유형을 사용하도록 안내됩니다.

기존 컴플라이언스 파이프라인은 마이그레이션해야 합니다. 컴플라이언스 파이프라인에서 새 파이프라인 실행 정책 유형으로 최대한 빨리 전환합니다.

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

기존 컴플라이언스 프레임워크를 파이프라인 실행 정책 유형으로 마이그레이션하려면 다음을 수행합니다:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.
3. 기존 컴플라이언스 프레임워크를 편집합니다.
4. 표시되는 배너에서 Migrate pipeline to a policy를 선택해 보안 정책에 새 정책을 만듭니다.
5. 컴플라이언스 프레임워크를 다시 편집해 컴플라이언스 파이프라인을 제거합니다.

자세한 내용은 보안 정책 프로젝트를 참고합니다.

마이그레이션 중에 Pipeline execution policy error: Job names must be unique 오류가 발생하면 관련 문제 해결 정보를 참고합니다.

레이블이 지정된 프로젝트에 대한 영향#

사용자는 컴플라이언스 파이프라인이 구성되었는지 알 수 없어, 자신의 파이프라인이 전혀 실행되지 않거나 직접 정의하지 않은 job 이 포함되는 이유를 혼란스러워할 수 있습니다.

레이블이 지정된 프로젝트에서 파이프라인을 작성할 때 컴플라이언스 파이프라인이 구성되어 있다는 표시는 없습니다. 프로젝트 수준의 유일한 표시는 컴플라이언스 프레임워크 레이블 자체이지만, 이 레이블은 해당 프레임워크에 컴플라이언스 파이프라인이 구성되어 있는지는 알려주지 않습니다.

따라서 불확실성과 혼란을 줄이려면 프로젝트 사용자에게 컴플라이언스 파이프라인 구성을 알립니다.

복수의 컴플라이언스 프레임워크#

컴플라이언스 파이프라인이 구성된 여러 컴플라이언스 프레임워크를 하나의 프로젝트에 적용할 수 있습니다. 이 경우 프로젝트에 가장 먼저 적용된 컴플라이언스 프레임워크의 컴플라이언스 파이프라인만 프로젝트 파이프라인에 포함됩니다.

프로젝트에 올바른 컴플라이언스 파이프라인이 포함되도록 하려면 다음을 수행합니다:

1. 프로젝트에서 모든 컴플라이언스 프레임워크를 제거합니다.
2. 올바른 컴플라이언스 파이프라인이 있는 컴플라이언스 프레임워크를 프로젝트에 적용합니다.
3. 추가 컴플라이언스 프레임워크를 프로젝트에 적용합니다.

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

컴플라이언스 파이프라인을 구성하려면 다음을 수행합니다:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

2. 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

3. Frameworks 섹션을 선택합니다.

4. New framework 섹션을 선택하고 컴플라이언스 프레임워크 구성 파일 경로를 포함해 컴플라이언스 프레임워크 정보를 추가합니다. 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:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA' # Must be defined or MR pipelines always use the use default branch
    rules:
      - if: $CI_PROJECT_PATH != "my-group/project-1" # Must run on projects other than the one hosting this configuration.

# Allows compliance team to control the ordering and interweaving of stages/jobs.
# Stages without jobs defined will remain hidden.
stages:
  - pre-compliance
  - build
  - test
  - pre-deploy-compliance
  - deploy
  - post-compliance

variables:  # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
  FOO: sast

sast:  # None of these attributes can be overridden by a project's local .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  # or 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  # or 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  # or 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:
    # If the custom path variables are defined, include the project's external config file.
    - 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
    # If any custom path variable is not defined, include the project's internal config file as normal.
    - 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:  # Execute individual project's configuration (if project contains .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:  # Execute individual project's configuration
  - 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로 구성 파일이 존재할 때만 포함됩니다.

컴플라이언스 파이프라인 구성에 exists:project를 지정하지 않으면 include가 정의된 프로젝트에서 파일을 찾습니다. 컴플라이언스 파이프라인에서 앞 예시의 include는 파이프라인을 실행하는 프로젝트가 아니라 컴플라이언스 파이프라인 구성 파일을 호스팅하는 프로젝트에 정의되어 있습니다.

컴플라이언스 job 이 항상 실행되도록 보장#

컴플라이언스 파이프라인은 GitLab CI/CD를 사용하므로 원하는 형태의 컴플라이언스 job을 폭넓게 정의할 수 있습니다. 목적에 따라 이러한 job은 다음과 같이 구성할 수 있습니다:

• 사용자가 수정할 수 있는 job.
• 수정할 수 없는 job.

일반적으로 컴플라이언스 job의 값은 다음과 같이 동작합니다:

• 값이 설정되어 있으면 프로젝트 수준 구성으로 변경하거나 재정의할 수 없습니다.
• 값이 설정되어 있지 않으면 프로젝트 수준 구성에서 설정할 수 있습니다.

어느 쪽이 적절한지는 사용 사례에 따라 다릅니다.

다음은 이러한 job 이 정의한 그대로 항상 실행되고, 하위의 프로젝트 수준 파이프라인 구성이 이를 변경하지 못하도록 하는 몇 가지 권장 사항입니다:

• 각 컴플라이언스 job에 rules:when:always 블록을 추가합니다. 이렇게 하면 job을 수정할 수 없고 항상 실행됩니다.
• job 이 참조하는 변수를 명시적으로 설정합니다. 이렇게 하면 다음 효과가 있습니다:
  • 프로젝트 수준 파이프라인 구성이 변수를 설정해 동작을 바꾸지 못하도록 합니다. 예를 들어 구성 예시의 before_script 및 after_script 구성을 참고합니다.
  • job의 로직을 이끄는 job도 함께 포함됩니다.
• job을 실행할 컨테이너 이미지를 명시적으로 설정합니다. 이렇게 하면 스크립트 단계가 올바른 환경에서 실행됩니다.
• 관련된 GitLab 사전 정의 job 키워드를 명시적으로 설정합니다. 이렇게 하면 job 이 의도한 설정을 사용하고, 프로젝트 수준 파이프라인이 그 설정을 재정의하지 못합니다.

문제 해결#

컴플라이언스 job 이 대상 리포지터리에 의해 덮어쓰이는 문제#

컴플라이언스 파이프라인 구성에서 extends 구문을 사용하면 컴플라이언스 job 이 대상 리포지터리의 job에 의해 덮어쓰입니다. 예를 들어 다음과 같은 .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.

컴플라이언스 job 이 덮어쓰이지 않게 하려면 컴플라이언스 파이프라인 구성에서 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.

사전 입력된 변수가 표시되지 않는 문제#

알려진 문제 때문에 파이프라인을 수동으로 시작할 때 컴플라이언스 파이프라인이 사전 입력된 변수가 표시되지 않게 만들 수 있습니다.

이 문제를 우회하려면 개별 프로젝트 구성을 실행하는 include: 구문에서 ref: '$CI_COMMIT_REF_NAME' 대신 ref: '$CI_COMMIT_SHA'를 사용합니다.

구성 예시에는 이 변경이 반영되어 있습니다:

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

오류: Job names must be unique#

컴플라이언스 파이프라인을 구성할 때 구성 예시는 include.project로 개별 프로젝트 구성을 포함할 것을 권장합니다.

이 구성은 프로젝트 파이프라인을 실행할 때 Pipeline execution policy error: Job names must be unique 오류를 일으킬 수 있습니다. 파이프라인 실행 정책이 프로젝트의 .gitlab-ci.yml을 포함하면서, 이미 파이프라인에 선언된 job을 다시 삽입하려 하기 때문입니다.

이 오류를 해결하려면 파이프라인 실행 정책에 연결된 별도 YAML 파일에서 include.project를 제거합니다.