Access control privileges determine who can access and perform operations on specific resources in Tabular.
On this page:
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 individuals. This model is designed to provide a significant amount of both control and flexibility. It differs from a user-based access control model, in which rights and privileges are assigned directly to each user or group of users.
- Resource: A data entity (warehouse, database, or table) to which access can be granted.
- Role: An entity to which you grant privileges. Roles are assigned to individuals. People access data resources in Tabular based on the privileges belonging to a role assigned to them. Roles also can be assigned to other roles, creating a role hierarchy (that is, nested roles). You can also grant MODIFY_ROLE privileges to another role – that is, one role can edit/manage another role without being nested
- Privilege: A defined level of access to a resource (LIST, SELECT, UPDATE, and so on).
- User: An identity recognized by Tabular, whether associated with a person or service.
Every resource resides within a logical container in a hierarchy of containers. The topmost container is the customer organization. The organization contains all warehouses for your Tabular account. The warehouse contains all your databases, and the databases contain all your tables.
The SQL actions you can do on resources are defined by the sum of all privileges granted to all the roles to which you belong. So if you have two roles, each with distinct privileges, you receive the superset of those privileges.
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.
- Ability to drop a table.
Access privileges on resources are granted to (or revoked from) roles. Roles are assigned to individuals. It’s the role that allows you to perform the actions on data you must do as part of your job. Individuals can be assigned multiple roles. Some of the things you can do with roles in Tabular:
- Create a new role in the organization and define its privileges.
- Assign to one role the privilege to grant privileges to another role.
- Create a hierarchy by granting one role to another role. For example, if you make the DATA ANALYST role a member of the MARKETING role, you’re giving data analysts access to marketing resources. The privileges associated with a role are inherited by any roles lower in that hierarchy – that is, a child (or grandchild) role inherits the privileges associated with the parent role.
Role hierarchy example
For a more specific example of role hierarchy and privilege inheritance, consider the following scenario:
- The role of Contributor has been granted privileges to public data.
- The role of Director has been granted privileges to restricted files. Director is also a member of the Contributor role.
- The role of Vice President has been granted privileges to top secret classified files. Vice President is also a member of the Director role.
- VP Smith is a member of the Vice President role.
Privilege inheritance for granted roles in this scenario:
- Director inherits privileges to public data.
- Vice President inherits privileges to both public and restricted data.
- VP Smith has the set of all 3 privileges - public, restricted, and top secret classified.
Tabular automatically includes 3 roles that come with pre-defined privileges. These system-defined roles cannot be dropped.
The ORG_ADMIN (Organization Administrator) role manages operations at the organization level. 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
The SECURITY_ADMIN role manages any resource grant globally, and can also create, monitor, and manage users and roles. This role:
- Is implicitly granted the MANAGE GRANTS security privilege; users assigned the SECURITY_ADMIN role can modify any grant, including revocation.
- Can create and manage service credentials
This role is automatically granted to every individual and every role in your organization. As with any other role, the EVERYONE role can carry privileges on resources.
EVERYONE typically is used in cases where you don’t need explicit access control and all individuals are viewed as equal with regard to their access rights.
You can make EVERYONE a member of other roles.
Anyone can define a new account role; no special privileges are required to do this.
By default, a newly-defined role is neither assigned to any individual nor granted to any other role.
For instructions on how to define roles, see Creating User-Defined Roles.
Each resource (warehouse, database, table) has a set of access privileges you can grant. These vary, depending on the resource to which the privileges apply. You can configure whether the privileges apply automatically to resources created in the future.
For a list of specific privileges available to Tabular resources, see Access control privileges.
To give a particular role the ability to grant its privileges to other roles, move the Privileges slider to Grant. In this way you can easily delegate access control management of a given resource.
To simplify grant management, future grants allow you to define an initial set of privileges on resources created in a schema. For example, you can grant the SELECT privilege on all new tables created in the schema my_schema to any role you specify.
Important In Tabular there is no concept of a “super-user” or “super-role” that can bypass authorization checks. Any access requires appropriate access privileges.
Privileges on resource creation
When you create a new resource, FUTURE privileges are granted to roles on the particular resource. For example, if you grant FUTURE_SELECT to role A on database my_db, then any tables subsequently created in my_db also will have SELECT granted to role A.
Note There is no formal concept of resource ownership. You must explicitly assign all privileges on a resource, including GRANT (which allows a role to grant and revoke privileges for other roles).
When you set or edit access privileges for a particular role on a database, you can opt to apply those privileges to existing tables. This option simplifies privilege management; you do not have to update privileges manually each time you wish to establish or modify data access to a resource.
You cascade privileges from the database page. You cannot cascade table privileges from the warehouse level.