Roles and Privileges

Casabase Cube uses Snowflake identity and authorization.

Access is controlled through two related layers:

Snowflake Account Roles
        │
        ▼
Casabase Cube Application Roles

Casabase Cube ships two primary application roles:

CUBE_PUBLIC
CUBE_ADMIN

These roles determine what a user can do within Casabase Cube.

Row-level security is separate and determines which cube data a user can see.

Application Roles

Application Role	Purpose
CUBE_PUBLIC	Query and discovery
CUBE_ADMIN	Modeling and administration

CUBE_ADMIN inherits CUBE_PUBLIC, so an administrator does not need to be granted both roles.

CUBE_PUBLIC

CUBE_PUBLIC is intended for report consumers, analysts, BI service accounts, and other users who need to query Casabase Cube.

It provides query and discovery capabilities such as:

• Running cube queries
• Listing cubes
• Listing dimensions
• Searching members
• Reading supported secure views

Conceptually:

CUBE_PUBLIC
    │
    ├── Query
    ├── Discover
    ├── Search Members
    └── Read Secure Views

Grant this role to users who consume Casabase Cube but do not administer or modify the model.

Granting CUBE_PUBLIC

Application roles are granted to Snowflake account roles.

For example:

GRANT APPLICATION ROLE
    CASABASE_CUBE.CUBE_PUBLIC
TO ROLE ANALYST;

Substitute the name of your installed Casabase Cube application for:

CASABASE_CUBE

where appropriate.

Users who inherit the ANALYST Snowflake role can then inherit the Casabase Cube application role through the normal Snowflake role hierarchy.

CUBE_ADMIN

CUBE_ADMIN provides all CUBE_PUBLIC capabilities plus modeling and administration.

Administrative capabilities include:

• Creating and rebuilding dimensions
• Loading data
• Managing formulas
• Managing security rules
• Scheduling queries
• Reading the audit log
• Performing other supported administrative operations

CUBE_ADMIN should be granted only to administrators.

Conceptually:

CUBE_ADMIN
    │
    ├── Everything in CUBE_PUBLIC
    │
    ├── Modeling
    ├── Data Administration
    ├── Formula Administration
    ├── Security Administration
    ├── Scheduling
    └── Audit / Operational Administration

Granting CUBE_ADMIN

For example:

GRANT APPLICATION ROLE
    CASABASE_CUBE.CUBE_ADMIN
TO ROLE CUBE_ADMINISTRATOR;

Because CUBE_ADMIN inherits CUBE_PUBLIC, there is no need to also grant:

CUBE_PUBLIC

to the same administrator role.

Reviewing Application Role Grants

To review which account roles hold CUBE_PUBLIC:

SHOW GRANTS OF APPLICATION ROLE
    CASABASE_CUBE.CUBE_PUBLIC;

To review CUBE_ADMIN:

SHOW GRANTS OF APPLICATION ROLE
    CASABASE_CUBE.CUBE_ADMIN;

These commands are useful during periodic access reviews.

Least Privilege

Use:

CUBE_PUBLIC

for normal consumers.

Reserve:

CUBE_ADMIN

for users whose responsibilities require administrative or modeling functionality.

Conceptually:

Needs to Query Only?
      │
      ├── Yes ──► CUBE_PUBLIC
      │
      └── No
             │
             ▼
Needs to Administer?
      │
      ├── Yes ──► CUBE_ADMIN
      │
      └── No  ──► Review Requirement

Administrative access should be reviewed periodically.

Application Roles vs. Row-Level Security

Application roles and row-level security perform different functions.

CUBE_PUBLIC / CUBE_ADMIN
        │
        ▼
What can the user do?


Row-Level Security
        │
        ▼
Which cube data can the user see?

For example:

User A
├── CUBE_PUBLIC
└── Active ENTITY security rule

can query the application but is restricted to the permitted ENTITY scope.

By contrast:

User B
├── CUBE_PUBLIC
└── No active security rules

can also query the application but is unrestricted by Casabase Cube row-level security.

See Access Control for the complete security model.

Account-Level Privileges

Casabase Cube declares two account-level Snowflake privileges that are requested at installation time:

READ SESSION
EXECUTE MANAGED TASK

Both have specific operational purposes.

