히스토리

• GitLab 17.2에서 pipeline_execution_policy_type이라는 플래그와 함께 도입됨. 기본적으로 활성화됨.

• GitLab 17.3에서 일반적으로 사용 가능해짐. Feature flag pipeline_execution_policy_type 제거됨.

파이프라인 실행 정책을 사용하면 단일 구성으로 여러 프로젝트의 CI/CD job을 관리하고 적용할 수 있습니다.

동영상 연습은 Security Policies: Pipeline Execution Policy Type을 참조하세요.

스키마#

히스토리

• GitLab 17.4에서 suffix 필드가 활성화됨.
• GitLab 17.7에서 이후 스테이지가 .pipeline-policy-pre 스테이지 완료를 기다리도록 파이프라인 실행이 변경됨.
• GitLab 18.10에서 .pipeline-policy-pre 스테이지가 실패할 때 이후 모든 작업이 건너뛰어지도록 파이프라인 실행이 변경됨. 기본적으로 활성화됨.
• GitLab 19.0에서 새 파이프라인 실행이 일반 제공됨. 기능 플래그 ensure_pipeline_policy_pre_succeeds 제거됨.

파이프라인 실행 정책이 포함된 YAML 파일은 pipeline_execution_policy 키 아래에 중첩된 파이프라인 실행 정책 스키마와 일치하는 객체의 배열로 구성됩니다. pipeline_execution_policy 키당 최대 5개의 정책을 구성할 수 있습니다. 처음 5개 이후에 구성된 추가 정책은 적용되지 않습니다.

새 정책을 저장하면 GitLab이 이 JSON 스키마에 대해 내용을 검증합니다. JSON 스키마 읽는 방법에 익숙하지 않은 경우 다음 섹션과 표에서 대안을 제공합니다.

pipeline_execution_policy 스키마#

다음에 유의하세요:

• 파이프라인을 트리거하는 사용자는 파이프라인 실행 정책에 지정된 파이프라인 실행 파일에 대한 최소 읽기 권한이 있어야 합니다. 그렇지 않으면 파이프라인이 시작되지 않습니다.

• 파이프라인 실행 파일이 삭제되거나 이름이 변경되면, 정책이 적용된 프로젝트의 파이프라인이 작동을 멈출 수 있습니다.

• 파이프라인 실행 정책 작업은 두 개의 예약된 스테이지 중 하나에 할당될 수 있습니다:

  .pipeline-policy-pre: .pre 스테이지 이전, 파이프라인의 시작 부분.

  • .pipeline-policy-post: .post 스테이지 이후, 파이프라인의 맨 끝.

• 예약된 스테이지에 작업을 주입하는 것은 항상 작동이 보장됩니다. 실행 정책 작업은 표준(build, test, deploy) 또는 사용자 선언 스테이지에도 할당될 수 있습니다. 그러나 이 경우 작업은 프로젝트 파이프라인 구성에 따라 무시될 수 있습니다.

• 파이프라인 실행 정책 외부에서는 예약된 스테이지에 작업을 할당할 수 없습니다.

• 파이프라인 실행 정책에 고유한 작업 이름을 선택하세요. 일부 CI/CD 구성은 작업 이름을 기반으로 하므로 동일한 파이프라인에 작업 이름이 여러 번 존재하면 원하지 않는 결과가 발생할 수 있습니다. 예를 들어, needs 키워드는 한 작업을 다른 작업에 종속시킵니다. example이라는 이름의 작업이 여러 개 있으면, example 작업 이름을 needs하는 작업은 임의로 하나의 example 작업 인스턴스에만 종속됩니다.

• 파이프라인 실행 정책은 프로젝트에 CI/CD 구성 파일이 없는 경우에도 적용됩니다.

• 정책의 순서는 적용된 접미사에 영향을 미칩니다.

• 특정 프로젝트에 적용된 정책 중 suffix: never가 있는 경우, 같은 이름의 작업이 파이프라인에 이미 존재하면 파이프라인이 실패합니다.

• 파이프라인 실행 정책은 모든 브랜치와 파이프라인 소스에 적용됩니다. 그러나 머지 요청 파이프라인의 경우, 일부 rules: 또는 workflow:rules 구성이 작업 실행을 방지할 수 있습니다. workflow rules를 사용하여 파이프라인 실행 정책이 언제 적용되는지 제어하세요.

보안 정책 파이프라인 검사#

Status: Experiment

히스토리

• GitLab 18.11에서 security_policy_pipeline_check 플래그와 함께 도입. 기본적으로 비활성화됨.
• GitLab 18.11에서 기본적으로 활성화됨.

프로젝트에 파이프라인 실행 정책 또는 스캔 실행 정책이 구성된 경우, 보안 정책 파이프라인 검사는 머지 요청을 병합하기 전에 최신 커밋에 대한 모든 파이프라인이 성공적으로 완료되어야 합니다. 이 검사는 보안 정책에서 생성한 파이프라인뿐 아니라 커밋으로 인해 실행된 모든 파이프라인에 적용됩니다.

보안 정책 파이프라인 검사는 머지 요청 파이프라인이 통과했지만 다른 파이프라인(예: 보안 정책에서 생성한 브랜치 파이프라인)이 실패한 경우 병합을 방지합니다. 그렇지 않으면 검증되지 않은 코드가 병합될 수 있습니다.

보안 정책 파이프라인 검사는 다음과 같이 동작합니다:

• 프로젝트 설정 파이프라인이 성공해야 함이 활성화된 경우, 실패한 파이프라인은 병합을 방지하는 하드 블록이 됩니다.

• 파이프라인이 성공해야 함이 활성화되지 않은 경우, 실패한 파이프라인은 경고를 생성합니다. 머지 요청은 여전히 자동 병합으로 설정될 수 있습니다.

• 프로젝트 설정 건너뛴 파이프라인을 성공으로 간주가 활성화된 경우, 건너뛴 파이프라인은 통과한 것으로 처리됩니다.

.pipeline-policy-pre Stage#

히스토리

• GitLab 18.10에서 .pipeline-policy-pre 스테이지가 실패할 때 이후 모든 작업이 건너뛰어지도록 파이프라인 실행이 변경됨. 기본적으로 활성화됨.
• GitLab 19.0에서 새 파이프라인 실행이 일반 제공됨. 기능 플래그 ensure_pipeline_policy_pre_succeeds 제거됨.

.pipeline-policy-pre 스테이지의 작업은 항상 실행됩니다. 이 스테이지는 보안 및 컴플라이언스 사용 사례를 위해 설계되었습니다. .pipeline-policy-pre 스테이지가 완료될 때까지 파이프라인의 작업이 시작되지 않습니다.

.pipeline-policy-pre 스테이지가 실패하거나 스테이지의 모든 작업이 건너뛰어지면, 다음을 포함한 이후 스테이지의 모든 작업이 건너뛰어집니다:

• needs: []가 있는 작업.
• when: always가 있는 작업.

이 동작이 워크플로우에 필요하지 않은 경우, .pre 스테이지 또는 사용자 정의 스테이지를 사용하세요.

작업 명명 모범 사례#

히스토리

• 명명 충돌 처리가 GitLab 17.4에서 도입됨.

작업이 보안 정책에 의해 생성되었다는 가시적인 표시가 없습니다. 정책에 의해 생성된 작업을 더 쉽게 식별하고 작업 이름 충돌을 방지하려면 작업 이름에 고유한 접두사나 접미사를 추가하세요.

예시:

• 사용: policy1:deployments:sast. 이 이름은 다른 모든 정책 및 프로젝트에서 고유할 가능성이 높습니다.
• 사용하지 말 것: sast. 이 이름은 다른 정책 및 프로젝트에서 중복될 가능성이 높습니다.

파이프라인 실행 정책은 suffix 속성에 따라 명명 충돌을 처리합니다. 같은 이름의 작업이 여러 개인 경우:

• on_conflict (기본값)을 사용하면, 파이프라인의 다른 작업과 이름이 충돌하는 작업에 접미사가 추가됩니다.
• never를 사용하면, 충돌 시 접미사가 추가되지 않고 파이프라인이 실패합니다.

