정책은 보안 팀과 컴플라이언스 팀이 조직 전체에 제어 항목을 전역으로 적용할 수 있는 방법을 제공합니다.

보안 팀은 다음을 보장할 수 있습니다:

• 보안 스캐너가 올바른 구성으로 개발 팀 파이프라인에 적용됩니다.
• 모든 스캔 job이 변경이나 수정 없이 실행됩니다.
• 해당 발견 사항의 결과를 기반으로 머지 리퀘스트에 적절한 승인이 이루어집니다.
• 더 이상 탐지되지 않는 취약점이 자동으로 해결되어 취약점 분류 작업량이 줄어듭니다.

컴플라이언스 팀은 다음을 적용할 수 있습니다:

• 모든 머지 리퀘스트에 대한 여러 승인자
• 머지 리퀘스트 설정이나 리포지터리 설정을 활성화하거나 잠그는 것과 같이 조직의 요구 사항에 기반한 프로젝트 설정.

다음 정책 유형을 사용할 수 있습니다:

• 스캔 실행 정책. 파이프라인의 일부로 또는 지정한 일정에 따라 보안 스캔을 적용합니다.
• 머지 리퀘스트 승인 정책. 스캔 결과를 기반으로 프로젝트 수준 설정과 승인 규칙을 적용합니다.
• 파이프라인 실행 정책. CI/CD job을 프로젝트 파이프라인의 일부로 적용합니다.
  • 예약된 파이프라인 실행 정책. 커밋 활동과 무관하게 여러 프로젝트에 걸쳐 지정한 주기로 사용자 지정 CI/CD job을 적용합니다.
• 취약점 관리 정책. 기본 브랜치에서 더 이상 탐지되지 않는 취약점을 자동으로 해결합니다.

정책 범위 구성#

policy_scope 키워드#

policy_scope 키워드를 사용하면 지정한 그룹, 프로젝트, 컴플라이언스 프레임워크, 보안 속성 또는 이들의 조합에만 정책을 적용합니다.

보안 속성으로 정책 범위를 지정하려면 보안 정책 프로젝트의 .gitlab/security-policies/policy.yml 파일에서 security_attributes_policy_scope 실험을 활성화합니다:

experiments:
  security_attributes_policy_scope:
    enabled: true

정책 범위는 기본 제공 보안 속성 카테고리 네 가지(business_impact, application, business_unit, exposure)로만 지정할 수 있습니다. 이 카테고리에서 사용자 지정 속성 값을 만들어 해당 값으로 범위를 지정할 수 있지만, 사용자 지정 카테고리로는 범위를 지정할 수 없습니다.

policy_scope의 빈 컬렉션#

policy_scope 필드를 빈 컬렉션([])으로 설정하면 해당 필드를 완전히 생략한 것과 같이 처리됩니다. 즉, 정책이 아무런 제한 없이 모든 프로젝트에 적용됩니다.

구체적으로는 다음과 같습니다:

• projects: { including: [] }는 정책을 프로젝트 0개가 아니라 모든 프로젝트에 적용합니다.
• groups: { including: [] }는 정책을 그룹 0개가 아니라 모든 그룹에 적용합니다.
• compliance_frameworks: []는 정책을 프레임워크가 없는 프로젝트가 아니라 모든 프로젝트에 적용합니다.

이 동작은 빈 컬렉션이 필터를 제공하지 않은 것처럼 처리되는 데 의존하는 기존 정책과의 하위 호환성을 유지합니다.

정책이 어떤 프로젝트에도 적용되지 않게 하려면 빈 컬렉션을 사용하는 대신 enabled: false를 설정합니다:

policy_scope:
  projects:
    including:
      - id: 123
enabled: false  # Disables the policy entirely

match_mode 이해#

여러 범위 조건(예: projects와 groups 둘 다)을 지정하면 match_mode 필드가 이 조건들을 결합하는 방식을 결정합니다:

• all(기본값): 정책이 지정한 조건을 모두 충족하는 프로젝트에만 적용됩니다. 이 모드는 더 제한적이고 기존 정책과의 하위 호환성을 유지합니다.
• any: 정책이 지정한 조건 중 하나라도 충족하는 프로젝트에 적용됩니다. 이 모드는 더 허용적이고, 하나의 정책으로 서로 다른 프로젝트 집합을 대상으로 삼을 때 유용합니다.

