InfoGrab DocsInfoGrab Docs

보안 정책 프로젝트

요약

보안 정책 프로젝트는 여러 프로젝트에 정책을 강제 적용합니다. 머지 리퀘스트에서 변경한 정책은 해당 머지 리퀘스트가 병합되는 즉시 적용됩니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트는 여러 프로젝트에 정책을 강제 적용합니다. 보안 정책 프로젝트는 정책만 담아 두는 특수한 유형의 프로젝트입니다. 보안 정책 프로젝트에 담긴 정책을 강제 적용하려면 정책을 적용할 프로젝트, 하위 그룹, 그룹에 해당 보안 정책 프로젝트를 연결합니다. 보안 정책 프로젝트는 여러 정책을 담을 수 있으며, 담긴 정책은 함께 강제 적용됩니다. 그룹 또는 하위 그룹에 강제 적용된 보안 정책 프로젝트는 모든 하위 그룹과 그 프로젝트를 포함해 계층 구조 아래의 모든 대상에 적용됩니다.

머지 리퀘스트에서 변경한 정책은 해당 머지 리퀘스트가 병합되는 즉시 적용됩니다. 머지 리퀘스트를 거치지 않고 기본 브랜치에 직접 커밋한 정책 변경은 적용되기까지 최대 10분이 걸릴 수 있습니다.

정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트 구현#

보안 정책 프로젝트의 구현 방식은 GitLab.com, GitLab Dedicated, GitLab Self-Managed 사이에 조금씩 다릅니다. 가장 큰 차이는 GitLab.com에서는 하위 그룹만 만들 수 있다는 점입니다. 직무 분리를 보장하려면 더 세밀한 권한 구성이 필요합니다.

GitLab.com 네임스페이스에서 전역으로 정책 강제 적용#

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 Owner 권한 또는 manage_security_policy_link 권한을 가진 사용자 지정 역할이 있어야 합니다. 자세한 내용은 직무 분리를 참고합니다.

GitLab.com 네임스페이스의 모든 하위 그룹과 프로젝트에 전역으로 정책을 강제 적용하는 대략적인 워크플로는 다음과 같습니다.

  1. 최상위 그룹에서 Policies 탭을 엽니다.

  2. 하위 그룹에서 Policies 탭으로 이동해 테스트 정책을 만듭니다.

    테스트 목적으로 정책을 비활성화 상태로 만들 수 있습니다. 정책을 만들면 최상위 그룹 아래에 보안 정책 프로젝트가 자동으로 생성됩니다. 이 프로젝트는 policy.yml 또는 코드형 정책을 저장하는 데 사용됩니다.

  3. 새로 생성된 프로젝트에서 권한을 확인하고 필요에 맞게 설정합니다.

    기본적으로 Owner와 Maintainer는 정책을 만들고 편집하고 삭제할 수 있습니다. Developer는 정책 변경을 제안할 수 있으나 병합할 수는 없습니다.

  4. 하위 그룹 안에 생성된 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    생성한 Security Policy Management 프로젝트의 Policies 탭에서 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 정책을 직접 수정할 수 있습니다.

  5. 그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결합니다.

    적절한 권한을 가진 하위 그룹 소유자 또는 프로젝트 소유자는 Policies 페이지에서 보안 정책 프로젝트로 연결을 만들 수 있습니다. 전체 경로를 포함하며, 프로젝트 이름은 "- security policy project" 로 끝나야 합니다. 연결된 모든 그룹, 하위 그룹, 프로젝트는 보안 정책 프로젝트에서 만든 정책의 강제 적용 대상이 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참고합니다.

  6. 기본적으로 정책이 활성화되면 연결된 그룹, 하위 그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다.

    더 세밀하게 강제 적용하려면 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 집합이나 특정 컴플라이언스 프레임워크 레이블을 가진 프로젝트를 대상으로 정책을 강제 적용할 수 있습니다.

  7. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구하는 등 추가 제한이 필요하면, 보안 정책 프로젝트만 범위로 하는 정책을 추가로 만들어 추가 승인을 강제 적용할 수 있습니다.

