Manage roles

Overview

Y42 enables detailed control over data assets and operations using a hierarchical role-based access control system that is integrated throughout the platform.

To understand access control in Y42, this general summary of relevant concepts may be helpful:

• Subject: typically a user, sometimes also an API token that is used to access Y42 programmatically. Users can be grouped into teams as well, and a team can be managed like a single subject.

• Role: roles are held by subjects, relative to resources. For example, the user "John Doe" can hold the "owner" role relative on the "ACME" organization.

• Resource: can be any object inside Y42, like an integration, a table, a job, but also containers like the whole of the integrations module or even a space or an organization.

• Resource Hierarchy: Resources can be "parents" of other resources.

  • An organization is the parent of all spaces inside that organization

  • The integrations module is the parent of each specific integration, the models module contains every UI-Model and SQL Model, etc.

  • An integration or model is the parent of each output table contained in it (usually 1 table, but UI models can have multiple output tables)

Available roles

The following provides a simplified overview of the different roles that exist on each resource type inside Y42, and which permissions are effectively entailed by that role.

*only administrators can delete an organization - for other resource types, owners can delete as well.

**reading subjects is only possible at two levels: organization and space. In practice, every subject can discover other subjects, except when the subject is a guest in the organization and also a guest in the space.

°These roles are considered "fine-grained" roles in specific contexts. For more information, see below.

Discovering resources vs. reading data

There is a difference between the "read" and "discover resource" permissions, which stems from the way Y42 runs Git under the hood.

For technical reasons, when a subject is able to access a space in any way (i.e. guest role or higher), they also need to be able to git clone that space’s Git repository. This means they will be able to discover all models, sources and other resources in the space, but, importantly, it does not automatically let them read any underlying data from tables in the data warehouse. Nevertheless, this detail may have governance, security and privacy implications that are important to be aware of.

Consuming data from BI tools and other downstream applications

To let downstream users and tools consume data managed by Y42 without exposing read access to the information managed in Git, Y42 provides the Publish layer [Link]. This lets you simply consume data directly from the data warehouse in the form of Views, which are automatically managed by Y42.

Using OAuth

Many BI tools, including, for example, Tableau, support OAuth authentication when connecting to data sources (in this case, BigQuery or Snowflake, depending on which data warehouse you use with Y42). If this is also the case for your tool, the workflow for controlling access to your Y42-managed data is easy:

• Make sure all of your Y42 users have an identity with the same email address in Y42, the BI tool, and the data warehouse. If you are using an identity provider like Okta to provision users, this will usually be the case
• Make sure the service account used by Y42 has sufficient permissions in the data warehouse to manage the permissions of other users
• Make sure your BI tool users connect to the data warehouse using OAuth (do not use a shared connection via e.g. a service account or other centralized credentials)
• If the above are all given, Y42 will automatically synchronize the Y42-”internal” table-level read access of each user to the data warehouse and each user in the OAuth-enabled BI tool will be able to access precisely the data that was configured in Y42.

Without OAuth

To access data from a BI tool or system that does not support OAuth for Snowflake and/or BigQuery (such as, at the time of writing, Superset or Metabase) we recommend using Y42 Access Tokens with associated data warehouse credentials:

• Under your organizations IAM settings in Y42, create an “Access Token” and give it a name that makes it easy to associate with the application and/or use case you want to consume data from
• Use the “re-generate data warehouse credentials” dialog to create, download and save authorization credentials for your tool
• In Y42, enable the desired level of access for the token, for example by assigning it a role in your organization or in specific spaces, or by enabling access to specific tables only
• Configure your tool with the downloaded credentials
• Whenever you update the access token’s view permissions in Y42, this access level will be reflected in the downstream system

Visibility of Git resources and data stored in the warehouse

By default, the Y42 application will filter out non-readable resources in the user interface. This means that a user will generally only see those integrations, models, tables, widgets and dashboards that they hold a Viewer role or higher on.

Similarly, they will not be able to read data from the data warehouse or any Y42 backend for an asset unless they hold a sufficiently high role. That is to say, Y42's access control layer will, of course, protect from unauthorized read and write access to git and the data warehouse.

However, it's important to note that any guest or member of a Space will have the ability to clone the git repository of that Space, as this is a technical necessity for Y42 to operate. That means that such users will be able to see all files that are stored in git, as well as their commit history and other git metadata (by directly cloning the repository, or by accessing their browser's internal storage). Naturally, this does not grant them the ability to read the corresponding data from the data warehouse, but is still an important fact to be aware of for particularly security-sensitive organizations, as the code that defines a data asset may itself be sensitive.

If you require full compartmentalization of data pipelines and their definitions for various teams in your organization, we recommend you enforce a hard separation between then by setting up multiple Spaces. You will still be able to share data between these Spaces using integrations that access the datasets in the warehouse, but the git repositories, pipeline definitions and therefore also data lineage will be totally separated between them.

Granting roles

A subject can generally grant other users equivalent access to their own role, but not higher. For example, only administrators can grant or revoke the administrator role to others, an editor can only grant or revoke the editor role to others.

There are some exceptions to this: for example, only Owners and Administrators can make grants at the organization-level, and Viewers, members and guests cannot generally make grants at all (unless they're given a higher role on a specific resource, in which case they might be able to make grants on that resource and its child resources).