예를 들어 포함할 프로젝트 목록과 포함할 그룹 목록을 모두 지정한 경우는 다음과 같습니다:

• match_mode: all에서는 프로젝트가 프로젝트 목록에 있으면서 동시에 지정한 그룹 중 하나에 속해야 합니다.
• match_mode: any에서는 프로젝트가 프로젝트 목록에 있거나 또는 지정한 그룹 중 하나에 속하면 범위에 포함됩니다.

excluding 조건과 including 조건을 match_mode: any와 함께 결합할 때는 excluding 조건이 정책의 적용 범위를 넓힌다는 점에 유의합니다. OR 논리에서는 조건 하나라도 일치하면 정책이 적용되므로, 그룹 제외 조건(제외한 그룹에 속하지 않은 모든 프로젝트와 일치)은 including 조건에 무엇을 지정했든 정책이 대부분의 프로젝트에 적용된다는 뜻입니다.

예를 들어 그룹 목록에서 group-2를 제외하고 특정 프로젝트 group-1/project-1-1과 group-2/project-2-1을 포함하는 정책은 다음과 같습니다:

policy_scope:
 match_mode: any
 groups:
   excluding:
     - id: 200  # group-2
 projects:
   including:
     - id: 101  # group-1/project-1-1
     - id: 201  # group-2/project-2-1

이 구성에서는 정책이 명시적으로 포함한 두 프로젝트뿐 아니라 group-2 밖의 다른 모든 프로젝트(포함할 프로젝트에 나열되지 않은 group-1/project-1-2 등)에도 적용됩니다. 그룹 제외 조건은 group-2에 속하지 않은 모든 프로젝트와 일치하고, OR 논리에서는 하나만 일치해도 정책이 적용되기에 충분합니다.

범위 예시#

이 예시에서 스캔 실행 정책은 ID가 2 또는 11인 컴플라이언스 프레임워크가 적용된 모든 프로젝트에서 모든 릴리스 파이프라인에 SAST 스캔을 적용합니다.

---
scan_execution_policy:
- name: Enforce specified scans in every release pipeline
  description: This policy enforces a SAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: sast
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 11

이 예시에서 스캔 실행 정책은 기본 브랜치 파이프라인에 시크릿 탐지와 SAST 스캔을 적용하며, 대상은 ID가 203인 그룹의 모든 프로젝트(모든 하위 그룹과 그 프로젝트 포함)이고 ID가 64인 프로젝트는 제외합니다.

- name: Enforce specified scans in every default branch pipeline
  description: This policy enforces secret detection and SAST scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
  policy_scope:
    groups:
      including:
        - id: 203
    projects:
      excluding:
        - id: 64

이 예시에서 스캔 실행 정책은 아카이브된 프로젝트를 제외한 모든 프로젝트에 SAST 스캔을 적용합니다. 스캔하지 않아야 할 아카이브된 프로젝트가 많을 때 유용합니다.

- name: Enforce SAST scan excluding archived projects
  description: This policy enforces SAST scans but excludes archived projects
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: sast
  policy_scope:
    projects:
      excluding:
        - type: archived

이 예시에서 스캔 실행 정책은 match_mode: any를 사용해 우선순위가 높은 특정 프로젝트나 특정 그룹에 속한 모든 프로젝트에 시크릿 탐지 스캔을 적용합니다. match_mode: any가 없으면 정책이 적용되려면 프로젝트가 프로젝트 목록에 있으면서 지정한 그룹 중 하나에도 속해야 합니다.

- name: Enforce secret detection on priority projects or security groups
  description: This policy enforces secret detection on specific projects or all projects in security-focused groups
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  policy_scope:
    match_mode: any
    projects:
      including:
        - id: 123  # High-priority project outside of security groups
        - id: 456  # Another critical project
    groups:
      including:
        - id: 78   # Security team's group
        - id: 90   # Compliance team's group

이 예시에서 스캔 실행 정책은 ID가 5인 Business Impact 보안 속성 값(예: Mission Critical)을 가진 모든 프로젝트의 기본 브랜치에 SAST 스캔을 적용합니다. 속성이 추가되거나 제거되면 정책을 바꾸지 않고도 프로젝트가 이 범위에 들어오거나 빠집니다.

- name: Enforce SAST on mission-critical projects
  description: This policy enforces a SAST scan on projects with a Business Impact security attribute
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: sast
  policy_scope:
    business_impact:
      including:
        - id: 5

직무 분리#

