Skip to main content
Skip table of contents

[~10.2.7] WAC Role & Policy Guide

QueryPie WAC, like other QueryPie products, provides Role-Based Access Control (RBAC).

This document provides information on WAC Roles and Policies applicable to versions 10.2.7 and earlier.

WAC Roles and Policies

  • A Policy is a specification, written in YAML format, that describes how to control access to resources registered in WAC.

    • It includes allowing or blocking access to web app resources.

  • A Role is an object that defines what a user can and cannot do.

    • Multiple policies can be assigned to a single Role; in this case, the policies are combined with an OR condition.

    • If multiple policies exist for the same Web App and sub-path, Deny policies take precedence over Allow policies.

  • Users can be assigned multiple Roles but can only select and use one at a time.

Warning

When all policies included in a Role are consolidated, at least one Allow policy must remain.

A Role consisting only of Deny policies does not grant any app permissions and therefore cannot be used normally.

Basic Structure of WAC YAML Policies

WAC policies are written in YAML format, and their basic structure is as follows:

Category

Property

Required

Description

Valid Values

apiVersion

-

REQUIRED

Version of the YAML code.

Managed by the system; no modification needed.

webApp.rbac.querypie.com/v1

kind

-

REQUIRED

Type of the YAML code.

Managed by the system; no modification needed.

WacPolicy

spec:
<effect>

-

REQUIRED

Detailed rules within the policy (allow or deny).

allow, deny

 

resources

REQUIRED

Specifies resources to allow/deny access to.

webApp, urlPaths

 

conditions

OPTIONAL

Detailed conditions for applying rules

(Currently only available for spec: allow).

urlPathTags, userAttributes, ipAddresses

The QueryPie WAC Policy YAML syntax required for policy creation is described below.

spec: <effect> REQUIRED

Specifies whether the specific rules of the policy are to allow or deny access. Supports spec: allow or spec: deny.

  1. A single policy can contain at most one allow block and one deny block.

  2. If deny and allow are declared for the same element within a policy, deny takes precedence.

Resources REQUIRED

Specifies the web app resources for which to set allow or block policies. It has webApp and urlPaths as sub-properties.

resources is permitted in both spec: allow and spec: deny.

webApp REQUIRED

Enter the name of the web app resource defined in QueryPie.

  1. The web app must be explicitly specified; wildcards or regular expressions are not allowed.

    • webApp: "QueryPie" (O)

    • webApp: "*Query*" (X)

    • webApp: "QueryPie$" (X)

  2. Multiple web apps can be listed within a single spec.

CODE 
spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: 
          - "/general-settings/user-management"
          - "/database-settings/policies"
      - webApp: "QueryPie Customer Portal"

  1. The web app name must satisfy the following conditions:

    • Maximum 120 characters.

    • Only uppercase/lowercase alphabets (case-sensitive), numbers, and some special characters (_, -, (, ), [, ]) are allowed.

    • Spaces are allowed.

    • Must start and end with an uppercase/lowercase alphabet or a number.

    • Cannot be duplicated.

urlPaths OPTIONAL

