Member-level security

The data model serves as a facade of your data. With member-level security, you can define whether data model entities (cubes, views, and their members) are exposed to end users and can be queried via APIs & integrations.

Member-level security in Cube is similar to column-level security in SQL databases. Defining whether users have access to cubes and views is similar to defining access to database tables; defining whether they have access to dimensions and measures — to columns.

By default, all cubes, views, and their members are public, meaning that they can be accessed by any users and they are also visible during data model introspection.

Managing member-level access

You can explicitly make a data model entity public or private by setting its public parameter to true or false. This parameter is available for cubes, views, measures, dimensions, hierarchies, and segments.

In development mode and in Playground, access control checks are disabled and all public parameters are ignored. It helps you conveniently debug the data model by using private data model entities in API queries and during data model introspection.

Dynamic data models

You can also control whether a data model entity should be public or private dynamically.

In the example below, the customers view would only be visible to a subset of tenants that have the team property set to marketing in the security context:

model/views/customers.yml

views:
  - name: customers
    public: "{{ is_accessible_by_team('marketing', COMPILE_CONTEXT) }}"

model/globals.py

from cube import TemplateContext
 
template = TemplateContext()
 
@template.function('is_accessible_by_team')
def is_accessible_by_team(team: str, ctx: dict) -> bool:
  return team == ctx['securityContext'].setdefault('team', 'default')

If you'd like to keep a data model entity public but prevent access to it anyway, you can use the query_rewrite configuration option for that.

Best practices

Data access policies

You can use data access policies to manage both member-level and row-level security for different roles. With them, you can keep access control rules in one place instead of spreading them across a number of public parameters in a cube or a view.

It is recommended to use data access policies by default. You can also combine them with setting some public parameters manually for specific cases.

Cubes and views

If your data model contains both cubes and views, it's recommended to keep cubes private and only expose views to visualization tools. Doing so, you will have more control over queries that can be run against the data model.

Members

If you have measures or dimensions that are not intended to be exposed to end users, it's recommended to keep them private. Often, such auxiliary members would be used in calculated measures and dimensions.

YAML

JavaScript

cubes:
  - name: users
    sql_table: users
 
    dimensions:
      - name: first_name
        sql: first_name
        type: string
        public: false
 
      - name: initial
        sql: "LEFT({first_name}, 1)"
        type: string

Security context Row-level security