정책을 성공적으로 구현하려면 직무 분리가 매우 중요합니다. 개발 팀이 목표를 달성할 수 있게 하면서 필요한 컴플라이언스 및 보안 요구 사항을 충족하는 정책을 구현합니다.

보안 및 컴플라이언스 팀:

• 정책을 정의하고, 정책이 개발 팀의 요구를 충족하는지 확인하기 위해 개발 팀과 협력할 책임이 있어야 합니다.

개발 팀:

• 어떤 방법으로도 정책을 비활성화하거나 수정하거나 우회할 수 없어야 합니다.

그룹, 하위 그룹 또는 프로젝트에 보안 정책 프로젝트를 적용하려면 다음 중 하나가 있어야 합니다:

• 해당 그룹, 하위 그룹 또는 프로젝트의 Owner 권한.
• 해당 그룹, 하위 그룹 또는 프로젝트에서 manage_security_policy_link 권한을 가진 사용자 지정 권한.

Owner 권한과 manage_security_policy_link 권한을 가진 사용자 지정 권한은 그룹, 하위 그룹, 프로젝트 전체에서 표준 계층 규칙을 따릅니다:

필요한 권한#

보안 정책을 만들고 관리하려면 다음이 필요합니다:

• 그룹에 적용하는 정책: 해당 그룹의 Maintainer 또는 Owner 권한이 있어야 합니다.
• 프로젝트에 적용하는 정책:
  • 프로젝트 소유자여야 합니다.
  • 그룹에서 프로젝트를 만들 권한이 있는 그룹 멤버여야 합니다.

정책 권장사항#

정책을 구현할 때는 다음 권장사항을 고려합니다.

브랜치 이름#

정책에서 브랜치 이름을 지정할 때는 개별 브랜치 이름이 아니라 기본 브랜치 또는 모든 보호된 브랜치와 같이 보호된 브랜치의 일반 카테고리를 사용합니다.

정책은 지정한 브랜치가 해당 프로젝트에 있을 때만 프로젝트에 적용됩니다. 예를 들어 정책이 main 브랜치에 규칙을 적용하는데 범위에 있는 일부 프로젝트가 기본 브랜치로 production을 사용한다면, 후자에는 정책이 적용되지 않습니다.

푸시 규칙#

GitLab 17.3 이하에서 푸시 규칙으로 브랜치 이름을 검증하는 경우 update-policy- 접두사가 붙은 브랜치를 만들 수 있도록 허용해야 합니다. 이 브랜치 이름 접두사는 보안 정책을 만들거나 수정할 때 사용됩니다. 예를 들어 update-policy-1659094451이며, 여기서 1659094451은 타임스탬프입니다. 푸시 규칙이 브랜치 생성을 차단하면 다음 오류가 발생합니다:

Branch name `update-policy-<timestamp>` does not follow the pattern `<branch_name_regex>`.

GitLab 17.4 이상에서는 보안 정책 프로젝트가 브랜치 이름 검증을 적용하는 푸시 규칙에서 제외됩니다.

보안 정책 프로젝트#

보안 정책 프로젝트에서 비공개로 유지하려던 민감한 정보가 노출되는 것을 막으려면, 보안 정책 프로젝트를 다른 프로젝트에 연결할 때 다음을 지킵니다:

• 보안 정책 프로젝트에 민감한 콘텐츠를 담지 않습니다.
• 비공개 보안 정책 프로젝트를 연결하기 전에 대상 프로젝트의 멤버 목록을 검토해 모든 멤버가 정책 콘텐츠에 액세스해도 되는지 확인합니다.
• 대상 프로젝트의 공개 범위 설정을 평가합니다.
• 보안 정책 관리 감사 로그로 프로젝트 연결을 모니터링합니다.

이 권장사항이 민감한 정보 노출을 막는 이유는 다음과 같습니다:

• 공개 범위 공유: 비공개 보안 프로젝트를 다른 프로젝트에 연결하면, 연결된 프로젝트의 Security Policies 페이지에 액세스할 수 있는 사용자가 .gitlab/security-policies/policy.yml 파일의 내용을 볼 수 있습니다. 비공개 보안 정책 프로젝트를 공개 프로젝트에 연결하는 경우도 여기에 해당하며, 이때 공개 프로젝트에 액세스할 수 있는 누구에게나 정책 내용이 노출될 수 있습니다.
• 액세스 제어: 비공개 보안 프로젝트가 연결된 프로젝트의 모든 멤버는 원래의 비공개 리포지터리에 액세스할 수 없어도 Policy 페이지에서 정책 파일을 볼 수 있습니다.

