Manage roles
Y42's access control feature is designed to provide secure and efficient management of user permissions and resource access. You can access this feature in the Y42 application by navigating to the IAM section in the Organization Settings & IAM menu.
Organization IAM settings
Overview
To understand access control in Y42, this general summary of relevant concepts may be helpful:
- Subject: typically a user, sometimes also an API key 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" space.
- Resource: objects in Y42 like organizations and spaces, organized in hierarchy, i.e. an organization is the parent of all spaces inside that organization.
- Directly Grantable Permissions: permissions that allow subjects to perform certain actions at the organization level without granting them full administrative rights.
Available roles
The following provides an overview of the different roles that exist on each resource type inside Y42, and which permissions are effectively entailed by that role.
| Role | Applicable to | Permissions | Inheritance |
|---|---|---|---|
| Administrator | Organization | All permissions | Always |
| Limited Access | Organization | Read subjects, receive roles on spaces | Partial - users with ‘Limited Access’ can not access space - explicit grant required. |
| Limited Viewer Access | Organization | Read subjects, receive ‘Viewer’ role on spaces | Partial - users with ‘Limited Viewer Access’ can not automatically access space - explicit grant required. |
| Owner | Spaces | Read, update, delete spaces CRUD space assets | N/A |
| Viewer | Spaces | Read space assets | N/A |
Directly Grantable Permissions
The directly grantable permissions feature allows organization administrators to delegate specific management tasks without having to grant full administrator permissions, enhancing both security and efficiency in org-related configurations management.
The following provides an overview of the directly grantable permissions in Y42. There are two types of such permissions:
- Use: Permissions that allow users to interact with and utilize specific source features
- Grant: Permissions that allow users to assign permissions to utilize specific source features
Direct permissions include:
- Create Teams: Allows the user to create and manage teams within the organization.
- Create API Keys: Enables the user to generate API keys for programmatic access to Y42.
- Read Subjects: Grants read access to view user and team information.
- Write Org Data: Allows the user to modify organization-level data.
- Create Spaces: Permits the creation of new spaces within the organization.
- Read Billing: Provides read-only access to billing information and invoices.
- Invite Readonly Users: Allows the user to invite others with read-only access to the organization.
- Invite Users: Enables the user to invite new users to spaces with varying roles.
Granting roles and permissions
A subject can generally grant other users equivalent access to their own role but not higher. For instance, only administrators can grant or revoke the administrator role to others. A space owner can grant Space Owner and Viewer roles to other users.
Directly grantable permissions can only be added by Administrators to subjects holding 'Limited Access' and 'Limited Viewer Access' roles.
Visibility of Git resources and data stored in the warehouse
By default, the Y42 application filters out non-readable resources in the user interface. This means users will only see spaces where they hold a Viewer role or higher.
Any Viewer of a space will have access to all files stored in Git, including commit history and other Git metadata, either by directly cloning the repository or accessing their browser's internal storage. Additionally, they will have access to the corresponding data from the data warehouse.
To control access to data pipelines and their definitions across various teams, we recommend enforcing a hard separation by setting up multiple spaces. While you can still share data between these spaces using integrations that access datasets in the warehouse, the Git repositories, pipeline definitions, and data lineage will remain completely separate.
Consuming data from BI tools and other downstream applications
To allow downstream users and tools to consume data managed by Y42 without exposing read access to the information in Git, Y42 provides the Publish layer. This feature lets you consume data directly from the data warehouse in the form of Views, which are automatically managed by Y42. For more details, refer to the Publish Assets documentation.