Privilege	Purpose
READ SESSION	Allows Casabase Cube to read Snowflake session context, including CURRENT_USER()
EXECUTE MANAGED TASK	Allows supported scheduled operations to run as Snowflake serverless managed tasks

READ SESSION

READ SESSION is required for functionality that depends on the executing Snowflake user.

This includes:

• Row-level security
• Query Builder user context

without READ SESSION, security rules cannot be evaluated because Casabase Cube cannot read CURRENT_USER().

Grant it with:

GRANT READ SESSION
ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

Why READ SESSION Matters

Casabase Cube row-level security is user-specific.

Conceptually:

Snowflake Session
      │
      ▼
CURRENT_USER()
      │
      ▼
Casabase Cube Security Rules
      │
      ▼
Effective User Scope

Without access to session context, the application cannot determine which user’s security rules should be applied.

This privilege does not itself define security rules. It enables the application to evaluate the current user against the configured rules.

EXECUTE MANAGED TASK

EXECUTE MANAGED TASK allows scheduled Casabase Cube operations to execute as Snowflake serverless tasks.

identifies two primary uses:

• Scheduled dimension rebuilds
• Saved Query materialization

These can run without requiring a customer-owned warehouse for the task execution.

Grant it with:

GRANT EXECUTE MANAGED TASK
ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

Scheduling Dependency

Without:

EXECUTE MANAGED TASK

the application’s supported serverless scheduling functionality cannot operate as designed.

Conceptually:

Saved Query Schedule
        │
        ▼
Snowflake Managed Task
        │
        ▼
Scheduled Materialization

and:

Scheduled Dimension Rebuild
        │
        ▼
Snowflake Managed Task
        │
        ▼
Dimension Processing

See Operational Tasks and Saved Queries.

Verifying Application Privileges

To review the account-level privileges currently granted to the installed application:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

This is useful during:

• Initial installation validation
• Security reviews
• Upgrade validation
• Troubleshooting
• Compliance reviews

Source Data Access

Casabase Cube cannot automatically read arbitrary objects in the customer’s Snowflake environment.

The customer explicitly grants access to the source objects each cube requires.

Typical source objects include:

• Dimension source tables
• Fact tables
• Snowflake stages containing import files

The application should be granted only the objects needed by the cubes it operates.

Example Source Grants

For example:

GRANT USAGE
ON DATABASE SOURCE_DB
TO APPLICATION CASABASE_CUBE;

GRANT USAGE
ON SCHEMA SOURCE_DB.FINANCE
TO APPLICATION CASABASE_CUBE;

GRANT SELECT
ON TABLE SOURCE_DB.FINANCE.GL_FACT
TO APPLICATION CASABASE_CUBE;

For a stage:

GRANT READ
ON STAGE SOURCE_DB.FINANCE.IMPORT_STAGE
TO APPLICATION CASABASE_CUBE;

Source Access Principle

Grant:

USAGE
SELECT
READ

where required.

Do not grant ownership merely to allow Casabase Cube to consume source data.

The application reads customer source tables and builds its own managed structures; it does not need to modify the source tables themselves.

Conceptually:

Customer Source Table
       │
       │ SELECT
       ▼
Casabase Cube
       │
       ▼
Application-Managed Structures

rather than:

Casabase Cube
       │
       ▼
Modify Customer Source Table

Least-Privilege Source Grants

A useful source-access model is:

Does Cube Need This Database?
        │
        └── Grant USAGE


Does Cube Need This Schema?
        │
        └── Grant USAGE


Does Cube Read This Table?
        │
        └── Grant SELECT


Does Cube Read This Stage?
        │
        └── Grant READ

Avoid granting broad access to unrelated customer data simply because Casabase Cube is installed in the account.

Optional AI Privilege

Cortex Agent and MCP integration require an additional Snowflake database-role grant:

GRANT DATABASE ROLE
    SNOWFLAKE.CORTEX_USER
TO APPLICATION CASABASE_CUBE;

This privilege is optional.

If AI features are not used, it does not need to be granted, and other Casabase Cube functionality does not depend on it.

AI Privilege Model

Conceptually:

Core Casabase Cube
      │
      ├── READ SESSION
      └── EXECUTE MANAGED TASK


Optional AI Features
      │
      └── SNOWFLAKE.CORTEX_USER

This keeps AI access separate from the permissions needed for normal cube modeling, querying, security, and scheduling.