보안 및 컴플라이언스 제어#

프로젝트 Maintainer는 그룹 정책의 실행을 방해하는 프로젝트 정책을 만들 수 있습니다. 그룹 정책을 수정할 수 있는 사람을 제한하고 컴플라이언스 요구 사항이 충족되도록, 중요한 보안 또는 컴플라이언스 제어를 구현할 때는 다음을 따릅니다:

• 사용자 지정 권한으로 프로젝트 수준에서 파이프라인 실행 정책을 만들거나 수정할 수 있는 사람을 제한합니다.
• 보안 정책 프로젝트의 기본 브랜치에 보호된 브랜치를 구성해 직접 푸시를 막습니다.
• 보안 정책 프로젝트에 지정된 승인자의 검토를 요구하는 머지 리퀘스트 승인 규칙을 설정합니다.
• 그룹 정책과 프로젝트 정책 양쪽의 모든 정책 변경을 모니터링하고 검토합니다.

정책 관리#

Policies 페이지에는 사용할 수 있는 모든 환경의 배포된 정책이 표시됩니다. 정책 정보(예: 설명이나 적용 상태)를 확인하고, 배포된 정책을 만들고 편집할 수 있습니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Policies를 선택합니다.

첫 번째 칼럼의 녹색 체크 표시는 정책이 활성화되어 범위에 있는 모든 그룹과 프로젝트에 적용되고 있음을 나타냅니다. 회색 체크 표시는 정책이 현재 활성화되지 않았음을 나타냅니다.

정책 편집기#

정책 편집기에는 두 가지 모드가 있습니다:

• 규칙 모드: 규칙 블록과 관련 컨트롤로 정책 규칙을 구성하고 미리 봅니다.
• YAML 모드: YAML 형식으로 정책 정의를 입력합니다. 전문 사용자와 규칙 모드가 지원하지 않는 경우에 적합합니다.

규칙 모드와 YAML 모드는 언제든지 전환할 수 있습니다. YAML에 오류나 지원되지 않는 데이터가 있으면 규칙 모드가 자동으로 꺼집니다. 규칙 모드를 다시 사용하려면 먼저 YAML을 수정합니다.

정책 편집기로 정책을 만들고 편집하고 삭제합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

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

   • 새 정책을 만들려면 Policies 페이지 헤더에서 New policy를 선택한 다음 정책 유형을 선택합니다.
   • 기존 정책을 편집하려면 선택한 정책 드로어에서 Edit policy를 선택합니다.

3. Configure with a merge request를 선택해 변경 사항을 저장하고 적용합니다.

   정책의 YAML이 검증되고, 그 결과로 발생한 오류가 표시됩니다.

4. 생성된 머지 리퀘스트를 검토하고 머지합니다.

   프로젝트 소유자이고 이 프로젝트에 보안 정책 프로젝트가 연결되어 있지 않으면, 머지 리퀘스트를 만들 때 보안 정책 프로젝트가 생성되어 이 프로젝트에 연결됩니다.

표준 및 고급 편집기 레이아웃#

히스토리

• GitLab 17.8에서 도입되었습니다.

정책 편집기에는 규칙 모드와 YAML 모드를 표시하는 방식을 결정하는 두 가지 레이아웃이 있습니다:

• 표준 편집기: 규칙 모드와 YAML 모드를 별도의 탭으로 표시합니다. 탭을 선택해 화면을 전환합니다. 규칙 모드에서는 읽기 전용 YAML 미리 보기가 사이드바에 표시됩니다.

• 고급 편집기: 규칙 모드와 YAML 모드를 크기 조절이 가능한 분할 화면에 나란히 표시합니다. 한쪽 패널의 변경 사항이 다른 쪽에 실시간으로 반영됩니다. 다음을 할 수 있습니다:

  • 구분선을 드래그해 패널 크기를 조절합니다.
  • 한쪽 패널을 접어 한 화면에 집중합니다.
  • 패널 크기를 초기화하려면 구분선을 두 번 선택합니다.

선호하는 패널 크기는 세션 간에 저장됩니다.

