[~10.2.7] WAC Role & Policy Guide

[~10.2.7] WAC Role & Policy Guide

QueryPie WAC은 다른 QueryPie 제품들과 마찬가지로 RBAC(Role-Based Access Control) 을 제공하고 있습니다.

이 문서에서는 10.2.7 이하 버전에 적용된 WAC 역할과 정책에 대하여 안내합니다.

WAC 역할과 정책

  • 정책(Policy)은 WAC에 등록된 리소스에 대해 어떻게 접근을 제어할지 기술한 명세로, YAML 형식으로 작성합니다.

    • 웹 앱 리소스에 대한 허용 또는 차단이 포함됩니다.

  • 역할(Role)은 사용자가 무엇을 할 수 있고 할 수 없는지 정의하는 오브젝트입니다.

    • 역할 하나 안에는 여러 개의 정책을 할당할 수 있으며, 이 경우 정책들은 OR 조건으로 합쳐집니다.

    • 동일한 Web App 및 하위 경로에 대한 여러 개의 정책이 존재할 경우 차단(Deny) 정책이 허용(Allow) 정책보다 우선합니다.

  • 사용자는 여러 개의 역할을 할당받을 수 있지만 한 번에 한 가지만 선택하여 사용합니다.

주의

역할에 포함된 정책을 모두 통합하였을 때, 최소 1개의 허용 정책이 남아있어야 합니다.
차단 정책만으로 구성된 역할은 아무런 앱 권한도 부여하지 않으므로 정상적인 사용이 불가합니다.

WAC YAML 정책의 기본 구조

WAC의 정책은 YAML 형식으로 작성되며, 그 기본 구조는 다음과 같습니다.

Category

Property

Required

Description

Valid Values

Category

Property

Required

Description

Valid Values

apiVersion

-

required

작성된 YAML Code의 버전

시스템에서 관리하는 값으로, 수정 불필요

webApp.rbac.querypie.com/v1

kind

-

required

작성된 YAML Code의 종류

시스템에서 관리하는 값으로, 수정 불필요

WacPolicy

spec:
<effect>

-

required

정책 내 세부 규칙 (허용 또는 거부)

allow, deny

 

resources

required

접근을 허용/거부할 리소스 지정

webApp, urlPaths

 

conditions

OPTIONAL

규칙 적용 대상에 대한 세부 조건

(현재 spec: allow 에서만 사용 가능)

urlPathTags, userAttributes, ipAddresses

아래에서 정책 작성에 필요한 QueryPie WAC Policy YAML 문법을 안내합니다.

spec: <effect> required

정책의 구체적인 규칙의 허용 또는 거부 여부를 지정합니다. spec: allow 또는 spec: deny 를 지원합니다.

  1. 한 정책에는 최대 1회의 allow, 1회의 deny 만이 존재할 수 있습니다.

  2. 정책 내에서 동일한 요소에 대해 denyallow가 동시에 선언된 경우 deny가 우선입니다.

Resources required

허용 또는 차단 정책을 설정하려는 웹 앱 리소스를 지정합니다. 하위에 webApp, urlPaths를 가집니다.

resourcesspec: allow, spec: deny 에서 모두 허용됩니다.

webApp required

QueryPie에 정의한 웹앱 리소스명을 입력합니다.

  1. 명시적으로 웹앱을 특정해야 하며, 와일드카드나 정규식을 허용하지 않습니다.

    • - webApp: "QueryPie" (O)

    • - webApp: "*Query*" (X)

    • - webApp: "QueryPie$" (X)

  2. 하나의 spec 안에서 여러 개의 웹 앱을 나열할 수 있습니다.

    spec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/database-settings/policies" - webApp: "QueryPie Customer Portal"
  3. 웹 앱 이름은 다음의 조건을 만족해야 합니다.

    • 글자 수 최대 120자

    • 알파벳 대소문자 (case-sensitive), 숫자 및 일부 특수기호 (_, -, (, ), [, ]) 만 허용

    • 공백 허용

    • 시작과 끝은 알파벳 대소문자 또는 숫자로 제한

    • 중복 불가

urlPaths OPTIONAL