GitLab Dedicated 또는 GitLab Self-Managed에서 전역으로 정책 강제 적용#

Note

GitLab Self-Managed에서는 컴플라이언스 및 보안 정책 그룹을 사용해 인스턴스 전체에 보안 정책을 강제 적용할 수도 있습니다.

사전 요건:

여러 그룹에 정책을 강제 적용하는 대략적인 워크플로는 다음과 같습니다.

  1. 정책을 담고 직무 분리를 보장할 별도 그룹을 만듭니다.

    독립된 별도 그룹을 만들면 권한을 상속받는 사용자 수를 최소화할 수 있습니다.

  2. 새 그룹에서 Policies 탭을 엽니다.

    이 탭이 정책 편집기의 기본 위치이며, UI에서 정책을 만들고 관리할 수 있습니다.

  3. 테스트 정책을 만듭니다(테스트 목적으로 정책을 비활성화 상태로 만들 수 있습니다).

    정책을 만들면 그룹 아래에 보안 정책 프로젝트가 자동으로 생성됩니다. 이 프로젝트는 policy.yml 또는 코드형 정책을 저장하는 데 사용됩니다.

  4. 새로 생성된 프로젝트에서 권한을 확인하고 필요에 맞게 설정합니다.

    기본적으로 Owner와 Maintainer는 정책을 만들고 편집하고 삭제할 수 있습니다. Developer는 정책 변경을 제안할 수 있으나 병합할 수는 없습니다.

  5. 하위 그룹에 생성된 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    생성한 Security Policy Management 프로젝트의 Policies 탭에서 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 정책을 직접 수정할 수 있습니다.

  6. 그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결합니다.

    적절한 권한을 가진 하위 그룹 소유자 또는 프로젝트 소유자는 Policies 페이지에서 보안 정책 프로젝트로 연결을 만들 수 있습니다. 전체 경로를 포함하며, 프로젝트 이름은 "- security policy project" 로 끝나야 합니다. 연결된 모든 그룹, 하위 그룹, 프로젝트는 보안 정책 프로젝트에서 만든 정책의 강제 적용 대상이 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참고합니다.

  7. 기본적으로 정책이 활성화되면 연결된 그룹, 하위 그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다. 더 세밀하게 강제 적용하려면 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 집합이나 특정 컴플라이언스 프레임워크 레이블을 포함한 프로젝트를 대상으로 정책을 강제 적용할 수 있습니다.

  8. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구하는 등 추가 제한이 필요하면, 보안 정책 프로젝트만 범위로 하는 정책을 추가로 만들어 추가 승인을 강제 적용할 수 있습니다.

보안 정책 프로젝트에 연결#

보안 정책 프로젝트에 담긴 정책을 그룹, 하위 그룹, 프로젝트에 강제 적용하려면 둘을 연결합니다. 기본적으로 연결된 모든 대상에 강제 적용됩니다. 정책별로 세밀하게 강제 적용하려면 각 정책에 정책 범위를 설정할 수 있습니다.

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 Owner 권한 또는 manage_security_policy_link 권한을 가진 사용자 지정 역할이 있어야 합니다. 자세한 내용은 직무 분리를 참고합니다.

그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결하려면 다음 단계를 따릅니다.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트, 하위 그룹, 그룹을 찾습니다.
  2. Secure > Policies를 선택합니다.
  3. Edit Policy Project를 선택한 다음, 드롭다운 목록에서 연결할 프로젝트를 검색해 선택합니다.
  4. Save를 선택합니다.

보안 정책 프로젝트의 연결을 해제하려면 같은 단계를 따르되 대화 상자에서 휴지통 아이콘을 선택합니다. 같은 최상위 그룹의 다른 하위 그룹에 있는 보안 정책 프로젝트나 완전히 다른 최상위 그룹의 보안 정책 프로젝트에 연결할 수 있습니다. 다만 파이프라인 실행 정책을 강제 적용하는 경우, 파이프라인을 트리거하려면 사용자에게 정책에서 참조하는 CI/CD 구성이 담긴 프로젝트에 대한 읽기 권한 이상이 있어야 합니다.

