- 작업
- 스캔 실행 정책 편집기
- 스캔 실행 정책 스키마
- 스캔 실행 정책 스키마
파이프라인
규칙 유형-
schedule
rule type scan
액션 유형- 보안 정책 범위
- 보안 정책 예시 프로젝트
- 스캔 실행 정책 에디터 예시
- 중복 스캔 방지
- 실험적 기능
스캔 실행 정책
- 그룹 수준 보안 정책은 GitLab 15.2에서 소개되었습니다.
- 그룹 수준 보안 정책은 GitLab 15.4에서 GitLab.com에서 활성화되었습니다.
- 운영 컨테이너 스캔은 GitLab 15.5에서 도입되었습니다.
- 스캔 실행 정책 편집기에서 사용자 정의 CI 변수를 지원 도입되었습니다 in GitLab 16.2.
- 기존 GitLab CI/CD 구성이 있는 프로젝트에서 스캔 실행 정책을 강제로 적용 도입되었습니다 in GitLab 16.2 특징 플래그인
scan_execution_policy_pipelines
와 함께. 특징 플래그scan_execution_policy_pipelines
가 GitLab 16.5에서 제거되었습니다.- 스캔 실행 정책에서 사전 정의된 변수 무시 도입되었습니다 in GitLab 16.10 특징 플래그인
allow_restricted_variables_at_policy_level
와 함께. 기본적으로 활성화됨.
보안 스캔을 강제로 실행 정책을 사용하여 파이프라인의 일부로 또는 지정된 일정에 보안 스캔을 실행합니다. 보안 스캔은 그룹 또는 하위 그룹 수준에서 정책을 정의하는 경우 프로젝트 파이프라인에서 여러 번 실행됩니다.
스캔 실행 정책은 모든 해당 프로젝트에 대해 강제로 적용됩니다. .gitlab-ci.yml
파일이 없는 프로젝트이거나 AutoDevOps가 비활성화된 경우에도 보안 정책은 암시적으로 .gitlab-ci.yml
파일을 생성합니다. 이는 프로젝트에서 빌드가 필요하지 않은 시크릿 감지, 정적 분석 또는 다른 스캐너의 실행을 가능하게 합니다.
이 기능은 컴플라이언스 프레임워크 파이프라인과 겹치는 부분이 있습니다. 두 기능에 대한 사용자 경험을 통합하지 않았기 때문에 두 기능간의 유사성과 차이에 대한 자세한 내용은 확인하세요.
- 비디오 안내는 GitLab에서 보안 스캔 정책 설정하는 방법을 참조하십시오.
- 개요는 GitLab CI/CD 구성 없이 프로젝트에 스캔 실행 정책을 강제로 적용하는 방법을 참조하십시오.
작업
DAST 스캔을 제외한 스캔에 대한 정책 작업은 파이프라인의 test
단계에 생성됩니다. 기본 파이프라인에서 test
단계를 제거하면 작업은 대신 scan-policies
단계에서 실행됩니다. 이 단계는 파이프라인에 주입되는 것으로, 평가 시에 없는 경우에 주입됩니다. build
단계가 있는 경우, build
단계 바로 뒤에 삽입되며, 그렇지 않으면 파이프라인의 맨 처음에 삽입됩니다. DAST 스캔은 항상 dast
단계에서 실행됩니다. 이 단계가 없는 경우 파이프라인의 끝에 dast
단계가 주입됩니다.
작업 이름 충돌을 피하기 위해 작업 이름 뒤에 하이픈과 번호가 추가됩니다. 번호는 정책 작업 당 고유합니다.
스캔 실행 정책 편집기
스캔 실행 정책 편집기를 사용하여 스캔 실행 정책을 생성 또는 편집합니다.
전제 조건:
- 그룹, 하위 그룹 또는 프로젝트 소유자만이 권한을 가지고 보안 정책 프로젝트를 선택할 수 있습니다.
- 보안 실행 정책 당 최대 5개의 스캔 실행 정책을 구성할 수 있습니다.
정책이 완료되면 편집기 하단의 Merge Request으로 설정을 선택하여 저장합니다. 이동되어 프로젝트에서 구성된 보안 정책 프로젝트의 Merge Request으로 이동합니다. 프로젝트에 연결된 것이 없으면 보안 정책 프로젝트가 자동으로 생성됩니다. 기존 정책은 편집기 인터페이스에서도 정책 삭제를 선택하여 삭제할 수 있습니다.
대부분의 정책 변경은 Merge Request이 Merge되는 즉시 적용됩니다. 기본 브랜치에 직접 커밋되지 않은 변경 사항은 정책 변경이 적용되기까지 최대 10분이 소요될 수 있습니다.
스캔 실행 정책 스키마
스캔 실행 정책을 포함하는 YAML 파일은 scan_execution_policy
키 아래에 중첩된 스캔 실행 정책 스키마의 배열로 구성됩니다. scan_execution_policy
키 아래에서 최대 5개의 정책을 구성할 수 있습니다. 첫 번째 5개 이상의 정책은 적용되지 않습니다.
새로운 정책을 저장할 때, GitLab은 이 JSON 스키마를 통해 정책 내용을 유효성 검사합니다. JSON 스키마 읽는 방법을 잘 모르는 경우, 다음 섹션 및 표에서 대안을 제공합니다.
필드 | 유형 | 필수 | 가능한 값 | 설명 |
---|---|---|---|---|
scan_execution_policy
| 스캔 실행 정책의 배열 | true | 스캔 실행 정책의 배열 (최대 5개) |
스캔 실행 정책 스키마
필드 | 유형 | 필수 | 가능한 값 | 설명 |
---|---|---|---|---|
name
| 문자열 | true | 정책 이름. 최대 255자. | |
description (선택사항)
| 문자열 | true | 정책 설명. | |
enabled
| 부울 | true |
true , false
| 정책을 활성화(true ) 또는 비활성화(false )하는 플래그.
|
rules
| 규칙의 배열 | true | 정책을 적용하는 규칙의 디렉터리. | |
actions
| 작업의 배열 | true | 정책이 강제하는 작업의 디렉터리. |
파이프라인
규칙 유형
특징 플래그:
Self-Managed형 GitLab에서는 기본적으로 branch_exceptions
필드를 사용할 수 있습니다. 기능을 숨기려면 관리자가 security_policies_branch_exceptions
라는 특징 플래그를 비활성화할 수 있습니다.
GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 있습니다.
이 규칙은 선택한 브랜치에 대해 파이프라인이 실행될 때 정의된 작업을 강제로 적용합니다.
필드 | 유형 | 필수 | 가능한 값 | 설명 |
---|---|---|---|---|
type
| 문자열 | true | pipeline
| 규칙의 유형. |
branches 1
|
string 의 배열
|
branch_type 필드가 없으면 필요
|
* 또는 브랜치 이름
| 해당 정책이 적용되는 브랜치(와일드카드 지원). |
branch_type 1
| 문자열 |
branches 필드가 없으면 필요
|
default , protected 또는 all
| 해당 정책이 적용되는 브랜치의 유형. |
branch_exceptions
| 문자열의 배열 | 선택적 | 브랜치 이름 | 이 규칙에서 제외할 브랜치의 이름. |
-
branches
또는branch_type
중 하나만 지정해야 합니다.
schedule
rule type
플래그:
Self-Managed형 GitLab에서 기본적으로 branch_exceptions
필드를 사용할 수 있습니다. 기능을 숨기려면 관리자가 security_policies_branch_exceptions
라는 피처 플래그를 비활성화할 수 있습니다.
GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 있습니다.
이 규칙은 스캔 파이프라인을 예약하고 cadence
필드에서 정의된 조치를 시행합니다. 예약된 파이프라인은 프로젝트의 .gitlab-ci.yml
파일에서 정의된 다른 작업을 실행하지 않습니다. 프로젝트가 보안 정책 프로젝트에 연결되면 보안 정책 봇이 프로젝트에 만들어지고 예약된 파이프라인의 작성자가 됩니다.
필드 | 유형 | 필수 | 가능한 값 | 설명 |
---|---|---|---|---|
type
| string
| true | schedule
| 규칙의 유형 |
branches 1
|
array of string
|
branch_type 또는 agents 필드 중 하나라도 존재하지 않으면 true
|
* 또는 브랜치 이름
| 지정된 정책이 적용되는 브랜치(와일드카드 지원). |
branch_type 1
| string
|
branches 또는 agents 필드 중 하나라도 존재하지 않으면 true
|
default , protected 또는 all
| 주어진 정책이 적용되는 브랜치의 유형. |
branch_exceptions
|
array of string
| false | 브랜치 이름 | 이 규칙에서 제외할 브랜치들 |
cadence
| string
| true | CRON 표현식 (예: 0 0 * * * )
| 스케줄된 시간을 나타내는 다섯 개의 필드를 포함한 공백으로 구분된 문자열 |
timezone
| string
| false | 시간대 식별자(예: America/New_York )
| cadence에 적용할 시간대. 값은 IANA 시간대 데이터베이스 식별자여야 합니다. |
agents 1
| object
|
branch_type 또는 branches 필드 중 하나라도 존재하지 않으면 true
| GitLab 에이전트의 이름과 Operational Container Scanning이 실행되는 GitLab 에이전트의 이름. 객체 키는 GitLab에서 프로젝트에 구성된 쿠버네티스 에이전트의 이름입니다. |
-
branches
,branch_type
, 또는agents
중 하나만 지정해야 합니다.
예약된 스캔 파이프라인은 보안 정책 프로젝트에 연결된 게스트 멤버인 보안 정책 봇 사용자에 의해 트리거됩니다. 보안 정책 봇 사용자는 자동으로 만들어지고 보안 정책 프로젝트에 링크가 제거되면 제거됩니다. 프로젝트에 보안 정책 봇 사용자가 없는 경우, 해당 봇은 자동으로 만들어지며 예약된 스캔 파이프라인이 그 봇을 사용합니다.
GitLab은 cadence
필드에 대해 다음과 같은 CRON 구문 유형을 지원합니다:
- 지정된 시간을 기준으로 매 시간 한 번씩 일일 스케줄
- 지정된 요일과 시간에 일주일에 한 번씩 주간 스케줄
cadence
필드의 CRON 구문의 다른 요소들이 작동할 수 있겠지만, GitLab에서는 공식적으로 테스트하거나 지원하지 않습니다.
쉼표 (,), 하이픈 (-) 또는 단계 연산자 (/)는 분과 시간에 대해 지원되지 않습니다.
정책을 만들 때 cadence가 유효하지 않으면 오류가 표시됩니다.
금시 또는 시간 필드에 쉼표 (,), 하이픈 (-), 또는 스텝 연산자 (/)를 사용한 이전에 만든 정책의 예약된 파이프라인은 건너뜁니다.
이전에 예약된 파이프라인은 지정된 시간에 새 파이프라인을 생성하기 위해 cadence
값을 사용합니다. 지정된 시간에 리소스가 사용 가능해지면 파이프라인이 실행됩니다.schedule
규칙 유형을 agents
필드와 함께 사용할 때 다음 사항을 유의하세요:
- 쿠버네티스 에이전트는 적용 가능한 정책을 찾기 위해 30초마다 확인합니다. 정책을 찾으면 CRON 표현식에 따라 스캔이 실행됩니다.
- CRON 표현식은 쿠버네티스 에이전트 pod의 시스템 시간을 사용하여 평가됩니다.
schedule
규칙 유형과 branches
필드를 함께 사용할 때 다음 사항을 유의하세요:
- 크론 워커는 15분 간격으로 실행되며 직전 15분 동안에 실행되어야 했던 파이프라인을 시작합니다.
- 규칙에 따라 예약된 파이프라인이 최대 15분까지 차이가 있을 수 있습니다.
- 대규모 프로젝트나 브랜치에 정책이 시행되는 경우 일괄 처리로 처리되며 모든 파이프라인을 생성하는 데 시간이 걸릴 수 있습니다.
- CRON 표현식은 GitLab.com의 표준 UTC 시간에서 평가됩니다. Self-Managed형 GitLab 인스턴스에서 서버 시간대를 변경했다면 CRON 표현식이 새로운 시간대로 평가됩니다.
agent
스키마
schedule
규칙 유형에서 agents
객체를 정의하는 데 이 스키마를 사용하세요.
필드 | 유형 | 필수 | 설명 |
---|---|---|---|
namespaces
|
array of string
| true | 스캔되는 네임스페이스. 비어있으면 모든 네임스페이스가 스캔됩니다. |
정책 예시
- name: Enforce Container Scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces
enabled: true
rules:
- type: schedule
cadence: '0 10 * * *'
agents:
<agent-name>:
namespaces:
- 'default'
- 'kube-system'
actions:
- scan: container_scanning
스케줄 규칙의 키는:
-
cadence
(필수): 스캔이 실행되는 시간을 나타내는 CRON 표현식 -
agents:<agent-name>
(필수): 스캔에 사용할 에이전트의 이름 -
agents:<agent-name>:namespaces
(선택사항): 스캔할 쿠버네티스 네임스페이스. 생략하면 모든 네임스페이스가 스캔됩니다.
scan
액션 유형
- 스캔 실행 정책 변수 우선순위가 변경되어 GitLab 16.7에서
security_policies_variables_precedence
라는 플래그가 지정되었습니다. 기본적으로 활성화됩니다. GitLab 16.8에서 피처 플래그가 제거되었습니다.
이 작업은 정의된 정책의 최소한 하나의 규칙에 대한 조건이 충족되었을 때 추가 매개변수와 함께 선택된 scan
을 실행합니다.
필드 | 타입 | 가능한 값 | 설명 |
---|---|---|---|
scan
| string
|
sast , sast_iac , dast , secret_detection , container_scanning , dependency_scanning
| 작업 유형입니다. |
site_profile
| string
| 선택된 DAST 사이트 프로필의 이름입니다. | 실행할 DAST 스캔에 사용되는 DAST 사이트 프로필입니다. 이 필드는 scan 유형이 dast 인 경우에만 설정되어야 합니다.
|
scanner_profile
|
string 또는 null
| 선택된 DAST 스캐너 프로필의 이름입니다. | 실행할 DAST 스캔에 사용되는 DAST 스캐너 프로필입니다. 이 필드는 scan 유형이 dast 인 경우에만 설정되어야 합니다.
|
variables
| object
| 선택된 스캔에 적용하고 강제하는 CI 변수 집합으로, key: value 쌍의 배열로 제공됩니다. key 는 변수 이름이며, value 는 문자열로 제공됩니다. 이 매개변수는 지정된 스캔에 대해 GitLab CI 작업이 지원하는 모든 변수를 지원합니다.
| |
tags
|
array of string
| 정책에 대한 러너 태그 디렉터리입니다. 정책 작업은 지정된 태그가 있는 러너에 의해 실행됩니다. |
다음 사항을 주의하세요:
- 선택한 Security Policy Project에 할당된 각 프로젝트에 대해 선택한 이름으로 사이트 프로필 및 스캐너 프로필을 생성해야 합니다. 그렇지 않으면 정책이 적용되지 않고 오류 메시지가 포함된 작업이 생성됩니다.
- 정책에서 사이트 프로필 및 스캐너 프로필을 이름으로 연결한 후에는 이를 수정하거나 삭제할 수 없습니다. 수정하려면 먼저
active
플래그를false
로 설정하여 정책을 비활성화해야 합니다. - 예약된 DAST 스캔으로 정책을 구성할 때, 보안 정책 프로젝트의 리파지토리에 커밋한 작성자는 스캐너 및 사이트 프로필에 액세스해야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.
- 비밀 탐지 스캔의 경우 기본 규칙 집합으로만 규칙이 지원됩니다. 사용자 정의 규칙 집합은 지원되지 않습니다. 대안으로 원격 구성 파일을 구성하고
SECRET_DETECTION_RULESET_GIT_REFERENCE
변수를 설정할 수 있습니다. - 기본적으로
예약된
스캔 실행 정책의 경우에는 정의된 CI 변수가 없는 비밀 탐지 스캔이 먼저historic
모드에서 실행됩니다 (SECRET_DETECTION_HISTORIC_SCAN
=true
). 이후의 예약된 스캔은 모두 기본 모드에서SECRET_DETECTION_LOG_OPTIONS
가 마지막 실행 및 현재 SHA 사이의 커밋 범위로 설정됩니다. 스캔 실행 정책에서 제공된 CI 변수는 이 동작을 재정의할 수 있습니다. historic mode에 대해 자세히 알아보기. -
triggered
스캔 실행 정책의 경우 비밀 탐지는.gitlab-ci.yml
에서 매뉴얼으로 구성한 것처럼 정상적으로 작동합니다. -
파이프라인
규칙 유형으로 구성된 컨테이너 스캐닝 스캔은agents
객체에 정의된 에이전트를 무시합니다.agents
객체는schedule
규칙 유형에만 고려됩니다.agents
에 제공된 이름을 가진 에이전트는 프로젝트에 생성하고 구성해야 합니다. - 스캔 실행 정책에서 정의된 변수는 표준 CI/CD 변수 우선순위를 따릅니다.
-
스캔 실행 정책이 강제되는 모든 프로젝트에서 다음과 같은 CI/CD 변수에 대해 사전 구성된 값이 사용됩니다. 값은 재정의될 수 있지만 정책에 선언되어야 합니다. 그룹 또는 프로젝트 CI/CD 변수에 의해 재정의할 수 없습니다.
DS_EXCLUDED_PATHS: spec, test, tests, tmp SAST_EXCLUDED_PATHS: spec, test, tests, tmp SECRET_DETECTION_EXCLUDED_PATHS: '' SECRET_DETECTION_HISTORIC_SCAN: false SAST_DISABLED_ANALYZERS: '' DS_DISABLED_ANALYZERS: ''
GitLab 16.9 및 이전 버전:
-
_EXCLUDED_PATHS
로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 값은 그룹 또는 프로젝트 CI/CD 변수에 의해 재정의될 수 있었습니다. -
_DISABLED_ANALYZERS
로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 정책, 그룹, 또는 프로젝트에 정의된 값을 무시했습니다.
-
보안 정책 범위
- GitLab 16.7에서
security_policies_policy_scope
라는 플래그가 지정되어 도입되었습니다. 기본적으로 활성화됩니다.- GitLab 16.11에서 일반적으로 사용 가능하게 되었습니다. 피처 플래그
security_policies_policy_scope
가 제거되었습니다.
보안 정책 강제는 먼저 정책을 포함하는 그룹, 서브그룹 또는 프로젝트와 정책을 포함하는 보안 정책 프로젝트 사이의 링크를 설정함으로써 가능합니다. 예를 들어, 정책을 그룹에 링크하려면 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 생성해야 합니다. 그런 다음, 보안 정책 프로젝트의 모든 정책이 그룹의 모든 프로젝트에 상속됩니다.
보안 정책 범위를 다음과 같이 세분화할 수 있습니다:
- 규정 준수 프레임워크 라벨이 포함된 프로젝트만 _포함_합니다.
- 선택한 프로젝트를 강제로 _포함_하거나 _제외_합니다.
정책 범위 스키마
필드 | 타입 | 필수 | 가능한 값 | 설명 |
---|---|---|---|---|
policy_scope
| object
| false |
compliance_frameworks , projects
| 규정 준수 프레임워크 라벨 또는 정의한 프로젝트를 기반으로 정책을 범위 지정합니다. |
policy_scope
범위 유형
필드 | 타입 | 가능한 값 | 설명 |
---|---|---|---|
compliance_frameworks
| array
| 범위 적용의 규정 준수 프레임워크 ID 디렉터리입니다. id 키를 가진 객체 배열입니다.
| |
projects
| object
|
including , excluding
|
excluding: 또는 including: 을 사용한 다음, 포함하거나 제외할 프로젝트의 ID 디렉터리을 객체 배열로 나열합니다.
|
보안 정책 범위가 포함된 policy.yml
예제
---
scan_execution_policy:
- name: 모든 릴리스 파이프라인에서 DAST 강제
description: 릴리스 브랜치에 DAST 스캔이 있는 작업을 강제하는 정책
enabled: true
rules:
- type: pipeline
branches:
- release/*
actions:
- scan: dast
scanner_profile: Scanner Profile A
site_profile: Site Profile B
policy_scope:
compliance_frameworks:
- id: 2
- id: 11
- name: 기본 브랜치 파이프라인에서 Secret Detection 및 Container Scanning 강제
description: 기본 브랜치에 Secret Detection 및 Container Scanning 스캔이 있는 작업을 강제하는 정책
enabled: true
rules:
- type: pipeline
branches:
- main
actions:
- scan: secret_detection
- scan: sast
variables:
SAST_EXCLUDED_ANALYZERS: brakeman
policy_scope:
projects:
excluding:
- id: 24
- id: 27
보안 정책 예시 프로젝트
이 예시를 .gitlab/security-policies/policy.yml
파일에 저장된 보안 정책 프로젝트에서 사용할 수 있습니다:
---
scan_execution_policy:
- name: 릴리스 파이프라인에 DAST 강제 실행
description: 이 정책은 릴리스 브랜치에 대한 파이프라인 구성에 DAST 스캔 작업을 강제합니다.
enabled: true
rules:
- type: pipeline
branches:
- release/*
actions:
- scan: dast
scanner_profile: Scanner Profile A
site_profile: Site Profile B
- name: DAST 및 시크릿 탐지 스캔을 10분마다 강제 실행
description: 이 정책은 DAST 및 시크릿 탐지 스캔을 10분마다 실행하도록 강제합니다.
enabled: true
rules:
- type: schedule
branches:
- main
cadence: "*/10 * * * *"
actions:
- scan: dast
scanner_profile: Scanner Profile C
site_profile: Site Profile D
- scan: secret_detection
- name: 기본 브랜치 파이프라인에 시크릿 탐지 및 컨테이너 스캔 강제 실행
description: 이 정책은 기본 브랜치에 대한 파이프라인 구성에 시크릿 탐지 및 컨테이너 스캔 작업을 강제합니다.
enabled: true
rules:
- type: pipeline
branches:
- main
actions:
- scan: secret_detection
- scan: sast
variables:
SAST_EXCLUDED_ANALYZERS: brakeman
- scan: container_scanning
이 예시에서:
-
release/*
와일드카드와 일치하는 브랜치에서 실행되는 모든 파이프라인에 대해- DAST 스캔이
Scanner Profile A
및Site Profile B
로 실행됩니다.
- DAST 스캔이
- DAST 및 시크릿 탐지 스캔은 10분마다 실행됩니다. DAST 스캔은
Scanner Profile C
및Site Profile D
로 실행됩니다. -
main
브랜치에서 실행되는 모든 파이프라인에 대해 시크릿 탐지, 컨테이너 스캔 및 SAST 스캔이 실행됩니다. SAST 스캔은SAST_EXCLUDED_ANALYZER
변수를"brakeman"
으로 설정하여 실행됩니다.
스캔 실행 정책 에디터 예시
스캔 실행 정책 에디터의 YAML 모드에서 이 예시를 사용할 수 있습니다. 이전 예시에서 하나의 객체에 해당합니다.
name: 기본 브랜치 파이프라인에 시크릿 탐지 및 컨테이너 스캔 강제 실행
description: 이 정책은 기본 브랜치에 대한 파이프라인 구성에 시크릿 탐지 및 컨테이너 스캔 작업을 강제합니다.
enabled: true
rules:
- type: pipeline
branches:
- main
actions:
- scan: secret_detection
- scan: container_scanning
중복 스캔 방지
스캔 실행 정책은 프로젝트의 .gitlab-ci.yml
파일에 스캔 작업을 포함시킨다면, 동일한 유형의 스캐너가 두 번 이상 실행되도록 할 수 있습니다. 이 동작은 의도적이며, 스캐너를 다른 변수 및 설정으로 여러 차례 실행할 수 있습니다. 예를 들어, 개발자는 보안 및 규정 준수팀에서 강제하는 것과 다른 변수로 SAST 스캔을 실행해보고 싶을 수 있습니다. 이 경우 한 파이프라인에서 개발자 변수로 SAST 작업이 실행되고, 보안 및 규정 준수팀 변수로 다른 SAST 작업이 실행됩니다.
중복 스캔을 실행하지 않으려면 프로젝트의 .gitlab-ci.yml
파일에서 스캔을 제거하거나 SAST_DISABLED: "true"
를 설정하여 로컬 작업을 비활성화할 수 있습니다. 이 방법으로 작업을 비활성화하면 스캔 실행 정책에 의해 정의된 보안 작업이 실행되지 않습니다.
실험적 기능
이 실험적인 기능에는 다음과 같은 제한이 있습니다.
-
.gitlab-ci.yml
파일이 없는 프로젝트에서 파이프라인 실행을 강제하는 것은 지원되지 않습니다. - 파이프라인 실행 액션이 예약된 트리거 유형과 함께 사용할 수 없습니다.
실험적인 기능에 대한 의견이 있으신가요? 의견을 듣고 싶습니다! 이에 대한 의견을 피드백 이슈에서 공유해 주세요.
파이프라인 실행 정책 액션
전제 조건:
-
파이프라인 실행 정책 액션 기능을 활성화하려면 그룹 소유자 또는 관리자가 실험 기능을 활성화해야 합니다.
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
- 설정 > 일반을 선택합니다.
- 권한 및 그룹 기능을 확장합니다.
- 보안 정책 파이프라인 실행 액션 확인란을 선택합니다.
-
선택 사항. 모든 하위 그룹에 적용을 선택합니다.
설정이 모든 하위 그룹에 적용되지 않으면 하위 그룹 소유자는 하위 그룹마다 설정을 관리할 수 있습니다.
파이프라인 실행 정책 액션은 대상 개발 프로젝트에서 사용자 정의 CI를 생성하고 강제하는 스캔 실행 정책을 위한 새로운 스캔 액션 유형을 도입합니다.
이 사용자 정의 스캔 유형은 원격 CI 구성 파일을 사용하여 원하는 사용자 정의 CI를 정의합니다. 스캔 실행 정책은 이 파일을 프로젝트의 .gitlab-ci.yml
과 Merge하여 정책에 의해 강제되는 각 프로젝트의 규정 준수 작업을 실행합니다.
ci_configuration_path
객체
필드 | 유형 | 필수 여부 | 설명 |
---|---|---|---|
project
| string
| true | 프로젝트 네임스페이스 경로 |
file
| string
| true | CI/CD YAML 파일의 파일명 |
ref
| string
| false | 브랜치 이름, 태그 이름 또는 커밋 SHA. 지정되지 않는 경우 기본 브랜치를 사용합니다. |
scan
액션 유형
이 액션은 정의된 정책의 적어도 하나의 규칙에 대한 조건이 충족될 때 선택된 scan
을 추가 매개변수와 함께 실행합니다.
필드 | 유형 | 가능한 값 | 설명 |
---|---|---|---|
scan
| string
| custom
| 액션의 유형 |
ci_configuration
| string
| 문자열 형식의 GitLab CI YAML | |
ci_configuration_path
| 객체 | CI 구성을 가리키는 프로젝트 경로 및 파일명을 가진 객체 |
다음 사항을 주목하세요:
-
custom
스캔의 경우ci_configuration
또는ci_configuration_path
중 하나를 지정해야 합니다. -
custom
스캔은 트리거된 규칙에 대해서만 실행됩니다. -
custom
스캔에 있는 작업 변수는 프로젝트의 CI/CD 구성의 변수보다 우선합니다. - 파이프라인을 트리거하는 사용자는
ci_configuration_path
에 지정된 CI 파일을 읽을 수 있는 최소한의 읽기 권한이 있어야 합니다. - 사용자 정의 스캔 액션에
stages
키워드를 사용하여 사용자 정의 단계를 정의할 수 없습니다. 대신에 세 가지 예약된 단계가 파이프라인에 추가됩니다:-
.pipeline-policy-pre
:.pre
단계 바로 앞에 위치합니다. -
.pipeline-policy-test
:test
단계 뒤에 위치합니다.test
단계가 없는 경우.post
단계 이후에 위치합니다.build
단계가 없는 경우.pre
단계 바로 앞에 위치합니다. -
.pipeline-policy-post
: 맨 끝에 위치합니다.
-
- 단계가 없는 작업은 기본적으로
.pipeline-policy-test
단계에 할당됩니다. - 예약된 단계를 사용자 정의 스캔 액션 외부에서 작업에 할당하는 것은 불가능합니다.
보안 정책 예시 프로젝트
이 예시를 .gitlab/security-policies/policy.yml
파일에 저장된 보안 정책 프로젝트에서 사용할 수 있습니다:
---
scan_execution_policy:
- name: 테스트 작업을 삽입하는 사용자 정의 스캔 생성
description: 이 정책은 릴리스 브랜치에 대한 파이프라인 구성에 DAST 스캔 작업을 강제합니다.
enabled: true
rules:
- type: pipeline
branches:
- release/*
actions:
- scan: custom
ci_configuration: |-
test job:
stage: test
script:
- echo "Hello World"