정책을 적용하려는 특정 웹앱 리소스의 하위 경로를 특정합니다.

  1. Admin > Web App 에 등록된 하위 경로만 등록이 가능합니다.

  2. Base URL을 포함하여, 웹 앱에 존재하는 모든 하위 경로에 대해 허용 또는 거부하는 방법은 다음과 같습니다.

    • urlPaths 행을 작성하지 않습니다.

      • 예: QueryPie Web Admin 의 전체 경로에 대해 접근 허용

        spec: allow: resources: - webApp: "Querypie Web Admin"
    • urlPaths: [] 으로 작성합니다.

      • 예: QueryPie Web Admin 의 전체 경로에 대해 접근 차단

        spec: deny: resources: - webApp: "Querypie Web Admin" urlPaths: []
  3. 특정 하위 경로 입력시, 입력한 경로와 해당 경로의 모든 하위 경로에 정책이 적용됩니다.

    • 하위 경로는 리스트로 나열하며, 여러 개를 입력할 수 있습니다.

      • 예: QueryPie Web Admin 의 /general-settings/user-management/general-settings/user-management/*, 그리고 /kubernetes-settings/kubernetes-settings/* 에 대해 접근 허용

        spec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/kubernetes-settings"
    • 하위 경로와 이에 포함된 세부 경로를 동시에 입력할 수 없습니다.

      • 예: QueryPie Web Admin 의 /general-settings/general-settings/user-management동시에 입력 불가

        spec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings" - "/general-settings/user-management"

urlPaths에 특정 하위 경로를 입력하려면 Web App 상세 정보에서 Path Management 활성화가 필요합니다. 등록되지 않은 하위 경로 입력 시 오류가 발생합니다.

  1. 와일드카드 또는 정규표현식은 지원되지 않습니다.

    • "/*-settings" (X)

    • "^/database-settings/policies/data-.*$" (X)

  2. 동일한 리소스(및 하위 경로)에 대하여 차단 정책과 허용 정책이 중첩되는 경우, 차단 정책이 우선입니다.

Conditions OPTIONAL

conditions 은 규칙 적용 대상 리소스의 범위를 좁히기 위한 조건을 정의합니다. urlPathTags, userAttributes, ipAddresses 세 종류의 조건 지정이 가능합니다.

conditions는 spec:allow에서만 문법적으로 허용됩니다.

urlPathTags OPTIONAL

Web App의 Path Management에서 부여된 태그를 기준으로 규칙에 의해 접근이 허용되는 리소스 범위를 한정합니다.

  1. 태그는 대소문자를 구분하며, 여러 개를 입력할 수 있습니다.

    • Key가 동일한 태그를 여러 개 입력 시, OR 조건으로 동작합니다.

      • 예: access: admin 또는 access: user 가 부여된 경로에 대해 접근 허용

        urlPathTags: "access": "admin" "access": "user"
    • Key가 다른 태그를 여러 개 입력 시, AND 조건으로 동작합니다.

      • 예: access: admintype: general 가 함께 부여된 경로에 대해 접근 허용

        urlPathTags: "access": "admin" "type": "general"
  2. resources[].urlPaths 와 연계되어 동작합니다.

    • 웹앱 리소스의 대상 urlPath가 명시되지 않은 경우

      • 등록된 전체 하위 경로 중 urlPathTag가 있는 경로를 모두 허용합니다.

      • 예: Web App “QueryPie Web Admin” 에 대해, Path Management에 등록된 전체 하위 경로 중 access: admin 태그가 부여된 경로에 한하여 접근 허용

        spec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: [] conditions: urlPathTags: "access": "admin"
    • 웹앱 리소스의 대상 urlPath가 명시된 경우

      • 명시된 경로들 중 urlPathTag가 있는 경로만을 허용합니다.

      • 예: Web App “QueryPie Web Admin” 에 대해, resources[].urlPaths 에 명시된 두 경로 중 Path Management에서 access: admin 태그가 부여된 경로에 한하여 접근 허용

        spec: allow: resources: - webApp: "Querypie Web Admin" urlPaths: - "/general-settings/user-management" - "/database-settings/policies" conditions: urlPathTags: "access": "admin"
    • 웹앱 리소스의 대상 urlPath가 명시되었으나 범위 내에서 매칭되는 urlPathTag가 없는 경우

      • 조건에 일치하는 urlPath가 존재하지 않으므로, 어떠한 경로도 허용하지 않습니다.

userAttributes OPTIONAL

QueryPie 사용자의 속성(attribute)을 기준으로 규칙에 의해 리소스 접근이 허용되는 사용자의 범위를 한정합니다.

사용자 속성은 Administrator > General > Users 메뉴의 사용자별 상세 페이지에서 조회할 수 있습니다. QueryPie에서 추가된 사용자의 속성은 상세 페이지에서 추가/변경/삭제 등이 가능하며, IdP 동기화에 의해 추가된 사용자의 속성은 사용자 원장(Okta, LDAP 등)에서 변경할 수 있습니다.

속성 정보는 대소문자를 구분하며, 여러 개 입력할 수 있습니다.

  • Key가 동일한 속성을 여러 개 입력 시, OR 조건으로 동작합니다.

    • 예: 부서(department)가 PM 또는 QA인 사용자에 대해 접근 허용

      userAttributes: "department": "PM" "department": "QA"
  • Key가 다른 속성을 여러 개 입력 시, AND 조건으로 동작합니다.

    • 예: 부서(department)가 PM이고, 직책(title)이 관리자인 사용자에 대해 접근 허용

      userAttributes: "department": "PM" "title": "Manager"

ipAddresses OPTIONAL

리소스에 대한 IP 접근 통제 조건 리스트를 단일IP, CIDR 형태으로 정의합니다.

ipAddresses: ["10.10.0.0/24", "10.11.10.1"]

별도로 정의하지 않은 경우, 기본값은 모두 허용(0.0.0.0/0) 입니다.

추천하는 사용 방식

전체 허용 + 일부 차단

가장 기본적인 사용법은 전체 허용 정책과 용도별 차단 정책을 별도로 생성 후 하나의 역할에 부여하는 것입니다.

예를 들어 다음과 같이 정책을 구성합니다.

  1. All Allow 정책 (서비스와 관리 콘솔을 포함한 모든 하위 링크에 접근 가능)

  2. 서비스 A 콘솔 Deny 정책 (예: 관리 콘솔 A에 대해 접근 차단)

  3. 서비스 B 콘솔 Deny 정책 (예: 관리 콘솔 B에 대해 접근 차단)

그리고 역할 별로 정책을 조합합니다.

  1. 일반 사용자용 역할

    1. 정책 1 + 2 + 3 = 서비스에만 접근 가능

  2. 서비스 A 관리자용 역할

    1. 정책 1 + 3 = 서비스 및 관리 콘솔 A에만 접근 가능

  3. 서비스 B 관리자용 역할

    1. 정책 1 + 2 = 서비스 및 관리 콘솔 B에만 접근 가능

이러한 패턴은 식별되지 않은 하위 경로에 대한 접근을 열어두더라도 문제가 없는 경우에 사용할 수 있습니다.

일부 허용 + 일부 차단

식별되지 않은 하위 경로에 대한 접근을 허용해서는 안 되는 경우, 허용 대상 경로를 명확하게 지정하여야 합니다.

  1. Path Management에 접근 허용이 필요한 모든 경로를 등록하고, Path Tag를 적절하게 부여합니다.

  2. 정책 구성 시, 태그 및 사용자 속성, IP 등의 조건을 사용합니다.

    1. 통제 대상 웹 앱의 urlPaths를 전체로 지정하더라도, 태그 조건 부여시, Path Management에 등록된 경로를 대상으로만 정책이 설정됩니다.

    2. 필요 시 사용자 속성이나 IP 등, 웹 앱 접근을 허용할 사용자의 범위를 지정할 수 있습니다.

주의

일부 허용 패턴을 사용하는 경우, 정상적인 웹 사이트 사용을 위해 반드시 진입이 필요한 랜딩 페이지들을 별도 정책으로 구성하고, 역할에 넣어주어야 합니다.

  • 예: 로그인 페이지, 리다이렉트 페이지 등