연결된 보안 정책 프로젝트 보기#

프로젝트 정책 페이지에 접근할 수 있으나 프로젝트 소유자가 아닌 사용자에게는 연결된 보안 정책 프로젝트로 이동하는 버튼이 대신 표시됩니다.

보안 정책 프로젝트는 둘 이상의 그룹 또는 프로젝트에 연결할 수 있습니다. 연결된 그룹이나 프로젝트 중 한 곳에서 보안 정책을 볼 수 있는 사용자는 다른 연결된 그룹과 프로젝트에 어떤 보안 정책이 강제 적용되는지 파악할 수 있습니다.

정책 한도 변경#

히스토리

성능상의 이유로 GitLab은 보안 정책 프로젝트에 구성할 수 있는 정책 수를 제한합니다.

Warning

보안 정책 프로젝트에 현재 저장된 정책 수보다 한도를 낮추면 GitLab은 한도를 초과한 정책을 강제 적용하지 않습니다. 해당 정책을 다시 활성화하려면 가장 많은 정책을 가진 보안 정책 프로젝트의 정책 수에 맞춰 한도를 높입니다.

기본 한도는 다음과 같습니다.

정책 유형 기본 정책 한도
머지 리퀘스트 승인 정책 5
스캔 실행 정책 5
파이프라인 실행 정책 5
취약점 관리 정책 5

GitLab Self-Managed 인스턴스에서 인스턴스 관리자는 정책 유형별 최대 20개까지 인스턴스 전체의 한도를 조정할 수 있습니다. 관리자는 특정 최상위 그룹의 한도를 변경할 수도 있습니다.

인스턴스의 정책 한도 변경#

사전 요건:

  • 관리자 액세스 권한.

조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면 다음 단계를 따릅니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Security and compliance를 선택합니다.
  3. Security policies 섹션을 확장합니다.
  4. 변경할 정책 유형마다 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

최상위 그룹의 정책 한도 변경#

그룹 한도는 구성된 인스턴스 한도나 기본 인스턴스 한도를 초과할 수 있습니다. 최상위 그룹에 대해 조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면 다음 단계를 따릅니다.

Note

이 한도를 높이면 시스템 성능에 영향을 줄 수 있으며, 복잡한 정책을 많이 적용하는 경우 특히 그렇습니다.

사전 요건:

  • 관리자 액세스 권한.

최상위 그룹의 한도를 조정하려면 다음 단계를 따릅니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Groups를 선택합니다.
  3. 수정할 최상위 그룹의 행에서 Edit를 선택합니다.
  4. 변경할 정책 유형마다 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

개별 그룹의 한도를 0으로 설정하면 시스템은 인스턴스 전체 기본값을 사용합니다. 이에 따라 한도가 0인 그룹도 기본 인스턴스 구성에 따라 정책을 만들 수 있습니다.

보안 정책 프로젝트 삭제#

히스토리
  • 보안 정책 프로젝트에 대한 삭제 보호가 GitLab 17.8에서 reject_security_policy_project_deletion이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • 보안 정책 프로젝트를 포함한 그룹에 대한 삭제 보호가 GitLab 17.9에서 reject_security_policy_project_deletion_groups라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • 보안 정책 프로젝트와 이를 포함한 그룹에 대한 삭제 보호가 GitLab 17.10에서 일반 제공됩니다. 기능 플래그 reject_security_policy_project_deletion과 reject_security_policy_project_deletion_groups는 제거되었습니다.

보안 정책 프로젝트 또는 그 상위 그룹을 삭제하려면 다른 모든 프로젝트나 그룹에서 해당 연결을 제거해야 합니다. 그렇지 않으면 연결된 보안 정책 프로젝트나 상위 그룹을 삭제하려고 할 때 오류 메시지가 표시됩니다.

보안 정책 프로젝트

GitLab v19.5
Tier: Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

보안 정책 프로젝트는 여러 프로젝트에 정책을 강제 적용합니다. 머지 리퀘스트에서 변경한 정책은 해당 머지 리퀘스트가 병합되는 즉시 적용됩니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트는 여러 프로젝트에 정책을 강제 적용합니다. 보안 정책 프로젝트는 정책만 담아 두는 특수한 유형의 프로젝트입니다. 보안 정책 프로젝트에 담긴 정책을 강제 적용하려면 정책을 적용할 프로젝트, 하위 그룹, 그룹에 해당 보안 정책 프로젝트를 연결합니다. 보안 정책 프로젝트는 여러 정책을 담을 수 있으며, 담긴 정책은 함께 강제 적용됩니다. 그룹 또는 하위 그룹에 강제 적용된 보안 정책 프로젝트는 모든 하위 그룹과 그 프로젝트를 포함해 계층 구조 아래의 모든 대상에 적용됩니다.

머지 리퀘스트에서 변경한 정책은 해당 머지 리퀘스트가 병합되는 즉시 적용됩니다. 머지 리퀘스트를 거치지 않고 기본 브랜치에 직접 커밋한 정책 변경은 적용되기까지 최대 10분이 걸릴 수 있습니다.

정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트 구현#

보안 정책 프로젝트의 구현 방식은 GitLab.com, GitLab Dedicated, GitLab Self-Managed 사이에 조금씩 다릅니다. 가장 큰 차이는 GitLab.com에서는 하위 그룹만 만들 수 있다는 점입니다. 직무 분리를 보장하려면 더 세밀한 권한 구성이 필요합니다.

GitLab.com 네임스페이스에서 전역으로 정책 강제 적용#

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 Owner 권한 또는 manage_security_policy_link 권한을 가진 사용자 지정 역할이 있어야 합니다. 자세한 내용은 직무 분리를 참고합니다.

GitLab.com 네임스페이스의 모든 하위 그룹과 프로젝트에 전역으로 정책을 강제 적용하는 대략적인 워크플로는 다음과 같습니다.

  1. 최상위 그룹에서 Policies 탭을 엽니다.

  2. 하위 그룹에서 Policies 탭으로 이동해 테스트 정책을 만듭니다.

    테스트 목적으로 정책을 비활성화 상태로 만들 수 있습니다. 정책을 만들면 최상위 그룹 아래에 보안 정책 프로젝트가 자동으로 생성됩니다. 이 프로젝트는 policy.yml 또는 코드형 정책을 저장하는 데 사용됩니다.

  3. 새로 생성된 프로젝트에서 권한을 확인하고 필요에 맞게 설정합니다.

    기본적으로 Owner와 Maintainer는 정책을 만들고 편집하고 삭제할 수 있습니다. Developer는 정책 변경을 제안할 수 있으나 병합할 수는 없습니다.

  4. 하위 그룹 안에 생성된 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    생성한 Security Policy Management 프로젝트의 Policies 탭에서 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 정책을 직접 수정할 수 있습니다.

  5. 그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결합니다.

    적절한 권한을 가진 하위 그룹 소유자 또는 프로젝트 소유자는 Policies 페이지에서 보안 정책 프로젝트로 연결을 만들 수 있습니다. 전체 경로를 포함하며, 프로젝트 이름은 "- security policy project" 로 끝나야 합니다. 연결된 모든 그룹, 하위 그룹, 프로젝트는 보안 정책 프로젝트에서 만든 정책의 강제 적용 대상이 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참고합니다.

  6. 기본적으로 정책이 활성화되면 연결된 그룹, 하위 그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다.

    더 세밀하게 강제 적용하려면 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 집합이나 특정 컴플라이언스 프레임워크 레이블을 가진 프로젝트를 대상으로 정책을 강제 적용할 수 있습니다.

  7. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구하는 등 추가 제한이 필요하면, 보안 정책 프로젝트만 범위로 하는 정책을 추가로 만들어 추가 승인을 강제 적용할 수 있습니다.