접미사는 작업이 메인 파이프라인에 병합되는 순서에 따라 추가됩니다.

순서는 다음과 같습니다:

• 프로젝트 파이프라인 작업
• 프로젝트 정책 작업 (해당되는 경우)
• 그룹 정책 작업 (해당되는 경우, 계층 구조 순서로, 최상위 그룹이 마지막으로 적용됨)

적용된 접미사 형식:

:policy-<security-policy-project-id>-<policy-index>

결과 작업 예시: sast:policy-123456-0.

하나의 보안 정책 프로젝트의 여러 정책이 동일한 작업 이름을 정의하면, 숫자 접미사는 충돌하는 정책의 인덱스에 해당합니다.

결과 작업 예시:

• sast:policy-123456-0
• sast:policy-123456-1

작업 스테이지 모범 사례#

파이프라인 실행 정책에서 정의된 작업은 프로젝트의 CI/CD 구성에 정의된 모든 스테이지, 그리고 예약된 스테이지 .pipeline-policy-pre 및 .pipeline-policy-post를 사용할 수 있습니다.

inject_policy 파이프라인 전략을 사용할 때, 대상 프로젝트에 자체 .gitlab-ci.yml 파일이 없는 경우 모든 정책 스테이지가 파이프라인에 주입됩니다.

(더 이상 사용되지 않는) inject_ci 파이프라인 전략을 사용할 때, 대상 프로젝트에 자체 .gitlab-ci.yml 파일이 없는 경우 사용 가능한 스테이지는 기본 파이프라인 스테이지와 예약된 스테이지뿐입니다.

수정 권한이 없는 CI/CD 구성이 있는 프로젝트에 파이프라인 실행 정책을 적용할 때는 .pipeline-policy-pre 및 .pipeline-policy-post 스테이지에 작업을 정의해야 합니다. 이 스테이지는 프로젝트의 CI/CD 구성에 관계없이 항상 사용 가능합니다.

여러 파이프라인 실행 정책과 사용자 정의 스테이지를 포함한 override_project_ci 파이프라인 전략을 사용할 때, 스테이지는 호환성을 위해 동일한 상대적 순서로 정의되어야 합니다:

유효한 구성 예시:

  - override-policy-1 stages: [build, test, policy-test, deploy]
  - override-policy-2 stages: [test, deploy]

유효하지 않은 구성 예시:

  - override-policy-1 stages: [build, test, policy-test, deploy]
  - override-policy-2 stages: [deploy, test]

하나 이상의 override_project_ci 정책에 유효하지 않은 stages 구성이 있으면 파이프라인이 실패합니다.

content 유형#

정책에서 content 유형을 사용하여 다른 저장소에 저장된 CI/CD 구성을 참조하세요. 이를 통해 여러 정책에서 동일한 CI/CD 구성을 재사용하여 이러한 구성 유지 관리 오버헤드를 줄일 수 있습니다. 예를 들어, 정책 A와 정책 B에서 적용하려는 사용자 정의 시크릿 탐지 CI/CD 구성이 있는 경우, 단일 YAML 구성 파일을 만들고 두 정책에서 모두 구성을 참조할 수 있습니다.

사전 요구사항:

• content 유형이 포함된 정책이 적용된 프로젝트에서 파이프라인을 실행하는 사용자는 CI/CD를 포함하는 프로젝트에 최소한 읽기 전용 액세스 권한이 있어야 합니다.
• 파이프라인 실행 정책이 적용된 프로젝트에서 파이프라인을 트리거하려면 사용자가 CI/CD 구성이 포함된 프로젝트에 최소한 읽기 전용 액세스 권한이 있어야 합니다.

GitLab 17.4 이상에서 content 유형을 사용하는 보안 정책 프로젝트에서 CI/CD 구성 파일에 필요한 읽기 전용 액세스 권한을 부여할 수 있습니다. 이를 위해 보안 정책 프로젝트의 일반 설정에서 파이프라인 실행 정책 설정을 활성화하세요. 이 설정을 활성화하면 파이프라인을 트리거한 사용자가 파이프라인 실행 정책에서 적용된 CI/CD 구성 파일을 읽을 수 있는 액세스 권한이 부여됩니다. 이 설정은 구성 파일이 저장된 프로젝트의 다른 부분에 대한 액세스 권한은 부여하지 않습니다. 자세한 내용은 자동으로 액세스 권한 부여를 참조하세요.

skip_ci 유형#

히스토리

• GitLab 17.7에서 도입.

파이프라인 실행 정책은 [skip ci] 지시문을 사용할 수 있는 사람을 제어합니다. 중요한 보안 및 컴플라이언스 검사가 수행되도록 하면서 [skip ci]를 사용할 수 있는 특정 사용자나 서비스 계정을 지정할 수 있습니다.

skip_ci 키워드를 사용하여 사용자가 skip_ci 지시문을 적용하여 파이프라인을 건너뛸 수 있는지 여부를 지정하세요. 키워드가 지정되지 않으면, skip_ci 지시문은 무시되어 모든 사용자가 파이프라인 실행 정책을 우회하는 것을 방지합니다.

no_pipeline 유형#

파이프라인 실행 정책은 [no_pipeline] 지시문을 사용할 수 있는 사람을 제어합니다. 중요한 보안 및 컴플라이언스 검사가 수행되도록 하면서 [no_pipeline]을 사용할 수 있는 특정 사용자나 서비스 계정을 지정할 수 있습니다.

no_pipeline 키워드를 사용하여 사용자가 no_pipeline 지시문을 적용하여 파이프라인을 생성하지 않을 수 있는지 여부를 지정하세요. 키워드가 지정되지 않으면, no_pipeline 지시문은 무시되어 모든 사용자가 파이프라인 실행 정책을 우회하는 것을 방지합니다.

variables_override 유형#

히스토리

• GitLab 18.1에서 도입.

이 옵션은 정책이 적용된 파이프라인에서 사용자 정의 변수가 처리되는 방식을 제어합니다. 이 기능을 사용하면 다음을 수행할 수 있습니다:

• 기본적으로 사용자 정의 변수 거부(권장) - 더 강력한 보안을 제공하지만, 사용자 정의 가능한 모든 변수를 exceptions 허용 목록에 추가해야 합니다.
• 기본적으로 사용자 정의 변수 허용 - 더 많은 유연성을 제공하지만 보안이 낮으므로, 정책 적용에 영향을 줄 수 있는 변수를 exceptions 거부 목록에 추가해야 합니다.
• allowed 전역 규칙에 대한 예외를 정의합니다.

사용자 정의 변수는 정책 작업의 동작에 영향을 줄 수 있으며 다양한 소스에서 올 수 있습니다:

• 파이프라인 변수.
• 프로젝트 변수.
• 그룹 변수.
• 인스턴스 변수.

variables_override 옵션이 지정되지 않으면 "최고 우선순위" 동작이 유지됩니다. 이 동작에 대한 자세한 내용은 파이프라인 실행 정책의 변수 우선순위를 참조하세요.

파이프라인 실행 정책이 변수 우선순위를 제어할 때, 작업 로그에는 구성된 variables_override 옵션과 정책 이름이 포함됩니다. 이 로그를 보려면 gitlab-runner가 버전 18.1 이상으로 업데이트되어야 합니다.

variables_override 구성 예시#

파이프라인 실행 정책 구성에 variables_override 옵션을 추가하세요:

pipeline_execution_policy:
  - name: Security Scans
    description: 'Enforce security scanning'
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: gitlab-org/security-policies
          file: security-scans.yml
    variables_override:
      allowed: false
      exceptions:
        - CS_IMAGE
        - SAST_EXCLUDED_ANALYZERS

컨테이너 사용자 정의를 허용하면서 보안 스캔 적용 (허용 목록 방법)#

보안 스캔은 적용하되 프로젝트 팀이 자체 컨테이너 이미지를 지정할 수 있도록 하려면:

variables_override:
  allowed: false
  exceptions:
    - CS_IMAGE

