WAC Role & Policy Guide

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

This document provides guidance on WAC roles and policies.

WAC Roles and Policies

A policy is a specification that describes how to control access to resources registered in WAC, written in YAML format.
- It includes allowing or denying access to web app resources.
A role is an object that defines what a user can and cannot do.
- A single role can have multiple policies assigned, and in this case, the policies are combined using an OR condition.
- If multiple policies exist for the same web app and sub-path, a Deny policy takes precedence over an Allow policy.
A user can be assigned multiple roles but can only select and use one at a time.

Note

When all policies included in a role are combined, at least one Allow policy must remain. A role consisting solely of Deny policies will not grant any app permissions, making normal use impossible.

Basic Structure of WAC YAML Policy

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 Written YAML Code This is a system-managed value and does not require modification.	`webApp.rbac.querypie.com/v1`
`kind`	-	REQUIRED	Type of the Written YAML Code This is a system-managed value and does not require modification.	`WacPolicy`
`spec:` `<effect>`	-	REQUIRED	Detailed Rules in the Policy (Allow or Deny)	`allow`, `deny`
	`resources`	REQUIRED	Specify the Resources to Allow/Deny Access	`webApp`, `urlPaths`
	`conditions`	OPTIONAL	Detailed Conditions for Applying the Rule (Only applicable for `spec: allow`)	`urlPathTags`, `userAttributes`, `ipAddresses`

Below is the syntax for writing a QueryPie WAC Policy YAML.

spec: <effect> REQUIRED

Specifies whether the specific rule in the policy is allowed or denied. It supports spec: allow or spec: deny.

A policy can have at most one allow and one deny.
If both deny and allow are declared for the same element within the policy, deny takes precedence.

Resources REQUIRED

Specifies the web app resources for which the allow or deny policy is to be set. It includes webApp and urlPaths as sub-elements.

resources is allowed in both spec: allow and spec: deny

webApp REQUIRED

Enter the web app resource name defined in QueryPie.

The web app must be explicitly specified, and wildcards or regular expressions are not allowed.
- - webApp: "QueryPie" (O)
- - webApp: "*Query*" (X)
- - webApp: "QueryPie$" (X)

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"

The web app name must meet the following conditions:
- Maximum length of 120 characters
- Only uppercase and lowercase alphabet letters (case-sensitive), numbers, and certain special characters (_, -, (, ), [, ]) are allowed
- Spaces are allowed
- The name must start and end with an uppercase or lowercase letter or a number
- Duplicates are not allowed

urlPaths OPTIONAL

Specifies the sub-paths of the specific web app resource where the policy is to be applied.

Only subpaths registered under Admin > Web App can be added.
To allow or deny access to all sub-paths within the web app, including the Base URL, follow the method below.
- Do not include the urlPaths field.
  - Example: Allow access to the entire path of QueryPie Web Admin.
    CODE
```
spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
```
- Write as urlPaths: [].
  - Example: Deny access to the entire path of QueryPie Web Admin.
    CODE
```
spec:
  deny:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: []
```
When specifying a particular sub-path, the policy will be applied to the entered path and all its sub-paths.
- Sub-paths are listed as a list, and multiple entries can be added.
  - Example: Allow access to /general-settings/user-management and /general-settings/user-management/*, as well as /kubernetes-settings and /kubernetes-settings/* for QueryPie Web Admin.
    CODE
```
spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: 
          - "/general-settings/user-management"
          - "/kubernetes-settings"
```
- Sub-paths and their detailed paths cannot be entered simultaneously.
  - Example: It is not allowed to enter both /general-settings and /general-settings/user-management simultaneously for QueryPie Web Admin.
    CODE
```
spec:
  allow:
    resources:
      - webApp: "Querypie Web Admin"
        urlPaths: 
          - "/general-settings"
          - "/general-settings/user-management"
```

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

Wildcards or regular expressions are not supported.
- "/*-settings" (X)
- "^/database-settings/policies/data-.*$" (X)
If a deny policy and an allow policy overlap for the same resource (and sub-path), the deny policy takes precedence.

Conditions OPTIONAL

conditions define the criteria to narrow the scope of the rule's application. It is possible to specify three types of conditions: urlPathTags, userAttributes, and ipAddresses.

conditions are syntactically allowed only in spec: allow.

urlPathTags OPTIONAL

Limits the scope of resources allowed by the rule based on tags granted in the Web App's Path Management.

Tags are case-sensitive, and multiple tags can be entered.
- If multiple tags with the same key are entered, they will function with an OR condition.
  - Example: Allow access to paths where access: admin or access: user is granted.
    CODE
```
urlPathTags: 
  "access": "admin"
  "access": "user"
```
- If multiple tags with different keys are entered, they will function with an AND condition.
  - Example: Allow access to paths where access: admin and type: general are both granted.
    CODE
```
urlPathTags: 
  "access": "admin"
  "type": "general"
```
It works in conjunction with resources[].urlPaths.
- If the target urlPath of the web app resource is not specified:
  - It allows all paths with a urlPathTag from all registered sub-paths.
  - Example: For the Web App "QueryPie Web Admin," allow access only to paths with the access: admin tag from all sub-paths registered in Path Management.
    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 the paths with a urlPathTag among the specified paths are allowed.
  - Example: For the Web App "QueryPie Web Admin," allow access only to the paths specified in resources[].urlPaths that have the access: admin tag assigned 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 the scope:
  - Since no urlPath matching the condition exists, no paths will be allowed.

userAttributes OPTIONAL

It limits the scope of users who are allowed to access resources based on the attributes of the QueryPie user.

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

Attribute information is case-sensitive, and multiple entries can be provided.

If multiple attributes with the same key are entered, they will function with an OR condition.
- Example: Allow access to users whose department is either PM or QA.
  CODE
```
userAttributes: 
  "department": "PM"
  "department": "QA"
```
If multiple attributes with different keys are entered, they will function with an AND condition.
- Example: Allow access to users whose department is PM and title is Manager.
  CODE
```
userAttributes: 
  "department": "PM"
  "title": "Manager"
```

ipAddresses OPTIONAL

The IP access control conditions for the resource are defined in a list using either a single IP or CIDR format.

CODE

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

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

Recommended Usage Method

Allow All + Deny Some

The most basic usage method is to create an Allow All policy and separate Deny policies for specific purposes, then assign them to a single role.

For example, the policies are configured as follows:

All Allow policy (access to all sub-links, including services and management consoles)
Service A Console Deny policy (e.g., block access to Management Console A)
Service B Console Deny policy (e.g., block access to Management Console B)

Then, policies are combined for each role:

General User Role
1. Policy 1 + 2 + 3 = Access only to services
Service A Admin Role
1. Policy 1 + 3 = Access only to service and Management Console A
Service B Admin Role
1. Policy 1 + 2 = Access only to service and Management Console B

This pattern can be used when leaving access open to unidentified sub-paths is not problematic.

Allow Some + Deny All

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

All paths that require access in Path Management should be registered, and Path Tags should be appropriately assigned.
When configuring policies, conditions such as tags, user attributes, and IPs are used.
1. Even if the urlPaths of the controlled web app are specified in full, when tag conditions are applied, the policy will be set only for the paths registered in Path Management.
2. If necessary, user attributes or IPs can be used to specify the range of users allowed to access the web app.

Note

When using some allowed patterns, it is essential to configure the landing pages that are required for normal website usage as a separate policy and include them in the appropriate role.

Example: Login page, Redirect page, etc.