Custom Roles

This page explains how to create custom Roles and Access Policies within Secberus.

Roles overview

Roles are a collection of access policies that include a set of permissions. There are predefined roles that can be assigned to users within each organization. In addition, custom roles can be created to limit a users access and privileges for specific data sources. Each user can be assigned multiple roles within each organization.

Creating custom roles

To create a custom role, first navigate to the Secberus Admin by clicking on the Organization select menu followed by Manage account.

Navigate to Roles.

Click + New role to bring up the setup screen.

Include the Name of the role, a short Description, and then select one or more Access policies that define the privileges for the role. See Creating access policies for more information.

Creating access policies

To create a new access policy, first navigate to the Secberus Admin section and select the Access policies item.

Click + New policy to bring up the Create a new access policy screen.

Include the Name of the policy and a short Description, then add the policy details in the Policy editor.

Custom access policies can be created using the YAML language. Policies will be composed of two sections: Actions and Conditions. Permissions are purely additive (there are no "deny" rules).

Key	Value
Actions	API Permissions api:datasources:create api:datasources:delete api:datasources:read api:datasources:update See complete list of api action permissions
Conditions	Attributes - category.name - framework.name - datasource.name - datasource.typeSee complete list of available attributesComparatorsString conditions: - equals: "abc123" - prefix: "PRE_" - suffix: "_SUF" - match: "bc12" - oneof: "bc123"

Example policies

Here is a simple access policy that allows full unrestricted access to a single datasource named "AWS-DS-01":

YAML

- actions:
    - api:datasources:create
    - api:datasources:read
    - api:datasources:update
    - api:datasources:delete
  conditions:
    - field: datasource.name
      value: AWS-DS-01
      comparator: match

For more complex policies, utilize multiple actions and conditions blocks:

YAML

- actions:
    - api:datasources:create
    - api:datasources:read
    - api:datasources:update
    - api:datasources:delete
  conditions:
    - field: datasource.name
      value: AWS-DS-01
      comparator: match
- actions:
    - api:exceptions:read
  conditions:
    - field: exception.name
      value: AWS-DS-01-exception
      comparator: match
- ... more ...

The value block can be constructed with multiple items. Here is a policy that allows read permissions for datasources "AWS-DS-02" and "AWS-DS-03" only for users who are in a customer SSO defined group "customer-group-1":

YAML

- actions:
    - api:datasources:read
  conditions:
    - comparator: oneof
      field: datasource.name
      value:
        - AWS-DS-02
        - AWS-DS-03
    - comparator: match
      field: user.group
      value: customer-group-1

Each logic block that contains conditions can only make reference to a service type, i.e. only datasources type:

YAML

# WRONG/INVALID
- actions:
    - api:datasources:read
    - api:exceptions:read
  conditions:
    - field: datasource.name
      value: AWS-DS-01
      comparator: match

# VALID
- actions:
    - api:datasources:read
  conditions:
    - field: datasource.name
      value: AWS-DS-01
      comparator: match
- actions:
    - api:exceptions:read
  conditions: []

Logic blocks with multiple service types are valid as long as there aren't any conditions associated with them:

yaml

# VALID
- actions:
    - api:datasources:read
    - api:exceptions:read
  conditions: []

You cannot specify the same field multiple times in a single logic block:

YAML

# WRONG/INVALID
  conditions:
    - comparator: oneof
      field: datasource.name
      value:
        - AWS-DS-02
        - AWS-DS-03
    - comparator: equals
      field: datasource.name
      value: AWS-DS-04

Certain actions are not able to be restricted by condition. The actions "api:logs:read" and "rpc:queries:execute" will not respect any associated conditions.

For example, the following policies are functionally identical:

YAML

- actions:
    - "api:logs:read"
  conditions: 
    - comparator: "match"
      field: "log.name"
      value: "*mylog*"

Will behave the exact same way as:

YAML

- actions:
    - "api:logs:read"
  conditions: []

Once you have written your policy, click Save to publish it. The policy will then be available to select from when creating and editing custom roles.

📘

Note

You can clone and edit any access policy. This is an easy way to tailor policies for your specific use cases. Navigate to any access policy, click on the more menu icon, and select Clone policy.