이 구성은 CS_IMAGE를 제외한 모든 사용자 정의 변수를 차단하여 보안 스캔을 비활성화할 수 없도록 하면서 팀이 컨테이너 이미지를 사용자 정의할 수 있도록 합니다.

특정 보안 변수 재정의 방지 (거부 목록 방법)#

대부분의 변수를 허용하면서 보안 스캔 비활성화를 방지하려면:

variables_override:
  allowed: true
  exceptions:
    - SECRET_DETECTION_DISABLED
    - SAST_DISABLED
    - DEPENDENCY_SCANNING_DISABLED
    - DAST_DISABLED
    - CONTAINER_SCANNING_DISABLED

이 구성은 보안 스캔을 비활성화할 수 있는 변수를 제외한 모든 사용자 정의 변수를 허용합니다.

policy scope 스키마#

정책 적용을 사용자 정의하기 위해 지정한 프로젝트, 그룹 또는 컴플라이언스 프레임워크 레이블을 포함하거나 제외하도록 정책 범위를 정의할 수 있습니다. 자세한 내용은 범위를 참조하세요.

CI/CD 구성에 대한 액세스 관리#

프로젝트에 파이프라인 실행 정책을 적용할 때, 파이프라인을 트리거하는 사용자는 정책 CI/CD 구성이 포함된 프로젝트에 대한 최소 읽기 전용 액세스 권한이 있어야 합니다. 프로젝트에 수동 또는 자동으로 액세스 권한을 부여할 수 있습니다.

수동으로 액세스 권한 부여#

파이프라인 실행 정책이 적용된 파이프라인을 실행할 수 있도록 사용자나 그룹을 정책 CI/CD 구성이 포함된 프로젝트에 초대할 수 있습니다.

자동으로 액세스 권한 부여#

파이프라인 실행 정책이 적용된 프로젝트에서 파이프라인을 실행하는 모든 사용자에게 정책 CI/CD 구성에 대한 액세스 권한을 자동으로 부여할 수 있습니다.

사전 요구사항:

• 파이프라인 실행 정책 CI/CD 구성이 보안 정책 프로젝트에 저장되어 있는지 확인하세요.
• 보안 정책 프로젝트의 일반 설정에서 파이프라인 실행 정책 설정을 활성화하세요.

보안 정책 프로젝트가 아직 없고 첫 번째 파이프라인 실행 정책을 만들려면, 빈 프로젝트를 만들고 보안 정책 프로젝트로 연결하세요. 프로젝트를 연결하려면:

• 정책을 적용하려는 그룹 또는 프로젝트에서 보안 > 정책 > 정책 프로젝트 편집을 선택합니다.
• 보안 정책 프로젝트를 선택합니다.

프로젝트가 보안 정책 프로젝트가 되고 설정을 사용할 수 있게 됩니다.

구성#

1. 정책 프로젝트에서 설정 > 일반 > 가시성, 프로젝트 기능, 권한을 선택합니다.
2. 파이프라인 실행 정책 설정을 활성화합니다.
3. 정책 프로젝트에서 정책 CI/CD 구성 파일을 만듭니다.

# policy-ci.yml

policy-job:
  script: ...

1. 정책을 적용하려는 그룹 또는 프로젝트에서 파이프라인 실행 정책을 만들고 보안 정책 프로젝트의 CI/CD 구성 파일을 지정합니다.

pipeline_execution_policy:
- name: My pipeline execution policy
  description: Enforces CI/CD jobs
  enabled: true
  pipeline_config_strategy: inject_policy
  content:
    include:
    - project: my-group/my-security-policy-project
      file: policy-ci.yml

파이프라인 구성 전략#

파이프라인 구성 전략은 정책 구성과 프로젝트 파이프라인을 병합하는 방법을 정의합니다. 파이프라인 실행 정책은 .gitlab-ci.yml 파일에 정의된 작업을 격리된 파이프라인에서 실행하며, 이는 대상 프로젝트의 파이프라인에 병합됩니다.

inject_policy 유형#

히스토리

• GitLab 17.9에서 도입.

이 전략은 프로젝트의 원래 CI/CD 구성을 완전히 대체하지 않고 기존 프로젝트 파이프라인에 사용자 정의 CI/CD 구성을 추가합니다. 새로운 보안 스캔, 컴플라이언스 검사 또는 사용자 정의 스크립트를 추가하는 등 추가 단계로 현재 파이프라인을 향상하거나 확장하려는 경우에 적합합니다.

더 이상 사용되지 않는 inject_ci 전략과 달리, inject_policy는 파이프라인에 사용자 정의 정책 스테이지를 주입하여 CI/CD 워크플로우에서 정책 규칙이 적용되는 위치를 더 세밀하게 제어할 수 있습니다.

여러 정책이 활성화된 경우, 이 전략은 각 정책의 모든 작업을 주입합니다.

이 전략을 사용하면 각 파이프라인이 격리된 YAML 구성을 가지므로 프로젝트 CI/CD 구성이 정책 파이프라인에서 정의된 동작을 재정의할 수 없습니다.

.gitlab-ci.yml 파일이 없는 프로젝트의 경우, 이 전략은 .gitlab-ci.yml 파일을 암묵적으로 생성합니다. 실행된 파이프라인에는 파이프라인 실행 정책에 정의된 작업만 포함됩니다.

스테이지 주입#

정책 파이프라인의 스테이지는 일반적인 CI/CD 구성을 따릅니다. 사용자 정의 정책 스테이지 앞뒤에 스테이지를 제공하여 사용자 정의 정책 스테이지가 프로젝트 파이프라인에 주입되는 순서를 정의합니다.

프로젝트 및 정책 파이프라인 스테이지는 방향성 비순환 그래프(DAG)로 표현되며, 여기서 노드는 스테이지이고 엣지는 종속성을 나타냅니다. 파이프라인을 결합할 때 개별 DAG가 하나의 더 큰 DAG로 병합됩니다. 이후 위상 정렬이 수행되어 모든 파이프라인의 스테이지가 실행되어야 하는 순서가 결정됩니다. 이 정렬은 최종 순서에서 모든 종속성이 준수되도록 합니다. 충돌하는 종속성이 있으면 파이프라인 실행이 실패합니다. 종속성을 수정하려면 프로젝트와 정책 전반에 걸쳐 스테이지가 일치하도록 하세요.

스테이지가 정책 파이프라인 구성에 명시적으로 정의되지 않은 경우, 파이프라인은 기본 스테이지 stages: [build, test, deploy]를 사용합니다. 이 스테이지가 포함되었지만 다른 순서로 나열된 경우, 파이프라인은 Cyclic dependencies detected when enforcing policies 오류와 함께 실패합니다.

다음 예시는 이 동작을 보여줍니다. 모든 예시는 다음과 같은 프로젝트 CI/CD 구성을 가정합니다:

# .gitlab-ci.yml
stages: [build, test, deploy]

project-build-job:
  stage: build
  script: ...

project-test-job:
  stage: test
  script: ...

project-deploy-job:
  stage: deploy
  script: ...

예시 1#

# policy-ci.yml
stages: [test, policy-stage, deploy]

policy-job:
  stage: policy-stage
  script: ...

이 예시에서 policy-stage 스테이지는:

• 존재하는 경우 test 스테이지 이후에 주입되어야 합니다.
• 존재하는 경우 deploy 스테이지 이전에 주입되어야 합니다.

결과: 파이프라인에는 다음 스테이지가 포함됩니다: [build, test, policy-stage, deploy].

특수 케이스:

• .gitlab-ci.yml이 스테이지를 [build, deploy, test]로 지정한 경우, 제약 조건을 충족할 수 없으므로 파이프라인이 Cyclic dependencies detected when enforcing policies 오류와 함께 실패합니다. 실패를 수정하려면 정책에 맞게 스테이지를 조정하세요.
• .gitlab-ci.yml이 스테이지를 [build]로 지정한 경우, 결과 파이프라인에는 다음 스테이지가 포함됩니다: [build, policy-stage].

예시 2#

