Personas and Permissions in Immuta

Audience: Data Owners, Data Users, Data Governors, and Systems Administrators

Content Summary: This page defines the personas in Immuta with the responsibilities and actions they may take. It also defines the permissions that System Administrators may add to each user.

Personas

User Roles

Data Owners

In order for data to be available in the Immuta platform, a Data Owner — the individual or team responsible for the data — needs to connect their data to Immuta. Once data is connected to Immuta, that data is called a data source. In the process of creating a data source, Data Owners are able to set policies on their data that restrict which users can access the data source, which rows within the data a user can access, and which columns within the data a user can see or be restricted. Data Owners can also decide whether to make their data source public, which makes it available for discovery to all users in the Immuta Web UI, or make it private, so that only the Data Owner and its assigned subscribers know it exists.

• Project Owners: Data Owners create projects to restrict how their data will be utilized using purpose-based restrictions.

Data Users

Data Users use the data that’s been made available through Immuta. Data Users can browse the Immuta Web UI seeking access to data and easily connecting their third-party data science tools to Immuta for all their data science needs.

• Project Owners: Data Users create projects to efficiently organize their data sources.

Data Governors

Data Governors set Global Policies within Immuta, meaning they can restrict the ways that data is used within Immuta across multiple projects and data sources. Governors can also set purpose-based usage restrictions on projects, which can help limit the ways that data is used within Immuta. By default, Governors can subscribe to data sources; however, this setting can be disabled in the Immuta Configuration, removing the Governor's ability to create or subscribe to data sources. Additionally, users can be a Governor and Admin simultaneously by default, but this setting can also be changed in permissions, rendering the Governor and Admin roles mutually exclusive.

System Administrators

Application Admins

Application Admins manage the configuration of Immuta for their organization. These users can configure Immuta to use external identity managers and catalogs, enable or disable data handlers, adjust email and cache settings, generate system API keys, and manage various other advanced settings.

User Admins

Another type of System Administrator is the User Admin, who is able to manage the permissions, attributes, and groups that attach to each user. Permissions are only managed locally within Immuta, but groups and attributes can be managed locally or derived from user management frameworks such as LDAP or Active Directory that are external to Immuta. By default, Admins can subscribe to data sources; however, this setting can be disabled in the Immuta Configuration, removing the Admin's ability to create or subscribe to data sources. Additionally, users can be an Admin and Governor simultaneously by default, but this setting can also be changed in permissions, rendering the Admin and Governor roles mutually exclusive.

Permissions

Permissions are a system-level mechanism that control what actions a user is allowed to take. These are applied to both the API and UI actions. Permissions can be added to any user by a System Administrator (any user with the USER_ADMIN permission), but the permissions themselves are managed by Immuta and cannot be added or removed in the Immuta UI; however, custom permissions can be created in the Immuta Configuration Builder.

Permission Details

• APPLICATION_ADMIN: Gives the user access to administrative actions for the configuration of Immuta. These actions include
  • Adding external IAMs.
  • Adding ODBC drivers.
  • Adding external catalogs.
  • Configuring email settings.
• USER_ADMIN: Gives the user access to administrative actions for managing users in Immuta. These include
  • Creating and managing users and groups.
  • Add and remove user permissions.
  • Create and manage user attributes.
• AUDIT: Gives the user access to the audit logs.
• CREATE_DATA_SOURCE: Gives the user the ability to create data sources.
• CREATE_DATA_SOURCE_IN_PROJECT: Gives the user the ability to create data sources within a project.
• CREATE_S3_DATASOURCE_WITH_INSTANCE_ROLE: When creating an S3 data source, this allows the user to the handler to assume an AWS Role when ingesting data.
• CREATE_FILTER: Gives the user the ability to create and save a search filter.
• CREATE_PROJECT: Gives the user the ability to create projects.
• FETCH_POLICY_INFO: Gives the user access to an endpoint that returns visibilities, masking information, and filters for a given data source.
• GOVERNANCE: Gives the user the ability to set Global Policies, create purpose-based usage restrictions on projects, and manage tags.
• PROJECT_MANAGEMENT: Gives the user the ability to manage purposes (modification, approval, and denial) , add them to data sources, view all data sources, and add any data source to a project.
• IMPERSONATE_HDFS_USER: When creating an HDFS data source, this allows the user to enter any HDFS user name to use when accessing data.

See Manage Personas and Permissions for a tutorial on adding and removing permissions.

User Impersonation

Some use cases require a trusted Immuta user that has the ability to impersonate other Immuta users.

Query Engine User Impersonation

Users with the IMPERSONATE_USER permission within Immuta are able to impersonate other Immuta users by using their own SQL credentials to authenticate with the Immuta Query Engine, and then specify which user they would like to impersonate.

To learn how to proceed with user impersonation, navigate to the tutorial.