GitLab Dedicated 또는 GitLab Self-Managed에서 전역으로 정책 강제 적용#

Note

GitLab Self-Managed에서는 컴플라이언스 및 보안 정책 그룹을 사용해 인스턴스 전체에 보안 정책을 강제 적용할 수도 있습니다.

사전 요건:

여러 그룹에 정책을 강제 적용하는 대략적인 워크플로는 다음과 같습니다.

  1. 정책을 담고 직무 분리를 보장할 별도 그룹을 만듭니다.

    독립된 별도 그룹을 만들면 권한을 상속받는 사용자 수를 최소화할 수 있습니다.

  2. 새 그룹에서 Policies 탭을 엽니다.

    이 탭이 정책 편집기의 기본 위치이며, UI에서 정책을 만들고 관리할 수 있습니다.

  3. 테스트 정책을 만듭니다(테스트 목적으로 정책을 비활성화 상태로 만들 수 있습니다).

    정책을 만들면 그룹 아래에 보안 정책 프로젝트가 자동으로 생성됩니다. 이 프로젝트는 policy.yml 또는 코드형 정책을 저장하는 데 사용됩니다.

  4. 새로 생성된 프로젝트에서 권한을 확인하고 필요에 맞게 설정합니다.

    기본적으로 Owner와 Maintainer는 정책을 만들고 편집하고 삭제할 수 있습니다. Developer는 정책 변경을 제안할 수 있으나 병합할 수는 없습니다.

  5. 하위 그룹에 생성된 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    생성한 Security Policy Management 프로젝트의 Policies 탭에서 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 정책을 직접 수정할 수 있습니다.

  6. 그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결합니다.

    적절한 권한을 가진 하위 그룹 소유자 또는 프로젝트 소유자는 Policies 페이지에서 보안 정책 프로젝트로 연결을 만들 수 있습니다. 전체 경로를 포함하며, 프로젝트 이름은 "- security policy project" 로 끝나야 합니다. 연결된 모든 그룹, 하위 그룹, 프로젝트는 보안 정책 프로젝트에서 만든 정책의 강제 적용 대상이 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참고합니다.

  7. 기본적으로 정책이 활성화되면 연결된 그룹, 하위 그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다. 더 세밀하게 강제 적용하려면 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 집합이나 특정 컴플라이언스 프레임워크 레이블을 포함한 프로젝트를 대상으로 정책을 강제 적용할 수 있습니다.

  8. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구하는 등 추가 제한이 필요하면, 보안 정책 프로젝트만 범위로 하는 정책을 추가로 만들어 추가 승인을 강제 적용할 수 있습니다.

보안 정책 프로젝트에 연결#

보안 정책 프로젝트에 담긴 정책을 그룹, 하위 그룹, 프로젝트에 강제 적용하려면 둘을 연결합니다. 기본적으로 연결된 모든 대상에 강제 적용됩니다. 정책별로 세밀하게 강제 적용하려면 각 정책에 정책 범위를 설정할 수 있습니다.

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 Owner 권한 또는 manage_security_policy_link 권한을 가진 사용자 지정 역할이 있어야 합니다. 자세한 내용은 직무 분리를 참고합니다.

그룹, 하위 그룹, 프로젝트를 보안 정책 프로젝트에 연결하려면 다음 단계를 따릅니다.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트, 하위 그룹, 그룹을 찾습니다.
  2. Secure > Policies를 선택합니다.
  3. Edit Policy Project를 선택한 다음, 드롭다운 목록에서 연결할 프로젝트를 검색해 선택합니다.
  4. Save를 선택합니다.

보안 정책 프로젝트의 연결을 해제하려면 같은 단계를 따르되 대화 상자에서 휴지통 아이콘을 선택합니다. 같은 최상위 그룹의 다른 하위 그룹에 있는 보안 정책 프로젝트나 완전히 다른 최상위 그룹의 보안 정책 프로젝트에 연결할 수 있습니다. 다만 파이프라인 실행 정책을 강제 적용하는 경우, 파이프라인을 트리거하려면 사용자에게 정책에서 참조하는 CI/CD 구성이 담긴 프로젝트에 대한 읽기 권한 이상이 있어야 합니다.