# policy-ci.yml
stages: [policy-stage, deploy]

policy-job:
  stage: policy-stage
  script: ...

이 예시에서 policy-stage 스테이지는:

• 존재하는 경우 deploy 스테이지 이전에 주입되어야 합니다.

결과: 파이프라인에는 다음 스테이지가 포함됩니다: [build, test, policy-stage, deploy].

특수 케이스:

• .gitlab-ci.yml이 스테이지를 [build, deploy, test]로 지정한 경우, 결과 파이프라인 스테이지는 [build, policy-stage, deploy, test]입니다.
• 프로젝트 파이프라인에 deploy 스테이지가 없는 경우, policy-stage 스테이지는 .pipeline-policy-post 바로 앞 파이프라인의 끝에 주입됩니다.

예시 3#

# policy-ci.yml
stages: [test, policy-stage]

policy-job:
  stage: policy-stage
  script: ...

이 예시에서 policy-stage 스테이지는:

• 존재하는 경우 test 스테이지 이후에 주입되어야 합니다.

결과: 파이프라인에는 다음 스테이지가 포함됩니다: [build, test, deploy, policy-stage].

특수 케이스:

• 프로젝트 파이프라인에 test 스테이지가 없는 경우, policy-stage 스테이지는 .pipeline-policy-post 바로 앞 파이프라인의 끝에 주입됩니다.

예시 4#

# policy-ci.yml
stages: [policy-stage]

policy-job:
  stage: policy-stage
  script: ...

이 예시에서 policy-stage 스테이지는 제약 조건이 없습니다.

결과: 파이프라인에는 다음 스테이지가 포함됩니다: [build, test, deploy, policy-stage].

예시 5#

# policy-ci.yml
stages: [check, lint, test, policy-stage, deploy, verify, publish]

policy-job:
  stage: policy-stage
  script: ...

이 예시에서 policy-stage 스테이지는:

• 존재하는 경우 스테이지 check, lint, test 이후에 주입되어야 합니다.
• 존재하는 경우 스테이지 deploy, verify, publish 이전에 주입되어야 합니다.

결과: 파이프라인에는 다음 스테이지가 포함됩니다: [build, test, policy-stage, deploy].

특수 케이스:

• .gitlab-ci.yml이 스테이지를 [check, publish]로 지정한 경우, 결과 파이프라인에는 다음 스테이지가 포함됩니다: [check, policy-stage, publish]

기본 스테이지 순서#

정책에서 스테이지가 정의되지 않은 경우, GitLab은 기본 스테이지 순서를 적용합니다:

• .pre
• build
• test
• deploy
• .post

기본 순서는 이러한 기본 스테이지를 다른 순서로 사용하는 프로젝트와 충돌할 수 있습니다. 예를 들어, stages: [test, build, deploy]에서 build 이전에 test를 사용하는 경우.

순환 종속성 방지#

순환 종속성 오류는 정책의 스테이지 순서가 프로젝트의 스테이지 순서와 충돌할 때 발생합니다. 이러한 오류를 방지하려면:

• 스테이지 순서가 명확하고 프로젝트와 호환되도록 항상 정책에서 스테이지를 명시적으로 정의하세요. 정책이 기본 스테이지 build, test 또는 deploy를 사용하는 경우, 순서가 모든 프로젝트에 적용될 것임을 인식하세요.

• 예약된 스테이지(.pipeline-policy-pre 및 .pipeline-policy-post)만 사용하는 경우, 이 예약된 스테이지는 항상 파이프라인의 시작과 끝에 배치되므로 정책에서 기본 스테이지를 정의할 필요가 없습니다.

이 지침을 따르면 다른 스테이지 구성을 가진 프로젝트에서 안정적으로 작동하는 정책을 만들 수 있습니다.

inject_ci (더 이상 사용되지 않음)#

이 전략은 프로젝트의 원래 CI/CD 구성을 완전히 대체하지 않고 기존 프로젝트 파이프라인에 사용자 정의 CI/CD 구성을 추가합니다. 새로운 보안 스캔, 컴플라이언스 검사 또는 사용자 정의 스크립트를 추가하는 등 추가 단계로 현재 파이프라인을 향상하거나 확장하려는 경우에 적합합니다.

여러 정책이 활성화된 경우 모든 작업이 추가적으로 주입됩니다.

이 전략을 사용하면 각 파이프라인이 격리된 YAML 구성을 가지므로 프로젝트 CI/CD 구성이 정책 파이프라인에서 정의된 동작을 재정의할 수 없습니다.

.gitlab-ci.yml 파일이 없는 프로젝트의 경우, 이 전략은 .gitlab-ci.yml 파일을 암묵적으로 생성합니다. 이를 통해 파이프라인 실행 정책에 정의된 작업만 포함된 파이프라인이 실행될 수 있습니다.

override_project_ci#

히스토리

• 워크플로우 규칙 처리가 업데이트됨:

GitLab 17.8에서 policies_always_override_project_ci 플래그와 함께 도입. 기본적으로 활성화됨.

• GitLab 17.10에서 일반적으로 사용 가능. 기능 플래그 policies_always_override_project_ci 제거됨.
• GitLab 17.9에서 스캔 실행 정책이 파이프라인 실행 정책과 함께 실행될 수 있도록 override_project_ci 처리가 변경됨.

이 전략은 파이프라인 실행 정책에서 정의된 새로운 구성으로 프로젝트의 기존 CI/CD 구성을 대체합니다. 이 전략은 고도로 규제된 산업에서 조직 전체 CI/CD 표준 또는 컴플라이언스 요구사항을 적용하려는 경우처럼 전체 파이프라인을 표준화하거나 대체해야 할 때 이상적입니다. 파이프라인 구성을 재정의하려면 CI/CD 작업을 정의하고 include:project를 사용하지 마세요.

이 전략은 inject_ci 또는 inject_policy 전략을 사용하는 다른 정책보다 우선합니다. override_project_ci가 있는 정책이 적용되면 프로젝트 CI/CD 구성이 무시됩니다. 그러나 다른 보안 정책 구성은 재정의되지 않습니다.

파이프라인 실행 정책에서 스캔 실행 정책과 함께 override_project_ci를 사용하면, CI/CD 구성이 병합되고 두 정책이 결과 파이프라인에 적용됩니다.

또는 재정의하는 대신 프로젝트의 .gitlab-ci.yml로 프로젝트 CI/CD 구성을 병합할 수 있습니다. 구성을 병합하려면 include:project를 사용하세요. 이 전략을 통해 사용자는 파이프라인 실행 정책 구성에 프로젝트 CI/CD 구성을 포함시켜 정책 작업을 사용자 정의할 수 있습니다. 예를 들어, 정책과 프로젝트 CI/CD 구성을 하나의 YAML 파일로 결합하여 before_script 구성을 재정의하거나 스캔할 컨테이너 경로를 정의하는 CS_IMAGE와 같은 필수 변수를 정의할 수 있습니다. 이 동작의 짧은 데모를 참조하세요.

파이프라인 이름#

override_project_ci 전략을 사용하는 파이프라인 실행 정책은 프로젝트의 원래 CI/CD 구성에 정의된 파이프라인 이름을 재정의합니다.

파이프라인 실행 정책 구성에서 파이프라인 이름을 정의할 수 있습니다.

override_project_ci 전략을 사용하는 파이프라인 실행 정책이 여러 개인 경우, 그룹 계층 구조에서 가장 낮은 것이 적용됩니다. 예를 들어, 프로젝트에 대한 정책은 프로젝트가 속한 그룹에 대한 정책을 재정의합니다. 하위 그룹에 대한 정책은 하위 그룹이 속한 그룹에 대한 정책보다 우선합니다.

파이프라인 실행 정책 구성에 프로젝트의 CI/CD 구성 포함#

override_project_ci 전략을 사용할 때, 프로젝트 구성을 파이프라인 실행 정책 구성에 포함할 수 있습니다:

include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
    rules:
      - exists:
          paths:
            - '$CI_CONFIG_PATH'
          project: '$CI_PROJECT_PATH'
          ref: '$CI_COMMIT_SHA'

