InfoGrab Docs

내부 권한 그룹

요약

내부 권한 그룹은 YAML 기반의 구성 파일로, 내부 리소스 상태에 따라 함께 활성화되거나 비활성화되는 권한들의 논리적 그룹을 정의합니다. 내부 권한 그룹은 config/authz/permission_groups/internal/ 아래의 YAML 파일로 정의됩니다.

내부 권한 그룹은 YAML 기반의 구성 파일로, 내부 리소스 상태에 따라 함께 활성화되거나 비활성화되는 권한들의 논리적 그룹을 정의합니다. 예를 들어 그룹이 아카이브된 경우와 같이 특정 조건이 충족될 때 집합적으로 방지(또는 활성화)되어야 하는 권한 집합을 중앙에서 관리할 수 있습니다.

작동 방식#

내부 권한 그룹은 config/authz/permission_groups/internal/ 아래의 YAML 파일로 정의됩니다. 각 파일에는 설명과 권한 이름 목록이 포함됩니다. 런타임에 Authz::PermissionGroups::Internal 클래스가 이 파일들을 로드하고 식별자로 그룹을 검색하는 조회 API를 제공합니다.

명명 규칙#

내부 권한 그룹의 식별자는 config/authz/permission_groups/internal/ 디렉토리를 기준으로 한 파일 경로에서 파생됩니다:

  • 디렉토리 이름은 콜론으로 구분된 접두사가 됩니다.
  • 파일 이름(확장자 없음)이 최종 세그먼트가 됩니다.

예를 들어, config/authz/permission_groups/internal/group/archived.yml은 식별자 group:archived를 생성합니다.

YAML 파일 구조#

각 YAML 파일에는 다음이 포함되어야 합니다:

  • description: 이러한 권한이 적용될 때에 대한 사람이 읽을 수 있는 설명.
  • permissions: 문자열로 된 권한(ability) 이름 목록.

예시(config/authz/permission_groups/internal/group/archived.yml):

description: Permissions that are disabled when a group is archived
permissions:
  - activate_group_member
  - admin_build
  - create_projects
  - push_code
  # ... 추가 권한

정책에서 내부 권한 그룹 사용#

DeclarativePolicy 정책에서 내부 권한 그룹을 사용하려면 그룹 식별자로 Authz::PermissionGroups::Internal.get을 호출하고 반환된 권한을 prevent 규칙으로 스플랫하십시오:

# app/policies/group_policy.rb

condition(:archived, scope: :subject) { @subject.self_or_ancestors_archived? }

rule { archived }.policy do
  prevent(*Authz::PermissionGroups::Internal.get('group:archived').permissions)
end

이렇게 하면 archived 조건이 참일 때 나열된 모든 권한이 방지되어, 정책 파일 전체에 긴 인라인 prevent 호출 목록을 유지할 필요가 없어집니다.

새 내부 권한 그룹 생성#

  1. YAML 파일 생성. config/authz/permission_groups/internal/ 아래에 새 .yml 파일을 추가합니다. 리소스 유형별로 네임스페이스를 지정하려면 디렉토리를 사용하십시오:

    config/authz/permission_groups/internal/<resource>/<subresource>/<name>.yml
    

    예를 들어, 프로젝트가 잠겼을 때 방지할 권한을 정의하려면:

    # config/authz/permission_groups/internal/project/locked.yml
    description: Permissions that are disabled when a project is locked
    permissions:
      - push_code
      - create_merge_request_from
      - admin_merge_request
    
  2. 정책에서 참조. 파일 경로에서 파생된 식별자를 사용하십시오(이 예시에서는 project:locked):

    # app/policies/project_policy.rb
    
    condition(:locked, scope: :subject) { @subject.locked? }
    
    rule { locked }.policy do
      prevent(*Authz::PermissionGroups::Internal.get('project:locked').permissions)
    end
    

내부 권한 그룹 사용 시기#

다음과 같은 경우 내부 권한 그룹을 사용하십시오:

  • 리소스 상태 변경(예: 아카이브 또는 잠금)으로 인해 많은 권한을 한꺼번에 비활성화해야 하는 경우.
  • 동일한 권한 집합이 여러 위치(정책, 사양 또는 공유 예시)에서 참조되어야 하는 경우.
  • 정책 파일 전체에 prevent 호출을 분산시키는 것보다 조건이 영향을 미치는 권한에 대한 단일 진실의 원천을 원하는 경우.

다음과 같은 경우에는 내부 권한 그룹을 사용하지 않는 것이 좋습니다:

내부 권한 그룹

원문 보기
요약

내부 권한 그룹은 YAML 기반의 구성 파일로, 내부 리소스 상태에 따라 함께 활성화되거나 비활성화되는 권한들의 논리적 그룹을 정의합니다. 내부 권한 그룹은 config/authz/permission_groups/internal/ 아래의 YAML 파일로 정의됩니다.

내부 권한 그룹은 YAML 기반의 구성 파일로, 내부 리소스 상태에 따라 함께 활성화되거나 비활성화되는 권한들의 논리적 그룹을 정의합니다. 예를 들어 그룹이 아카이브된 경우와 같이 특정 조건이 충족될 때 집합적으로 방지(또는 활성화)되어야 하는 권한 집합을 중앙에서 관리할 수 있습니다.

작동 방식#

내부 권한 그룹은 config/authz/permission_groups/internal/ 아래의 YAML 파일로 정의됩니다. 각 파일에는 설명과 권한 이름 목록이 포함됩니다. 런타임에 Authz::PermissionGroups::Internal 클래스가 이 파일들을 로드하고 식별자로 그룹을 검색하는 조회 API를 제공합니다.

명명 규칙#

내부 권한 그룹의 식별자는 config/authz/permission_groups/internal/ 디렉토리를 기준으로 한 파일 경로에서 파생됩니다:

  • 디렉토리 이름은 콜론으로 구분된 접두사가 됩니다.
  • 파일 이름(확장자 없음)이 최종 세그먼트가 됩니다.

예를 들어, config/authz/permission_groups/internal/group/archived.yml은 식별자 group:archived를 생성합니다.

YAML 파일 구조#

각 YAML 파일에는 다음이 포함되어야 합니다:

  • description: 이러한 권한이 적용될 때에 대한 사람이 읽을 수 있는 설명.
  • permissions: 문자열로 된 권한(ability) 이름 목록.

예시(config/authz/permission_groups/internal/group/archived.yml):

description: Permissions that are disabled when a group is archived
permissions:
  - activate_group_member
  - admin_build
  - create_projects
  - push_code
  # ... 추가 권한

정책에서 내부 권한 그룹 사용#

DeclarativePolicy 정책에서 내부 권한 그룹을 사용하려면 그룹 식별자로 Authz::PermissionGroups::Internal.get을 호출하고 반환된 권한을 prevent 규칙으로 스플랫하십시오:

# app/policies/group_policy.rb

condition(:archived, scope: :subject) { @subject.self_or_ancestors_archived? }

rule { archived }.policy do
  prevent(*Authz::PermissionGroups::Internal.get('group:archived').permissions)
end

이렇게 하면 archived 조건이 참일 때 나열된 모든 권한이 방지되어, 정책 파일 전체에 긴 인라인 prevent 호출 목록을 유지할 필요가 없어집니다.

새 내부 권한 그룹 생성#

  1. YAML 파일 생성. config/authz/permission_groups/internal/ 아래에 새 .yml 파일을 추가합니다. 리소스 유형별로 네임스페이스를 지정하려면 디렉토리를 사용하십시오:

    config/authz/permission_groups/internal/<resource>/<subresource>/<name>.yml
    

    예를 들어, 프로젝트가 잠겼을 때 방지할 권한을 정의하려면:

    # config/authz/permission_groups/internal/project/locked.yml
    description: Permissions that are disabled when a project is locked
    permissions:
      - push_code
      - create_merge_request_from
      - admin_merge_request
    
  2. 정책에서 참조. 파일 경로에서 파생된 식별자를 사용하십시오(이 예시에서는 project:locked):

    # app/policies/project_policy.rb
    
    condition(:locked, scope: :subject) { @subject.locked? }
    
    rule { locked }.policy do
      prevent(*Authz::PermissionGroups::Internal.get('project:locked').permissions)
    end
    

내부 권한 그룹 사용 시기#

다음과 같은 경우 내부 권한 그룹을 사용하십시오:

  • 리소스 상태 변경(예: 아카이브 또는 잠금)으로 인해 많은 권한을 한꺼번에 비활성화해야 하는 경우.
  • 동일한 권한 집합이 여러 위치(정책, 사양 또는 공유 예시)에서 참조되어야 하는 경우.
  • 정책 파일 전체에 prevent 호출을 분산시키는 것보다 조건이 영향을 미치는 권한에 대한 단일 진실의 원천을 원하는 경우.

다음과 같은 경우에는 내부 권한 그룹을 사용하지 않는 것이 좋습니다: