Roles & Permissions

Permissions will help you to take care of the data governance in your workspace. Using this resource, you can control who can access and edit each table or layer (individually or for a group of people).

​

Existing roles

Each person inside a workspace will have one of these three roles:

​

Members permissions

Differently from owners and admins, members have their access controlled. If you are a member, your access to layers and tables will be either Viewer, Editor or Manager.

In general:

• Viewer: Allows users to see the referred resource, but not make changes to it.
• Editor: Allows users to make certain changes to the referred resource and create other resources related to it.
• Manager: Allows users to make any changes and delete the referred resource, as well as grant viewer and editor permissions to the same resource for other member users.

Lakehouse permissions can be directly assigned to the following types of resources:

• Layer
• Table
• Volume

Access to other types of resources follow as a result of the permissions granted to layers, tables and volumes. Sources, transformations, destinations and visualizations require at least the same level of access to all its input and output tables, (unless its stream is disabled).

Lakehouse permissions may be revoked at any time by an organization owner, admin user or member user with manager access to the same resource the permission refers to.

​

Permission propagation

Lakehouse permissions automatically propagate from layers to all their tables and volumes. A member user who’s given permission of a certain level of access to a layer has automatically the same level of access to all the tables and volumes that belong to that same layer.

Also, viewer access propagate from tables and volumes back to their layer. A member user who’s given permission of any level of access to a table or volume has viewer access to its layer automatically, but no more than that unless another permission of a higher level is granted directly to the layer for the same user.

​

Permission groups

Lakehouse permissions can be assigned to a permission group rather than a particular user. Organization owners and admin users can create and manage permission groups as well as manage member users within each group.

Consider that if your group has, for example, a viewer permission to a specific table, but your individual account has been granted with a editor permission, the editor permission will be considered! We’ll always use the higher permission given to your account in case of multiple options.

Every organization has a special permission group called All, which contains all the users in the organization. Any new user who joins an organization will be automatically added to the All group. The All group cannot be modified or deleted, and users cannot be added or removed from it. Still, organization owners, admin users and managers can use the All group to assign lakehouse permissions to all member users at once.

​

Lakehouse permissions for API Tokens

Nekt API tokens are bound to the user who’s created it, and as such, will be granted the same level of access. The level of access of an API token to a certain resource will change in the same way as the level of the user who created it. This may happen as result of the following events:

• New permissions are granted to the user or existing ones are revoked.
• The user is added or removed from permission groups.
• User is promoted or demoted to a different role.

​

Examples

Here follow a few scenarios that may help us understand how lakehouse permissions work on Nekt:

• Members cannot create new layers, regardless of the permissions they have.
• If a member does not have viewer access to a layer, they cannot see that layer nor any sources, transformations, destinations, or visualizations linked to tables within that layer.
• To create a new source, a member must have editor access to the output layer, since the source will create new tables in that layer.
• If a member has editor access to a layer, they can modify sources that write to that layer and add new streams to those sources.
• Even without editor access to the layer, a member can modify a source if they have editor access to all the output tables of that source. This permission still applies even if the source includes disabled streams linked to tables the user cannot access.

If you encounter any issues, reach out to us via Slack, and we’ll gladly assist you!