Privilege Summary

The main privileges associated with Casabase Cube are:

Type	Privilege / Role	Purpose
Application role	CUBE_PUBLIC	Query and discovery
Application role	CUBE_ADMIN	Modeling and administration
Account privilege	READ SESSION	Current-user context for security and Query Builder
Account privilege	EXECUTE MANAGED TASK	Serverless scheduling
Source grant	USAGE	Access required database/schema namespaces
Source grant	SELECT	Read source tables
Source grant	READ	Read staged import files
Optional database role	SNOWFLAKE.CORTEX_USER	Cortex Agent and MCP functionality

Role and Privilege Boundaries

It is useful to distinguish four separate access questions.

Can the application see the source object?

Controlled by customer grants such as:

USAGE
SELECT
READ

Can the user access Casabase Cube?

Controlled through a Snowflake account role that inherits:

CUBE_PUBLIC

or:

CUBE_ADMIN

Can the user administer Casabase Cube?

Controlled through:

CUBE_ADMIN

Which cube data can the user see?

Controlled through Casabase Cube row-level security.

Conceptually:

Source Grants
      │
      └── What can the application read?


Application Roles
      │
      └── What can the user do?


Security Rules
      │
      └── What cube data can the user see?


Account Privileges
      │
      └── What platform capabilities can the app use?

Keeping these boundaries separate makes access reviews much clearer.

Reviewing Administrative Capability

During a periodic access review:

SHOW GRANTS OF APPLICATION ROLE
    CASABASE_CUBE.CUBE_ADMIN;

The result identifies Snowflake account roles that have administrative Casabase Cube capability.

Administrators should then determine which users inherit those account roles using the organization’s normal Snowflake role review process.

Reviewing Consumer Access

Similarly:

SHOW GRANTS OF APPLICATION ROLE
    CASABASE_CUBE.CUBE_PUBLIC;

shows the account roles that receive query and discovery access.

Remember that because CUBE_ADMIN inherits CUBE_PUBLIC, administrative users already receive consumer functionality through the inheritance chain.

Reviewing Account Grants

Use:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

to verify the platform privileges and object grants available to the Native App.

A review should confirm that:

• READ SESSION is present where row-level security and Query Builder are used.
• EXECUTE MANAGED TASK is present where scheduling is required.
• Source-object access follows least privilege.
• SNOWFLAKE.CORTEX_USER is granted only when AI features are required.

Initial Access Checklist

For a new installation:

[ ] Grant READ SESSION
[ ] Grant EXECUTE MANAGED TASK
[ ] Grant required source database USAGE
[ ] Grant required source schema USAGE
[ ] Grant SELECT on required source tables
[ ] Grant READ on required stages
[ ] Grant SNOWFLAKE.CORTEX_USER only if AI is used
[ ] Grant CUBE_ADMIN only to administrator roles
[ ] Grant CUBE_PUBLIC to consumer roles

These items align with the definitive initial administrator checklist.

Recommended Practices

• Grant CUBE_PUBLIC to report consumers and BI service accounts.
• Grant CUBE_ADMIN only to administrators.
• Do not grant both application roles to administrators; CUBE_ADMIN already inherits CUBE_PUBLIC.
• Review CUBE_ADMIN membership periodically.
• Keep row-level security separate from functional role assignment.
• Ensure READ SESSION is available when security or Query Builder functionality is required.
• Ensure EXECUTE MANAGED TASK is available when serverless scheduling is required.
• Grant source access only to the databases, schemas, tables, and stages actually used.
• Grant SELECT rather than ownership on source tables.
• Grant SNOWFLAKE.CORTEX_USER only when AI features are enabled.
• Use SHOW GRANTS during security, governance, and compliance reviews.

Key Principle

The Casabase Cube access model can be summarized as:

Snowflake Account Role
        │
        ▼
Casabase Cube Application Role
        │
        ▼
Functional Capability

while:

Casabase Cube Security Rule
        │
        ▼
Data Scope

and:

Snowflake Object Grants
        │
        ▼
Source Data Available to the Application

These controls work together, but they should not be treated as interchangeable.

Related Topics

• Administration Overview
• Access Control
• Operational Tasks
• Application Upgrades
• Compliance and Privacy
• Security Model
• Integration Points