Access Control & Administration

This section illustrates how access control is enforced in ByteHouse, and how administrators can configure access control policies in terms of user management, object access control and network security.

For better illustration, the examples listed in this document are from the perspective of an AccountAdmin.

Topics include:

  • User Management
  • Object-level Role-Based Access Control.
  • Network Security & IP Filtering

User Management

Create a New User

New users can be created on User Management page as follows. You can toggle the "Force Password Change" checkbox to decide whether the new user needs to change a new password upon first login.

You can also specify some advanced information for the new user.

Manage User

On the user page, Account or User Administrators can view all the users. Selecting the user will allow you to edit user identity information, reset his/her password, as well as disable the user.

Object-level Role Based Access Control

Permission

All actions that can be performed in ByteHouse have related permission defined. For example: viewing account resource usage, creating new users, querying data from some table, or loading large data set into ByteHouse.

Permissions that are resource specific, such as creating tables (related to a database), inserting new data (related to a table), and running virtual warehouses (related to a warehouse), are bound to the particular resource instance or object.

Permissions that are not resource specific, such as creating databases (*note that databases are account level resources), viewing billing status, or creating a new service user, are not bound to any particular object.

Role

Permission control in ByteHouse is enforced at a role level. Every ByteHouse user is able to have one or more assigned roles.
You can visit "User Management - Roles" page to view all roles that are available under the account.

Active Role

When using ByteHouse, you need to select an "Active Role", and all your behaviour will be restricted by the permissions assigned to this Active Role.

By selecting a different "Active Role", from your avatar dropdown, you will switch to a different permission space bound to that "Active Role", and your view in the web console may vary according to that permission space as well.

By default, a "PublicRole" represented by an asterisk mark "*" is assigned to all users under an account. This Public Role is also the "Default Role" after a new user is created.

Web Console
In ByteHouse web console, the panel to switch active role is shown below:

In your " Account Details " page, you can change your " Default Role " to any roles that you are assigned to. The Default Role is the active role in the web console every time you login to ByteHouse.

CLI Access

When accessing ByteHosue using CLI:

  • Active role can be switched using:
SET ROLE "Role Name A";

-- or --

SET ROLE RoleNameB;
  • Change Default Role setting:
SET DEFAULT ROLE "Role Name A";

-- or --

SET DEFAULT ROLE RoleNameB;

Role Hierarchy

Roles are managed hierarchically in ByteHouse. ParentRole will "inherit" all permissions coming from its direct child or indirect child (grandchild) roles.
In the example below, GrandchildRole1 is granted with "Create Database" permission, and ChildRoleB is granted with "Query TableOne" permission. As a result of the Role Hierarchy:

  • ParentRole, ChildRoleA, and GrandchildRole can "Create Database"
  • ParentRole and ChildRoleB can "Query TableOne"

Predefined Roles

There are 6 system "Predefined Roles" that are already created for you once you sign up with ByteHouse, each of them has some predefined permissions

  • AccountAdmin is the root role of a ByteHouse Account. Users assigned with this Role have all privileges/permissions under the account.

  • SecurityAdmin is a direct child role under the Account Admin. Users with this role will be in charge of all permission or privileges related actions, such as creating new custom roles, deleting a custom role, assigning users to some roles, etc. One exception is that SecurityAdmin cannot grant AccountAdmin role to other users.

  • UserAdmin is a direct child role under the Account Admin. UserAdmin can do everything related to users, namely, CRUD for users.

  • SystemAdmin is a direct child role under the Account Admin. Users with this role will have permissions with regard to all platform resources, such as databases, tables, virtual warehouses, online worksheets, etc.

  • OperationAdmin is a direct child role under AccountAdmin. This role does not have any predefined privileges or permissions. This role is used to assign to ByteHouse customer engineers for customer support purposes.

  • PublicRole, as described above, is represented by a asterisk mark "*" in ByteHouse. It is the least privileged role in a ByteHouse account. Granting permission to this role has the same effect of granting the same permission to all roles in this account.

Here is what you can see on "User Management - Roles" page once you first log in ByteHouse as an "AccountAdmin" role.

Custom Roles

Custom Roles can be created on the role management page. All custom roles are either direct child or indirect child (grandchild) role of SystemAdmin, and are the direct or indirect parent (grandparent) role of "PublicRole". An example of a complete role hierarchy diagram can be represented below:

Granting Permissions

Permission can be granted at role level as explained above.

Object-Levelpermissions

For object-level permissions, you need to locate the target resource and manage its permission from its own permission management panel.
Take a database as an example:
Find the permission management entry point from the detailed view of the database:

You can either:

  1. Grant permission to a role that previously has no permission on it, as shown in label 1. 

  2. Edit permissions on roles that have already some permissions granted, as shown in label 2. 

Label 3 is a special option when granting permissions, with the option checked, the role that is granted with permissions is able to regrant the same permissions to other roles.

One thing to note is permissions that are default to system predefined roles, and permissions that are inherited from child roles are not modifiable.

Non Object-Level permissions

Non object-level permissions can be granted or revoked from the role management page. Currently, only 4 such permissions are open to be granted as shown below.

Assign Roles

You can assign a role to users on the role management page. You can search for usernames in the role details page as shown below, and then click the "+" sign beside the username for assignment.


Did this page help you?