User Personas and Permissions

Audience: All Immuta users

Content Summary: User roles in Immuta are fluid and interdependent, and understanding these different roles is essential to effectively sharing, analyzing, and protecting data and maintaining compliance. This page describes the user personas in Immuta and their corresponding permissions.

User Personas

• 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.

• 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 source that restrict which users can access it, which rows within the data a user can access, and which columns within the data source are visible or masked. 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 made private, which means only the Data Owner and its assigned subscribers know it exists.

• Data Users: Data Users consume the data that’s been made available through Immuta. Data Users can browse the Immuta Web UI seeking access to data and easily connect their third-party data science tools to Immuta.

• Project Owners: These users can create their own project to restrict how their data will be utilized using purpose-based restrictions or to efficiently organize their data sources.

• Governors: 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 the Configuration Builder, rendering the Governor and Admin roles mutually exclusive.

• Project Managers: These users inspect, manage, approve, and deny various project changes, including purpose requests and project data sources.

• 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 the Configuration Builder, 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 on the App Settings page.

• 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.
• 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.
• IMPERSONATE_USER: Allows user to impersonate other Immuta users by entering their own SQL credentials to authenticate with the Immuta Query Engine and then specifying which user they would like to impersonate.
• IMPERSONATE_HDFS_USER: When creating an HDFS data source, this allows the user to enter any HDFS username to use when accessing data.
• PROJECT_MANAGEMENT: Allows users to create purposes, approve and deny purpose requests, and manage project data sources.
• 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.