연결된 보안 정책 프로젝트 보기#

프로젝트 정책 페이지에 접근할 수 있으나 프로젝트 소유자가 아닌 사용자에게는 연결된 보안 정책 프로젝트로 이동하는 버튼이 대신 표시됩니다.

보안 정책 프로젝트는 둘 이상의 그룹 또는 프로젝트에 연결할 수 있습니다. 연결된 그룹이나 프로젝트 중 한 곳에서 보안 정책을 볼 수 있는 사용자는 다른 연결된 그룹과 프로젝트에 어떤 보안 정책이 강제 적용되는지 파악할 수 있습니다.

정책 한도 변경#

히스토리

성능상의 이유로 GitLab은 보안 정책 프로젝트에 구성할 수 있는 정책 수를 제한합니다.

Warning

보안 정책 프로젝트에 현재 저장된 정책 수보다 한도를 낮추면 GitLab은 한도를 초과한 정책을 강제 적용하지 않습니다. 해당 정책을 다시 활성화하려면 가장 많은 정책을 가진 보안 정책 프로젝트의 정책 수에 맞춰 한도를 높입니다.

기본 한도는 다음과 같습니다.

정책 유형 기본 정책 한도
머지 리퀘스트 승인 정책 5
스캔 실행 정책 5
파이프라인 실행 정책 5
취약점 관리 정책 5

GitLab Self-Managed 인스턴스에서 인스턴스 관리자는 정책 유형별 최대 20개까지 인스턴스 전체의 한도를 조정할 수 있습니다. 관리자는 특정 최상위 그룹의 한도를 변경할 수도 있습니다.

인스턴스의 정책 한도 변경#

사전 요건:

  • 관리자 액세스 권한.

조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면 다음 단계를 따릅니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Security and compliance를 선택합니다.
  3. Security policies 섹션을 확장합니다.
  4. 변경할 정책 유형마다 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

최상위 그룹의 정책 한도 변경#

그룹 한도는 구성된 인스턴스 한도나 기본 인스턴스 한도를 초과할 수 있습니다. 최상위 그룹에 대해 조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면 다음 단계를 따릅니다.

Note

이 한도를 높이면 시스템 성능에 영향을 줄 수 있으며, 복잡한 정책을 많이 적용하는 경우 특히 그렇습니다.

사전 요건:

  • 관리자 액세스 권한.

최상위 그룹의 한도를 조정하려면 다음 단계를 따릅니다.

  1. 오른쪽 위 모서리에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Groups를 선택합니다.
  3. 수정할 최상위 그룹의 행에서 Edit를 선택합니다.
  4. 변경할 정책 유형마다 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

개별 그룹의 한도를 0으로 설정하면 시스템은 인스턴스 전체 기본값을 사용합니다. 이에 따라 한도가 0인 그룹도 기본 인스턴스 구성에 따라 정책을 만들 수 있습니다.

보안 정책 프로젝트 삭제#

히스토리
  • 보안 정책 프로젝트에 대한 삭제 보호가 GitLab 17.8에서 reject_security_policy_project_deletion이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • 보안 정책 프로젝트를 포함한 그룹에 대한 삭제 보호가 GitLab 17.9에서 reject_security_policy_project_deletion_groups라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • 보안 정책 프로젝트와 이를 포함한 그룹에 대한 삭제 보호가 GitLab 17.10에서 일반 제공됩니다. 기능 플래그 reject_security_policy_project_deletion과 reject_security_policy_project_deletion_groups는 제거되었습니다.

보안 정책 프로젝트 또는 그 상위 그룹을 삭제하려면 다른 모든 프로젝트나 그룹에서 해당 연결을 제거해야 합니다. 그렇지 않으면 연결된 보안 정책 프로젝트나 상위 그룹을 삭제하려고 할 때 오류 메시지가 표시됩니다.