Access control framework

Access control privileges determine who can access and perform operations on specific resources in Tabular.

Role-based access control

Tabular uses a Role-based Access Control (RBAC) model - access privileges are assigned to roles, which are in turn assigned to users.

The key concepts to understanding access control in Tabular are:

  • Securable resource: An entity to which access can be granted. Unless allowed by a grant, access is denied.
  • Role: An entity to which privileges can be granted. Roles are in turn assigned to users. Note that roles an also be assigned to other roles, creating a role hierarchy.
  • Privilege: A defined level of access to an resource. Multiple distinct privileges may be used to control the granularity of access granted.
  • User: A user identity recognized by Tabular, whether associated with a person or service.

In the Tabular model, access to securable resources is allowed via privileges assigned to roles, which are in turn assigned to other roles or users. This model is different from a user-based access control model, in which rights and privileges are assigned to each user or group of users. The Tabular model is designed to provide a significant amount of both control and flexibility.

Securable resources

Every securable resource resides within a logical container in a hierarchy of containers. The top-most container is the customer organization. Securable resources such as tables are contained in a database, which are in turn contained in a warehouse. All warehouses for your Tabular account are contained in the organization.

The ability to perform SQL actions on resources is defined by the union of all privileges granted to all roles which the current user is a member of. The following are examples of SQL actions available on various resources in Tabular:

  • Ability to create a database.
  • Ability to list tables contained in a database.
  • Ability to add data to a table.


Roles are the entities to which privileges on securable resources can be granted and revoked. Roles are assigned to users to allow them to perform actions required for business functions in their organization. A user can be assigned multiple roles.

There are a small number of system-defined roles in a Tabular account. System-defined roles cannot be dropped. In addition, the privileges granted to these roles by Tabular cannot be revoked.

Users who have been granted a role with the necessary privileges can create custom roles to meet specific business and security needs.

Roles can be also granted to other roles, creating a hierarchy of roles. The privileges associated with a role are inherited by any roles above that role in the hierarchy. For more information about role hierarchies and privilege inheritance, see Role Hierarchy and Privilege Inheritance (in this topic).

Although additional privileges can be granted to the system-defined roles, it is not recommended. System-defined roles are created with privileges related to account-management. As a best practice, it is not recommended to mix account-management privileges and entity-specific privileges in the same role. If additional privileges are needed, Tabular recommends granting the additional privileges to a custom role and assigning the custom role to the system-defined role.

System-defined roles


(aka Organization Administrator)

Role that manages operations at the organization level. More specifically, this role:

  • Can rename or delete the organization
  • Can manage users in the SECURITY_ADMIN role
  • Can view usage and billing information across the organization


(aka Security Administrator)

Role that can manage any resource grant globally, as well as create, monitor, and manage users and roles. More specifically, this role:

  • Is implicitly granted the MANAGE GRANTS security privilege to be able to modify any grant, including revoking it.
  • Can create and manage Service Credentials


Pseudo-role that is automatically granted to every user and every role in your account. The EVERYONE role can carry privileges on securable resources, just like any other role.

This role is typically used in cases where explicit access control is not needed and all users are viewed as equal with regard to their access rights.

Custom roles

Custom account roles can be created using the SECURITY_ADMIN role as well as by any role to which the CREATE ROLE privilege has been granted.

By default, a newly-created role is not assigned to any user, nor granted to any other role.

For instructions to create custom roles, see Creating Custom Roles.

Default roles

Users can set their DEFAULT ROLE using their profile page in the Tabular app.

The DEFAULT ROLE is used for assigning privileges whenever a user creates a new resource like a database or table.


For each securable resource, there is a set of privileges that can be granted on it. For existing resources, privileges must be granted on individual resources (e.g. the SELECT privilege on the table my_table).

Any granted privilege may also be specified as with GRANT, meaning that the target role has the ability to grant the privilege to other roles. This enables access control management of a given resource to be easily delegated.

To simplify grant management, future grants allow defining an initial set of privileges on resources created in a schema (i.e. grant the SELECT privilege on all new tables created in the schema my_schema to a specified role).

There is no concept of a “super-user” or “super-role” in Tabular that can bypass authorization checks. All access requires appropriate access privileges.

For more details, see Access control privileges.

Privileges on resource creation

When a new resource is created, the following privileges are granted:

  • Full privileges (with GRANT) will be granted to the current user’s DEFAULT ROLE
  • Any FUTURE privileges granted to roles on the containing resource (e.g. if FUTURE_SELECT is granted to role A on database my_db, then any tables created in my_db will have SELECT granted to role A).

There is no formal concept of resource ownership. All privileges on a securable resource must be explicitly defined, including GRANT which allows a role to grant and revoke privileges for other roles.

Role hierarchy example

For a more specific example of role hierarchy and privilege inheritance, consider the following scenario:

  • Role 1 has been granted Privilege A.
  • Role 2 has been granted Privilege B and is a member of Role 1.
  • Role 3 has been granted Privilege C and is a member of Role 2.
  • User 1 is a member of Role 3.

Privilege inheritance for granted roles In this scenario:

  • Role 2 inherits Privilege A.
  • Role 3 inherits Privileges A and B.
  • User 1 has all three privileges - A, B, and C.