Specifies the sub-paths of a particular web app resource to which the policy applies.

  • Only sub-paths registered for the Web App (typically managed under Admin > Web Apps) can be listed.

  • To allow or deny all sub-paths of a web app, including the Base URL, use one of the following methods:

    1. Do not include the urlPaths line.

      • e.g., Allow access to all paths of QueryPie Web Admin:

        CODE 
        spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"

    2. Write it as urlPaths: [].

      1. e.g., Deny access to all paths of QueryPie Web Admin:

        CODE 
        spec:
  deny:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: []

  • When a specific sub-path is entered, the policy applies to that path and all its subsequent sub-paths.

    • Sub-paths are listed as a list, and multiple entries are allowed.

      • e.g., Allow access to /general-settings/user-management and /general-settings/user-management/*, and /kubernetes-settings and /kubernetes-settings/* of Querypie Web Admin:

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

    • A parent path and its more specific sub-path cannot be entered simultaneously.

      • e.g., Cannot simultaneously enter /general-settings and /general-settings/user-management for Querypie Web Admin:

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

To enter specific sub-paths in urlPaths, Path Management must be enabled in the Web App details. An error will occur if an unregistered sub-path is entered.

  1. Wildcards or regular expressions are not supported.

    • "/*-settings" (X)

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

  2. If Deny and Allow policies overlap for the same resource (and sub-path), the Deny policy takes precedence.

Conditions OPTIONAL

conditions define criteria to narrow the scope of resources to which a rule applies. Three types of conditions can be specified: urlPathTags, userAttributes, and ipAddresses.

conditions are syntactically allowed only in spec:allow.

conditions are syntactically allowed only in spec:allow.

urlPathTags OPTIONAL

Limits the scope of resources allowed by a rule, based on tags assigned in Path Management of the Web App.

  1. Tags are case-sensitive, and multiple tags can be entered.

    • If multiple tags with the same Key are entered, they operate under an OR condition.

      • e.g., Allow access to paths tagged with access: admin OR access: user:

        CODE 
        urlPathTags: 
  "access": "admin"
  "access": "user"

    • If multiple tags with different Keys are entered, they operate under an AND condition.

      • e.g., Allow access to paths tagged with access: admin AND type: general:

        CODE 
        urlPathTags: 
  "access": "admin"
  "type": "general"

  2. Works in conjunction with resources[].urlPaths.

    • If the target urlPath of the web app resource is not specified:

      • All registered sub-paths that have the specified urlPathTag are allowed.

      • e.g., For Web App “QueryPie Web Admin”, allow access only to paths among all registered sub-paths in Path Management that are tagged with access: admin:

        CODE 
        spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: []
    conditions:
      urlPathTags:
        "access": "admin"

    • If the target urlPath of the web app resource is specified:

      • Only those specified paths that also have the urlPathTag are allowed.

      • e.g., For Web App “QueryPie Web Admin”, allow access only to paths specified in resources[].urlPaths that are also tagged with access: admin in Path Management:

        CODE 
        spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: 
          - "/general-settings/user-management"
          - "/database-settings/policies"
    conditions:
      urlPathTags:
        "access": "admin"

    • If the target urlPath of the web app resource is specified, but no matching urlPathTag exists within that scope:

      • No path is allowed, as no urlPath matches the condition.

userAttributes OPTIONAL

Limits the scope of users allowed resource access by a rule, based on QueryPie user attributes.

User attributes can be viewed on the user details page in the Administrator > General > Users menu. Attributes for users added in QueryPie can be added/modified/deleted on the details page, while attributes for users added via IdP synchronization can be changed in the user directory (e.g., Okta, LDAP).

Attribute information is case-sensitive, and multiple attributes can be entered.

  • If multiple attributes with the same Key are entered, they operate under an OR condition.

    • e.g., Allow access for users whose department (department) is PM OR QA:

      CODE 
      userAttributes: 
  "department": "PM"
  "department": "QA"

  • If multiple attributes with different Keys are entered, they operate under an AND condition.

    • e.g., Allow access for users whose department (department) is PM AND title (title) is Manager

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

ipAddresses OPTIONAL

Defines a list of IP access control conditions for resources, in single IP or CIDR format.

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

If not defined separately, the default is to allow all (0.0.0.0/0).

Recommended Usage Patterns

Allow All + Deny Some

The most basic usage is to create an 'allow all' policy and separate 'deny' policies for specific purposes, then assign them to a single Role.

For example, configure policies as follows:

  1. All Allow policy: Allows access to all sub-links, including services and admin consoles.

  2. Service A Console Deny policy: e.g., deny access to admin console A.

  3. Service B Console Deny policy: e.g., deny access to admin console B.

Then, combine policies per Role:

  1. Role for general users:

    1. Policy 1 (All Allow) + Policy 2 (Deny A) + Policy 3 (Deny B) = Access only to services (A and B consoles are denied).

  2. Role for Service A administrators:

    1. Policy 1 (All Allow) + Policy 3 (Deny B) = Access only to services and admin console A (B console is denied).

  3. Role for Service B administrators:

    1. Policy 1 (All Allow) + Policy 2 (Deny A) = Access only to services and admin console B (A console is denied).

This pattern can be used when leaving access open for unidentified sub-paths does not pose a problem.

Allow Some + Deny Some

If access to unidentified sub-paths must not be allowed, the allowed paths must be clearly specified.

  1. Register all paths requiring access in Path Management and assign appropriate Path Tags.

  2. When configuring policies, use conditions such as tags, user attributes, and IP addresses.

    1. Even if urlPaths for the controlled web app are specified as all-inclusive (e.g., urlPaths: [] or omitted), if tag conditions are applied, the policy will only target paths registered in Path Management that match those tags.

    2. If necessary, you can specify the scope of users allowed web app access using user attributes, IP addresses, etc.

Warning

When using the 'allow some' pattern, landing pages essential for normal website use (e.g., login pages, redirect pages) must be configured as separate policies and included in the Role.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close