표준 편집기 레이아웃과 고급 편집기 레이아웃을 전환하려면 다음을 수행합니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.

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

   • 새 정책을 만들려면 Policies 페이지 헤더에서 New policy를 선택한 다음 정책 유형을 선택합니다.
   • 기존 정책을 편집하려면 선택한 정책 드로어에서 Edit policy를 선택합니다.

3. 정책 편집기 상단에서 Enable advanced editor 또는 Enable standard editor를 선택합니다.

선호 설정은 사용자 계정에 저장되고 세션 간에 유지됩니다.

policy.yml에서 ID 주석 달기#

히스토리

• GitLab 18.1에서 policy.yml 파일에 정의하는 annotate_ids 옵션과 함께 실험 기능으로 도입되었습니다.

policy.yml 파일을 단순하게 유지하기 위해 GitLab은 프로젝트 ID, 그룹 ID, 사용자 ID, 컴플라이언스 프레임워크 ID와 같은 ID 뒤에 주석을 자동으로 추가할 수 있습니다. 주석은 각 ID의 의미나 출처를 사용자가 파악하는 데 도움이 되므로, policy.yml 파일을 이해하고 유지 관리하기가 더 쉬워집니다.

이 실험 기능을 활성화하려면 보안 정책 프로젝트의 .gitlab/security-policies/policy.yml 파일에서 experiments 섹션에 annotate_ids 섹션을 추가합니다:

experiments:
  annotate_ids:
    enabled: true

이 옵션을 활성화하면 GitLab 정책 편집기로 보안 정책을 변경할 때마다 policy.yml 파일의 ID 옆에 주석이 생성됩니다.

예시는 다음과 같습니다:

# Example policy.yml with annotated IDs
approval_policy:
- name: Your policy name
  # ... other policy fields ...
  policy_scope:
    projects:
      including:
      - id: 361 # my-group/my-project
  actions:
  - type: require_approval
    approvals_required: 1
    user_approvers_ids:
    - 75 # jane.doe
    group_approvers_ids:
    - 203 # security-approvers

GitLab Security Policy Bot 사용자#

GitLab Security Policy Bot은 GitLab 인스턴스 전체에서 보안 정책을 실행하는 내부 사용자입니다. 이 봇은 보안 정책과 예약된 파이프라인이 올바르게 동작하는 데 필수입니다.

Security Policy Bot은 다음을 담당합니다:

• 예약된 파이프라인 실행: type: schedule 규칙이 있는 스캔 실행 정책에 정의된 파이프라인을 트리거합니다.
• 컨테이너 스캔 자동화: latest 태그로 이미지를 푸시할 때 컨테이너 스캔 job을 트리거합니다.
• 정책 적용: 보안 정책에 정의된 보안 스캔과 컴플라이언스 검사를 실행합니다.
• 파이프라인 생성: 보안 정책이 적용된 프로젝트에서 정책 기반 파이프라인을 생성하고 관리합니다.

계정 특성#

Security Policy Bot의 특성은 다음과 같습니다:

• 보안 정책이 적용된 모든 프로젝트에 자동으로 생성됩니다.
• 프로젝트에서 Guest 권한으로 실행되며, 특정 권한이 추가로 부여됩니다.
• 내부 사용자로 표시되므로 라이선스 한도에 포함되지 않습니다.
• 정책이 적용되면 각 프로젝트가 자체 Security Policy Bot 인스턴스를 갖습니다.

권한 및 액세스#

Security Policy Bot은 최소한이지만 필수적인 권한으로 동작합니다:

• 리포지터리 액세스: 정책 실행에 필요한 리포지터리 콘텐츠에 대한 읽기 전용 액세스입니다.
• 파이프라인 생성: 정책 적용을 위해 파이프라인을 생성하고 트리거할 수 있습니다.
• CI/CD 변수: 변수 우선순위 규칙에 따라 프로젝트 변수와 그룹 변수에 액세스합니다.
• 레지스트리 액세스: 적절한 자격 증명이 구성되어 있으면 컨테이너 레지스트리에 인증할 수 있습니다.

제한사항#

GitLab Security Policy Bot에는 다음 제한사항이 있습니다:

• 수동으로 삭제할 수 없음: UI에서 봇을 삭제할 수 없습니다.
• 수정할 수 없음: 사용자 설정이나 권한을 수동으로 변경할 수 없습니다.
• 프로젝트에 종속됨: 각 봇 인스턴스는 특정 프로젝트에 묶여 있어 여러 프로젝트에서 인스턴스를 공유할 수 없습니다.
• 정책에 종속됨: 봇의 기능은 전적으로 해당 프로젝트에 구성된 보안 정책에 의존합니다.