compliance_job:
 ...

CI/CD 변수#

기본적으로 파이프라인 실행 정책은 격리된 환경에서 실행되므로 정책 외부에서 정의된 변수를 적용하지 않습니다.

variables_override 설정을 활성화하면, 파이프라인 실행 정책이 다음과 같은 사용자 정의 변수에 액세스할 수 있습니다:

• 그룹 CI/CD 설정의 변수.
• 프로젝트 CI/CD 설정의 변수.
• 새 파이프라인을 실행할 때 사용자가 지정한 변수.

그러나 variables_override 설정이 활성화된 경우에도 파이프라인 실행 정책은 다음 유형의 변수에 액세스할 수 없습니다:

• 다른 정책에서 정의된 변수.
• 프로젝트의 .gitlab-ci.yml 파일에 정의된 변수.

활성화된 경우, variables_override 설정은 표준 CI/CD 변수 우선순위 규칙에 따라 정책이 변수에 액세스하고 적용하도록 합니다.

그러나 파이프라인 실행 정책을 사용할 때 우선순위 규칙은 파이프라인 실행 정책 전략에 따라 달라질 수 있어 더 복잡합니다:

• inject_policy 전략: 변수가 파이프라인 실행 정책에 정의된 경우, 작업은 항상 이 값을 사용합니다. 변수가 파이프라인 실행 정책에 정의되지 않은 경우, 작업은 그룹 또는 프로젝트 설정의 값을 적용합니다.
• inject_ci 전략: 변수가 파이프라인 실행 정책에 정의된 경우, 작업은 항상 이 값을 사용합니다. 변수가 파이프라인 실행 정책에 정의되지 않은 경우, 작업은 그룹 또는 프로젝트 설정의 값을 적용합니다.
• override_project_ci 전략: 결과 파이프라인의 모든 작업은 정책 작업으로 처리됩니다. 정책에 정의된 변수(포함된 파일의 변수 포함)는 프로젝트 및 그룹 변수보다 우선합니다. 즉, 포함된 프로젝트의 CI/CD 구성에서 작업의 변수는 프로젝트 및 그룹 설정에 정의된 변수보다 우선합니다.

파이프라인 실행 정책의 변수에 대한 자세한 내용은 파이프라인 실행 정책의 변수 우선순위를 참조하세요.

UI에서 프로젝트 또는 그룹 변수를 정의할 수 있습니다.

파이프라인 실행 정책의 변수 우선순위#

파이프라인 실행 정책, 특히 override_project_ci 전략을 사용할 때, 여러 위치에서 정의된 변수 값의 우선순위는 표준 GitLab CI/CD 파이프라인과 다를 수 있습니다. 이해해야 할 몇 가지 중요한 포인트:

• override_project_ci를 사용할 때 결과 파이프라인의 모든 작업은 포함된 프로젝트의 CI/CD 구성에서 가져온 작업을 포함하여 정책 작업으로 간주됩니다.
• 정책 파이프라인에서 정의된 변수(전체 인스턴스 또는 작업용)는 프로젝트 또는 그룹 설정에 정의된 변수보다 우선합니다.
• 이 동작은 프로젝트의 CI/CD 구성 파일(.gitlab-ci.yml)에서 포함된 작업을 포함한 모든 작업에 적용됩니다.

예시#

프로젝트의 CI/CD 구성의 변수와 포함된 .gitlab-ci.yml 파일에 정의된 작업 변수가 같은 이름인 경우, override_project_ci를 사용할 때 작업 변수가 우선합니다.

프로젝트의 CI/CD 설정에서 MY_VAR 변수가 정의됩니다:

• Key: MY_VAR
• Value: Project configuration variable value

포함된 프로젝트의 .gitlab-ci.yml에서 동일한 변수가 정의됩니다:

project-job:
  variables:
    MY_VAR: "Project job variable value"
  script:
    - echo $MY_VAR  # This will output "Project job variable value"

이 경우 작업 변수 값 Project job variable value가 우선합니다.

수동으로 실행된 파이프라인에서 변수 미리 채우기#

히스토리

• GitLab 18.5에서 도입.

description, value 및 options 키워드를 사용하여 사용자가 파이프라인을 수동으로 실행할 때 미리 채워지는 CI/CD 변수를 정의할 수 있습니다. description을 사용하여 변수의 용도와 허용 가능한 값과 같은 관련 정보를 제공하세요.

작업별 변수는 미리 채울 수 없습니다.

수동으로 트리거된 파이프라인에서, 새 파이프라인 페이지에는 적용 가능한 모든 정책의 CI/CD 구성에 description이 정의된 모든 파이프라인 변수가 표시됩니다.

미리 채워진 변수는 variables_override를 사용하여 허용으로 구성해야 합니다. 그렇지 않으면 파이프라인을 수동으로 트리거할 때 사용된 값이 무시됩니다.

파이프라인 실행 정책 다시 만들기#

파이프라인 실행 정책을 다시 만들려면:

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 보안 > 정책을 선택합니다.
3. 다시 만들 파이프라인 실행 정책을 선택합니다.
4. 오른쪽 사이드바에서 YAML 탭을 선택하고 전체 정책 파일의 내용을 복사합니다.
5. 정책 테이블 옆의 세로 줄임표( ellipsis_v )를 선택하고 삭제를 선택합니다.
6. 생성된 머지 요청을 병합합니다.
7. 보안 > 정책으로 돌아가 새 정책을 선택합니다.
8. 파이프라인 실행 정책 섹션에서 정책 선택을 선택합니다.
9. .yaml 모드에서 이전 정책의 내용을 붙여넣습니다.
10. 머지 요청을 통해 업데이트를 선택하고 생성된 머지 요청을 병합합니다.

보안 중요 정책 실행 보장#

보안 및 컴플라이언스 목적으로 파이프라인 실행 정책을 구현할 때, 정책을 우회하거나 침해할 수 없도록 하려면 다음 모범 사례를 고려하세요.

변경 방지: 보안 중요 작업에 대한 규칙#

보안 중요 파이프라인 정책에서는 changes: 규칙을 사용하지 마세요. 이는 브랜치 파이프라인에서 예상치 못한 결과를 생성할 수 있습니다. changes: 키워드는 SHA 기반 diff에 의존하며, git commit --amend 이후 강제 푸시와 같은 특정 시나리오에서 우회될 수 있습니다.

git commit --amend 이후 강제 푸시를 사용할 때, GitLab은 변경된 파일을 다르게 계산합니다:

• 첫 번째 푸시 (표준 커밋):

  GitLab은 새 커밋을 부모와 비교합니다.

  • GitLab은 대상 파일이 변경된 것을 감지합니다.
  • changes: [filename] 규칙이 올바르게 트리거됩니다.

• 두 번째 푸시 (--force를 사용한 수정된 커밋):

  수정된 커밋은 새 SHA로 이전 커밋을 완전히 대체합니다.

  • GitLab은 브랜치의 이전 커밋과 비교하는 git diff HEAD~를 사용하여 변경 사항을 계산합니다.
  • 해당 브랜치의 이전 커밋에도 동일한 파일 변경 사항이 있었으므로 diff는 새 변경 사항이 없음을 표시합니다.
  • changes: 규칙이 트리거되지 않습니다.

대신 우회할 수 없는 조건을 사용하세요:

check-critical-files:
  stage: .pipeline-policy-pre
  script:
    - |
      # Check if critical files differ from the target branch
      if git diff origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME --name-only | grep -q "Makefile\|\.gitlab-ci\.yml"; then
        echo "Critical files have been modified"
        exit 1
      fi
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always

또는 changes: 조건 없이 모든 파이프라인에서 정책 검사를 실행하세요:

security-check:
  stage: .pipeline-policy-pre
  script:
    - echo "Running security checks"
    - ./run-security-checks.sh
  rules:
    - when: always

changes: 동작에 대한 자세한 내용은 changes를 사용할 때 예상치 못하게 실행되는 작업 또는 파이프라인을 참조하세요.

중요 보안 검사에 .pipeline-policy-pre 스테이지 사용#

.pipeline-policy-pre 스테이지의 작업은 보안 및 컴플라이언스 사용 사례를 위해 설계되었습니다. 이 스테이지가 완료될 때까지 다른 모든 파이프라인 작업이 대기합니다. .pipeline-policy-pre 스테이지가 실패하면 이후의 모든 작업이 건너뛰어집니다.

중복 보안 구성 감지#

.pipeline-policy-pre를 사용하여 기존 보안 구성을 확인하고 지침을 제공하는 사용자 정의 검증 작업을 만들 수 있습니다. 예를 들어, 파이프라인 실행 정책으로 조직 전체에 보안 스캔을 적용하면서 일부 프로젝트에는 이미 자체 보안 스캔 구현이 있는 경우, .pipeline-policy-pre를 사용하여 중복된 스캔을 식별할 수 있습니다.

정책 CI/CD 구성 예시:

# policy-ci.yml
check-duplicate-scans:
  stage: .pipeline-policy-pre
  script:
    - |
      echo "Checking for duplicate security scan configurations..."
      if [ -f ".gitlab-ci.yml" ]; then
        if grep -q "secret_detection:" .gitlab-ci.yml || \
           grep -q "sast:" .gitlab-ci.yml || \
           grep -q "dependency_scanning:" .gitlab-ci.yml || \
           grep -q "container_scanning:" .gitlab-ci.yml; then
          echo "WARNING: Duplicate security scans detected."
          echo ""
          echo "This project has security scans defined in .gitlab-ci.yml"
          echo "that might duplicate the scans enforced by pipeline execution policies."
          echo ""
          echo "To avoid redundant scans and reduce pipeline time:"
          echo "1. Review your .gitlab-ci.yml for security scanning jobs."
          echo "2. Remove duplicate jobs (secret_detection, sast, dependency_scanning, and so on)."
          echo "3. The pipeline execution policy ensures these scans still run."
          echo ""
          echo "For questions, contact your security team."
        else
          echo "No duplicate security scans detected."
        fi
      fi
  allow_failure: true
  rules:
    - when: always

이 구성은:

• 파이프라인을 차단하지 않고 잠재적 중복 구성을 감지합니다.
• 개발 팀에 실행 가능한 지침을 제공합니다.
• 정리가 필요한 프로젝트에 대한 가시성을 유지합니다.
• 의도하지 않은 결과를 초래할 수 있는 작업 자동 제거의 복잡성을 방지합니다.

이 예시를 확장하여 다른 구성 문제를 확인하거나 프로젝트 전반에 걸쳐 컴플라이언스를 추적하는 보안 팀용 보고서를 생성할 수 있습니다.

변수 재정의 제어#

variables_override 구성을 사용하여 사용자가 보안 스캔을 비활성화하거나 중요 보안 구성을 수정하여 중요 보안 변수를 재정의하는 것을 방지하세요.

variables_override:
  allowed: false
  exceptions:
    - CS_IMAGE  # Allow customization of container image only

보안 작업 명명#

충돌을 방지하고 작업이 보안 적용임을 사용자에게 명확히 하기 위해 접두사를 사용하여 고유하고 설명적인 작업 이름을 사용하세요:

# Good: Clear security policy job name
security-policy:sast-scan:
  stage: .pipeline-policy-pre
  script: ...

# Avoid: Generic name that could conflict
sast:
  stage: .pipeline-policy-pre
  script: ...

[no_pipeline]과의 동작#

기본적으로 사용자는 일반 파이프라인 생성을 방지하기 위해 푸시 옵션에서 [no_pipeline]을 사용하여 보호된 브랜치에 커밋을 푸시할 수 있습니다. 그러나 파이프라인 실행 정책으로 정의된 작업은 정책이 [no_pipeline] 지시문을 무시하므로 항상 트리거됩니다. 이를 통해 개발자가 정책에 정의된 작업 실행을 건너뛰는 것을 방지하여 중요한 보안 및 컴플라이언스 검사가 항상 수행되도록 합니다.

[no_pipeline] 동작에 대한 더 유연한 제어는 no_pipeline 유형 섹션을 참조하세요.

[skip ci]와의 동작#

기본적으로 사용자는 일반 파이프라인 트리거를 방지하기 위해 커밋 메시지에 [skip ci]를 사용하여 보호된 브랜치에 커밋을 푸시할 수 있습니다. 그러나 파이프라인 실행 정책으로 정의된 작업은 정책이 [skip ci] 지시문을 무시하므로 항상 트리거됩니다. 이를 통해 개발자가 정책에 정의된 작업 실행을 건너뛰는 것을 방지하여 중요한 보안 및 컴플라이언스 검사가 항상 수행되도록 합니다.

[skip ci] 동작에 대한 더 유연한 제어는 skip_ci 유형 섹션을 참조하세요.

예시#

이 예시는 파이프라인 실행 정책으로 달성할 수 있는 것을 보여줍니다.

파이프라인 실행 정책#

보안 정책 프로젝트에 저장된 .gitlab/security-policies/policy.yml 파일에서 다음 예시를 사용할 수 있습니다:

---
pipeline_execution_policy:
- name: My pipeline execution policy
  description: Enforces CI/CD jobs
  enabled: true
  pipeline_config_strategy: override_project_ci
  content:
    include:
    - project: my-group/pipeline-execution-ci-project
      file: policy-ci.yml
      ref: main # optional
  policy_scope:
    projects:
      including:
      - id: 361

프로젝트 변수를 기반으로 적용된 작업 사용자 정의#

파이프라인 실행 정책은 프로젝트별 변수를 기반으로 동작을 조정합니다. 개별 프로젝트가 적용된 작업의 특정 측면을 사용자 정의할 수 있도록 허용하면서 합리적인 기본값을 제공하는 유연한 정책을 만들 수 있습니다.

변수 평가#

파이프라인 실행 정책의 규칙(예: if: $PROJECT_CS_IMAGE)은 프로젝트 컨텍스트가 아니라 정책 실행 중에 평가됩니다. 즉:

• 프로젝트 변수는 표준 이름(예: $PROJECT_CS_IMAGE)을 사용하여 정책에서 사용 가능합니다.
• 프로젝트 변수는 정책에 정의된 변수보다 우선할 수 있습니다.
• 어떤 변수를 사용할지에 대한 평가는 GitLab이 정책 파이프라인을 구성할 때 발생합니다.

변수 명명 패턴#

사용자 정의 가능한 정책을 만들 때, 다음과 같은 명명 규칙을 따르세요:

• 정책 변수: 기본값에 표준 이름(예: CS_IMAGE)을 사용하세요.
• 프로젝트 재정의 변수: 목적을 명확히 나타내는 설명적인 접두사(예: PROJECT_CS_IMAGE)를 사용하세요.

이 패턴은 명명 충돌을 방지하고 의도를 명확히 합니다.

예시: 사용자 정의 이미지가 있는 컨테이너 스캔#

이 예시는 기본 컨테이너 이미지를 사용하지만 프로젝트가 자체 이미지를 지정할 수 있도록 하는 정책을 만드는 방법을 보여줍니다:

variables:
  CS_ANALYZER_IMAGE: "$CI_TEMPLATE_REGISTRY_HOST/security-products/container-scanning:8"
  CS_IMAGE: alpine:latest  # Default fallback value

policy::container-security:
  stage: .pipeline-policy-pre
  rules:
    - if: $PROJECT_CS_IMAGE  # Check if project defined a custom image
      variables:
        CS_IMAGE: $PROJECT_CS_IMAGE  # Use project's custom image
    - when: always  # Always run the job (with default or custom image)
  script:
    - echo "CS_ANALYZER_IMAGE:$CS_ANALYZER_IMAGE"
    - echo "CS_IMAGE:$CS_IMAGE"

작동 방식:

• 기본 동작: 프로젝트에 PROJECT_CS_IMAGE가 정의되지 않은 경우, CS_IMAGE는 alpine:latest로 유지됩니다.
• 사용자 정의 동작: 프로젝트가 PROJECT_CS_IMAGE를 정의하면 해당 값이 CS_IMAGE를 재정의합니다.
• 규칙 평가: if: $PROJECT_CS_IMAGE 조건은 정책 컨텍스트에서 평가되며 프로젝트 변수에 액세스할 수 있습니다.
• 변수 우선순위: 정책의 변수 할당이 기본값보다 우선합니다.

컨테이너 이미지를 사용자 정의하려면 프로젝트는 .gitlab-ci.yml 파일에서 지정하는 것이 아니라 프로젝트 변수로 PROJECT_CS_IMAGE를 정의해야 합니다.

변수 고려사항 요약#

변수 소스:

• 프로젝트 변수는 .gitlab-ci.yml이 아닌 프로젝트의 CI/CD 설정에서 정의되어야 합니다.
• 정책은 표준 이름을 사용하여 그룹 변수와 인스턴스 변수에도 액세스할 수 있습니다.
• 정책 변수는 같은 이름으로 모두 정의된 경우 프로젝트 변수보다 우선합니다.

규칙 평가:

• 파이프라인 실행 정책의 모든 rules: 조건은 정책이 실행될 때 평가됩니다. 즉, 정책이 프로젝트별 변수에 액세스하고 반응할 수 있습니다.
• 평가는 파이프라인 구성 중, 작업이 실행되기 전에 발생합니다.

모범 사례:

• 프로젝트 재정의에 설명적인 변수 이름과 접두사(예: PROJECT_*)를 사용하세요.
• 항상 정책에서 합리적인 기본값을 제공하세요.
• 사용자를 위해 사용 가능한 사용자 정의 변수를 문서화하세요.

.gitlab-ci.yml과 아티팩트를 사용하여 적용된 작업 사용자 정의#

정책 파이프라인은 격리된 환경에서 실행되므로 파이프라인 실행 정책은 .gitlab-ci.yml에서 직접 변수를 읽을 수 없습니다. 프로젝트의 CI/CD 설정에서 정의하는 대신 .gitlab-ci.yml의 변수를 사용하려면, 아티팩트를 사용하여 .gitlab-ci.yml 구성에서 파이프라인 실행 정책의 파이프라인으로 변수를 전달할 수 있습니다.

# .gitlab-ci.yml

build-job:
  stage: build
  script:
    - echo "BUILD_VARIABLE=value_from_build_job" >> build.env
  artifacts:
    reports:
      dotenv: build.env

stages:
- build
- test

test-job:
  stage: test
  script:
    - echo "$BUILD_VARIABLE"  # Prints "value_from_build_job"

프로젝트 구성에서 before_script로 보안 스캐너 동작 사용자 정의#

정책에서 적용된 보안 작업의 동작을 프로젝트의 .gitlab-ci.yml에서 사용자 정의하려면 before_script를 재정의할 수 있습니다. 이를 위해 정책에서 override_project_ci 전략을 사용하고 프로젝트의 CI/CD 구성을 포함하세요. 파이프라인 실행 정책 구성 예시:

# policy.yml
type: pipeline_execution_policy
name: Secret detection
description: >
  This policy enforces secret detection and allows projects to override the
  behavior of the scanner.
enabled: true
pipeline_config_strategy: override_project_ci
content:
  include:
    - project: gitlab-org/pipeline-execution-policies/compliance-project
      file: secret-detection.yml

# secret-detection.yml
include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
  - template: Jobs/Secret-Detection.gitlab-ci.yml

프로젝트의 .gitlab-ci.yml에서 스캐너에 대한 before_script를 정의할 수 있습니다:

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  before_script:
    - echo "Before secret detection"

override_project_ci를 사용하고 프로젝트의 구성을 포함하면 YAML 구성이 병합될 수 있습니다.

리소스별 변수 제어 구성#

팀이 작업별 재정의를 허용하면서 파이프라인 실행 정책 변수를 재정의할 수 있는 전역 변수를 설정하도록 허용할 수 있습니다. 이를 통해 팀이 보안 스캔에 적절한 기본값을 설정하면서도 다른 작업에 적절한 리소스를 사용할 수 있습니다.

resource-optimized-scans.yml에 포함:

variables:
  # Default resource settings for all jobs
  KUBERNETES_MEMORY_REQUEST: 4Gi
  KUBERNETES_MEMORY_LIMIT: 4Gi
  # Default values that teams can override via project variables
  SAST_KUBERNETES_MEMORY_REQUEST: 4Gi

sast:
  variables:
    SAST_EXCLUDED_ANALYZERS: 'spotbugs'
    KUBERNETES_MEMORY_REQUEST: $SAST_KUBERNETES_MEMORY_REQUEST
    KUBERNETES_MEMORY_LIMIT: $SAST_KUBERNETES_MEMORY_REQUEST

policy.yml에 포함:

pipeline_execution_policy:
- name: Resource-Optimized Security Policy
  description: Enforces security scans with efficient resource management
  enabled: true
  pipeline_config_strategy: inject_ci
  content:
    include:
    - project: security/policy-templates
      file: resource-optimized-scans.yml
      ref: main

  variables_override:
    allowed: false
    exceptions:
      # Allow scan-specific resource overrides
      - SAST_KUBERNETES_MEMORY_REQUEST
      - SECRET_DETECTION_KUBERNETES_MEMORY_REQUEST
      - CS_KUBERNETES_MEMORY_REQUEST
      # Allow necessary scan customization
      - CS_IMAGE
      - SAST_EXCLUDED_PATHS

이 접근 방식은 팀이 파이프라인의 모든 작업에 영향을 미치지 않고 변수 재정의를 사용하여 스캔별 리소스 변수(예: SAST_KUBERNETES_MEMORY_REQUEST)를 설정할 수 있도록 하여 대규모 프로젝트에 더 나은 리소스 관리를 제공합니다. 이 예시는 개발자에게 제공할 수 있는 다른 일반적인 스캔 사용자 정의 옵션도 보여줍니다. 개발 팀이 활용할 수 있도록 사용 가능한 변수를 문서화하세요.

파이프라인 실행 정책에서 그룹 또는 프로젝트 변수 사용#

파이프라인 실행 정책에서 그룹 또는 프로젝트 변수를 사용할 수 있습니다.

PROJECT_VAR="I'm a project" 프로젝트 변수를 사용하면 다음 파이프라인 실행 정책 작업의 결과는 I'm a project입니다.

pipeline execution policy job:
    stage: .pipeline-policy-pre
    script:
    - echo "$PROJECT_VAR"

파이프라인 실행 정책에 프로젝트 구성의 변수 포함#

파이프라인 실행 정책은 자체 격리된 컨텍스트에서 실행되므로 프로젝트의 .gitlab-ci.yml 파일에 정의된 변수는 정책 작업에 자동으로 사용할 수 없습니다. 그러나 프로젝트의 별도 변수 파일을 참조하여 프로젝트에서 정의된 변수를 포함할 수 있습니다.

다음의 경우에 이 방법을 사용하세요:

• Docker 컨테이너에 사용자 정의 명명 규칙을 사용해야 하는 경우.
• 정책이 준수해야 하는 프로젝트별 구성을 유지 관리하려는 경우.
• 동일한 프로젝트에서 빌드된 다른 이름의 여러 컨테이너가 있는 경우.

예시: 프로젝트 변수 파일 포함#

프로젝트 저장소에 변수 파일을 만드세요(예: gitlab-variables.yml):

# gitlab-variables.yml
variables:
  DOCKER_TLS_CERTDIR: "/certs"
  CS_IMAGE: ${CI_REGISTRY_IMAGE}:build
  CUSTOM_VARIABLE: "custom-value"

파이프라인 실행 정책 구성에서 이 변수 파일을 포함하세요:

# Pipeline execution policy configuration
include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: 'gitlab-variables.yml'
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  stage: test
  before_script:
    - echo "CS_IMAGE = $CS_IMAGE"
    - echo "CUSTOM_VARIABLE = $CUSTOM_VARIABLE"

이 구성은:

• 스캔되는 프로젝트에서 gitlab-variables.yml 파일을 포함합니다.
• 해당 파일에 정의된 변수를 정책 작업에 사용 가능하게 만듭니다.
• 각 프로젝트가 일관된 정책 구조를 유지하면서 자체 변수 값을 정의할 수 있도록 합니다.

중요 고려사항#

• 변수 우선순위: 프로젝트 파일에서 포함된 변수는 파이프라인 실행 정책의 표준 변수 우선순위 규칙을 따릅니다.
• 파일 위치: 변수 파일은 프로젝트 저장소 어디에든 위치할 수 있습니다. 찾고 유지 관리하기 쉽도록 설명적인 이름과 위치를 사용하세요.
• 전체 CI/CD 구성 포함 방지: 이 방법을 사용할 때는 전체 .gitlab-ci.yml이 아닌 변수 파일만 포함하세요. 전체 CI/CD 구성을 포함하면 작업이 중복될 수 있습니다.
• 보안: 변수 파일에 민감한 정보를 저장하지 마세요. 민감한 데이터에는 프로젝트 또는 그룹 설정에서 정의된 CI/CD 변수를 사용하세요.

대안: 프로젝트 CI/CD 설정 사용#

동적으로 설정된 변수가 필요하지 않은 경우, 별도 파일을 사용하는 대신 프로젝트의 CI/CD 설정(설정 > CI/CD > 변수)에서 상수를 설정할 수 있습니다. 이 변수는 추가 구성 없이 파이프라인 실행 정책 작업에 자동으로 사용 가능합니다.

파이프라인 실행 정책을 사용하여 변수 값 적용#

파이프라인 실행 정책에서 정의된 변수의 값은 같은 이름을 가진 그룹 또는 정책 변수의 값을 재정의합니다. 이 예시에서 변수 PROJECT_VAR의 프로젝트 값은 덮어쓰여지고 작업 결과는 I'm a pipeline execution policy가 됩니다.

variables:
  PROJECT_VAR: "I'm a pipeline execution policy"

pipeline execution policy job:
    stage: .pipeline-policy-pre
    script:
    - echo "$PROJECT_VAR"

보안 정책 범위가 있는 example policy.yml#

이 예시에서 보안 정책의 policy_scope는:

• ID가 9인 컴플라이언스 프레임워크가 적용된 모든 프로젝트를 포함합니다.
• ID가 456인 프로젝트를 제외합니다.

pipeline_execution_policy:
- name: Pipeline execution policy
  description: ''
  enabled: true
  pipeline_config_strategy: inject_policy
  content:
    include:
    - project: my-group/pipeline-execution-ci-project
      file: policy-ci.yml
  policy_scope:
    compliance_frameworks:
    - id: 9
    projects:
      excluding:
      - id: 456

파이프라인 실행 정책에서 ci_skip 구성#

다음 예시에서 파이프라인 실행 정책이 적용되고, ID가 75인 사용자를 제외하고 CI 건너뛰기가 허용되지 않습니다.

pipeline_execution_policy:
  - name: My pipeline execution policy with ci.skip exceptions
    description: 'Enforces CI/CD jobs'
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: group-a/project1
          file: README.md
    skip_ci:
      allowed: false
      allowlist:
        users:
          - id: 75

파이프라인 실행 정책에서 ci_no_pipeline 구성#

다음 예시에서 파이프라인 실행 정책이 적용되고, ID가 75인 사용자를 제외하고 CI 미생성이 허용되지 않습니다.

pipeline_execution_policy:
  - name: My pipeline execution policy with ci.no_pipeline exceptions
    description: 'Enforces CI/CD jobs'
    enabled: true
    pipeline_config_strategy: inject_policy
    content:
      include:
        - project: group-a/project1
          file: README.md
    no_pipeline:
      allowed: false
      allowlist:
        users:
          - id: 75

exists 조건 구성#

exists 규칙을 사용하여 특정 파일이 존재할 때 프로젝트의 CI/CD 구성 파일을 포함하도록 파이프라인 실행 정책을 구성하세요.

다음 예시에서 파이프라인 실행 정책은 Dockerfile이 존재하는 경우 프로젝트의 CI/CD 구성을 포함합니다. exists 규칙은 project로 '$CI_PROJECT_PATH'를 사용하도록 설정해야 합니다. 그렇지 않으면 GitLab이 보안 정책 CI/CD 구성을 보유하는 프로젝트에서 파일이 존재하는지 평가합니다.

include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH
    rules:
      - exists:
          paths:
            - 'Dockerfile'
          project: '$CI_PROJECT_PATH'

이 방법을 사용하려면 그룹 또는 프로젝트가 override_project_ci 전략을 사용해야 합니다.

CI_JOB_TOKEN으로 파이프라인 스테이지 및 작업 검증#

.pipeline-policy-pre 작업에서 CI_JOB_TOKEN을 사용하여 GitLab API를 호출하고 파이프라인 스테이지와 작업이 승인된 스테이지 또는 작업 목록에 있는지 검증할 수 있습니다. 이 패턴은 프로젝트가 승인되지 않은 CI/CD 스테이지 및 작업을 사용하는 것을 방지하려는 경우에 유용합니다.

다음 예시 스크립트는 API에서 파이프라인의 작업을 가져오고, 고유한 스테이지와 작업 이름을 추출하여 각각을 APPROVED_STAGES 및 APPROVED_JOBS 변수와 비교합니다. 승인되지 않은 스테이지 또는 작업이 발견되면 다른 작업이 실행되기 전에 파이프라인이 실패합니다.

APPROVED_STAGES와 APPROVED_JOBS를 프로젝트, 그룹 또는 정책 구성에서 CI/CD 변수로 정의하세요.

validate-pipeline:
  stage: .pipeline-policy-pre
  image: alpine:latest
  before_script:
    - apk add --no-cache curl jq bash
  script:
    - |
      #!/bin/bash

      echo "Checking pipeline stages and jobs..."

      # Fetch pipeline jobs using CI_JOB_TOKEN
      api_url="$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs"
      echo "API URL: $api_url"

      jobs=$(curl --silent --header "JOB-TOKEN: $CI_JOB_TOKEN" "$api_url")
      echo "Fetched Jobs: $jobs"

      if [[ "$jobs" == *"404 Project Not Found"* ]]; then
        echo "Failed to authenticate with GitLab API: Project not found"
        exit 1
      fi

      # Extract stages and jobs
      pipeline_stages=$(echo "$jobs" | jq -r '.[].stage' | sort | uniq | tr '\n' ',')
      pipeline_jobs=$(echo "$jobs" | jq -r '.[].name' | sort | uniq | tr '\n' ',')

      echo "Pipeline Stages: $pipeline_stages"
      echo "Pipeline Jobs: $pipeline_jobs"

      # Check if pipeline stages are approved
      for stage in $(echo $pipeline_stages | tr ',' ' '); do
        echo "Checking stage: $stage"
        if ! [[ ",$APPROVED_STAGES," =~ ",$stage," ]]; then
          echo "Stage $stage is not approved."
          exit 1
        fi
      done

      # Check if pipeline jobs are approved
      for job in $(echo $pipeline_jobs | tr ',' ' '); do
        echo "Checking job: $job"
        if ! [[ ",$APPROVED_JOBS," =~ ",$job," ]]; then
          echo "Job $job is not approved."
          exit 1
        fi
      done

파이프라인 실행 정책을 사용하여 컨테이너 스캔 컴포넌트 적용#

보안 스캔 컴포넌트를 사용하여 버전 관리 처리 및 적용을 개선할 수 있습니다.

include:
  - component: gitlab.com/components/container-scanning/container-scanning@main
    inputs:
      cs_image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

container_scanning:  # override component with additional configuration
  variables:
    CS_REGISTRY_USER: $CI_REGISTRY_USER
    CS_REGISTRY_PASSWORD: $CI_REGISTRY_PASSWORD
    SECURE_LOG_LEVEL: debug  # add for verbose debugging of the container scanner
  before_script:
  - echo $CS_IMAGE  # optionally add a before_script for additional debugging