보안 문제 해결#

Security Policy Bot 기능에 문제가 있으면 다음을 참고합니다:

예약된 파이프라인이 실행되지 않는 경우#

예약된 파이프라인이 구성한 대로 실행되지 않는다면 다음을 확인합니다:

• 봇 계정이 존재하고 차단되거나 삭제되지 않았는지 확인합니다.
• 보안 정책 구성이 유효한지 확인합니다.
• 봇이 프로젝트에서 필요한 권한을 갖고 있는지 확인합니다.

정책 job 실패#

정책 job이 실패한다면 다음을 확인합니다:

• 봇이 필요한 CI/CD 변수에 액세스할 수 있는지 확인합니다.
• 참조된 CI/CD 구성 파일이 존재하고 액세스할 수 있는지 확인합니다.
• 파이프라인 로그에서 구체적인 오류 메시지를 검토합니다.

컨테이너 스캔이 트리거되지 않는 경우#

컨테이너 스캔이 구성한 대로 트리거되지 않는다면 다음을 확인합니다:

• 컨테이너 스캔 정책이 올바르게 구성되었는지 확인합니다.
• 필요한 경우 봇에 레지스트리 인증 자격 증명이 있는지 확인합니다.
• latest 태그 푸시가 예상한 정책 규칙을 트리거했는지 확인합니다.

봇 계정 누락#

봇 계정이 더 이상 존재하지 않는다면 다음을 수행합니다:

• 보안 정책을 다시 적용하거나 업데이트해 봇 계정을 다시 만듭니다.
• 악용 신고로 봇이 의도치 않게 차단되거나 삭제되었다면 GitLab 관리자에게 문의합니다.

문제 해결#

보안 정책을 다룰 때는 다음 문제 해결 팁을 고려합니다:

• 보안 정책 프로젝트를 개발 프로젝트와, 그 개발 프로젝트가 속한 그룹이나 하위 그룹에 동시에 연결하지 않아야 합니다. 이렇게 연결하면 머지 리퀘스트 승인 정책의 승인 규칙이 개발 프로젝트의 머지 리퀘스트에 적용되지 않습니다.
• 머지 리퀘스트 승인 정책을 만들 때 scan_finding 규칙의 severity_levels 배열과 vulnerability_states 배열은 어느 쪽도 비워 둘 수 없습니다. 규칙이 동작하려면 각 배열에 항목이 하나 이상 있어야 합니다.
• 프로젝트 소유자는 그룹에서 프로젝트를 만들 권한도 함께 있다면 해당 프로젝트에 정책을 적용할 수 있습니다. 그룹 멤버가 아닌 프로젝트 소유자는 정책을 추가하거나 편집하는 데 제한이 있을 수 있습니다. 프로젝트의 정책을 관리할 수 없다면 그룹 관리자에게 문의해 그룹에서 필요한 권한이 있는지 확인합니다.
• 정책이 충돌하면 가장 최근에 적용된 정책이 우선합니다.

여전히 문제가 있다면 최근 보고된 버그를 확인하고, 보고되지 않은 새 이슈를 등록할 수 있습니다.

GraphQL API로 정책 재동기화#

정책이 적용되지 않거나 승인이 올바르지 않은 등 정책에 일관되지 않은 점이 보이면, GraphQL resyncSecurityPolicies 뮤테이션으로 정책 재동기화를 수동으로 강제할 수 있습니다:

mutation {
  resyncSecurityPolicies(input: { fullPath: "group-or-project-path" }) {
    errors
  }
}

fullPath에는 보안 정책 프로젝트가 할당된 프로젝트나 그룹의 경로를 설정합니다.

GraphQL API로 프로젝트 재동기화#

영향을 받는 프로젝트가 그룹이나 하위 그룹에서 정책을 상속받는다면 해당 프로젝트만 재동기화할 수 있습니다:

mutation {
  resyncSecurityPolicies(
    input: {
      fullPath: "project-path"
      relationship: INHERITED
    }
  ) {
    errors
  }
}

fullPath에는 정책을 상속받는 프로젝트의 경로를 설정합니다. relationship: INHERITED를 사용하면 전체 그룹이나 하위 그룹을 재동기화하지 않고 그 프로젝트가 상속받은 정책만 재동기화합니다.