Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Native impersonation allows users to natively query data as another Immuta user.
User impersonation is supported with
Impersonating users in projects
If you are impersonating a user who is currently in a project, you will only see data sources within that project. For details about this behavior, see the description of project contexts.
Select Enable Impersonation when configuring the Redshift integration on the App Settings page.
After enabling user impersonation with your Amazon Redshift integration, there are two ways to give a user permission to use the feature: in the Immuta UI or in Amazon Redshift. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Add Permissions.
Click the Select Permission dropdown, and select the IMPERSONATE_USER permission.
As a Redshift superuser,
Navigate to your Redshift instance.
Run ALTER GROUP <Impersonation Group> ADD USER <Redshift User>.
To impersonate another user in Redshift,
Run the following in Redshift: CALL immuta_procedures.impersonate_user(<Immuta username of the user to impersonate>).
Run queries.
To end user impersonation in Redshift, run CALL immuta_procedures.impersonate_user(<NULL>).
There are two ways to revoke permission to impersonate users: in the Immuta UI or in Amazon Redshift. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Remove for the IMPERSONATE_USER permission.
As a Redshift superuser,
Navigate to your Redshift instance.
Run the following in Redshift: ALTER GROUP <Impersonation Group> DROP USER <Redshift User>
User impersonation is specific to the script and session in which it was set. Using a new script or running a subset of script queries without setting the context will result in the queries being run as the regular user.
Select Enable Impersonation when configuring the Synapse Analytics integration on the App Settings page.
After enabling user impersonation with your Azure Synapse Analytics integration, there are two ways to give a user permission to use the feature: in the Immuta UI or in Azure Synapse Analytics. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Add Permissions.
Click the Select Permission dropdown, and select the IMPERSONATE_USER permission.
As a Synapse user,
Navigate to your Synapse instance.
Run the following in Synapse: EXEC sp_addrolemember N'<Impersonation Role>', N'<Synapse User>'
To impersonate another user in Synapse,
Run the following command:
Run queries.
To end user impersonation in Synapse, run EXEC sys.sp_set_session_context @key = N'NULL', @value = '<NULL>'.
There are two ways to revoke permission to impersonate users: in the Immuta UI or in Azure Synapse Analytics. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Remove for the IMPERSONATE_USER permission.
As a Synapse user,
Navigate to your Synapse.
Run the following in Synapse: EXEC sp_droprolemember N'<Impersonation Role>', N'<Synapse User>'
User impersonation is specific to the script and session in which it was set. Opening a new script will revert the user back to themselves.
Scala clusters
Avoid using this feature with Scala clusters, as the proper security mechanisms were not built to account for user isolation limitations in Scala clusters. This feature was developed for the BI tool use case in which service accounts connecting to the Databricks cluster need to impersonate Immuta users so that policies can be enforced.
Databricks user impersonation allows a Databricks user to impersonate an Immuta user. With this feature,
the Immuta user who is being impersonated does not have to have a Databricks account, but they must have an Immuta account.
the Databricks user who is impersonating an Immuta user does not have to be associated with Immuta. For example, this could be a service account.
When acting under impersonation, the Databricks user loses their privileged access, so they can only access the tables the Immuta user has access to and only perform DDL commands when that user is acting under an allowed circumstance (such as workspaces, scratch paths, or non-Immuta reads/writes).
Follow one of these methods to allow specified Databricks users to impersonate Immuta users:
In the cluster policy JSON in the Immuta UI, add a comma-separated list of Databricks users who are allowed to impersonate Immuta users for the IMMUTA_SPARK_DATABRICKS_ALLOWED_IMPERSONATION_USERS Spark environment variable.
In the Spark environment variables section of the Databricks UI, add IMMUTA_SPARK_DATABRICKS_ALLOWED_IMPERSONATION_USERS followed by a comma-separated list of Databricks users who are allowed to impersonate Immuta users.
In the cluster policy JSON in the Immuta UI, add a comma-separated list of Databricks users who are allowed to impersonate Immuta users for the IMMUTA_SPARK_DATABRICKS_ALLOWED_IMPERSONATION_USERS Spark environment variable.
In the Spark environment variables section of the Databricks UI, add IMMUTA_SPARK_DATABRICKS_ALLOWED_IMPERSONATION_USERS followed by a comma-separated list of Databricks users who are allowed to impersonate Immuta users.
Prevent users from changing impersonation user in a given session
If your BI tool or other service allows users to submit arbitrary SQL or issue SET commands, set IMMUTA_SPARK_DATABRICKS_SINGLE_IMPERSONATION_USER to true to prevent users from changing their impersonation user once it has been set for a given Spark session.
Once the cluster is configured with a list of Databricks users who are allowed to impersonate Immuta users, run the following SQL command to set the user you want to impersonate:
This command generates an API token for the specified user that queries Immuta for metadata pertinent to that user. When generating the token, the impersonated username is matched with the corresponding IAM user. The IAM used by default is the built-in IAM in Immuta, but can be set using the IMMUTA_USER_MAPPING_IAMID environment variable.
Run queries as the impersonated Immuta user:
Once impersonation is active, any query issued in the session will have the appropriate data and subscription policies applied for the impersonated user.
Audited queries include an impersonationUser field, which identifies the Databricks user impersonating the Immuta user:
To end user impersonation for the session, run
The only way to enable this feature is through cluster configuration. The IMPERSONATE_USER permission in Immuta will not allow a user to perform native impersonation in Databricks.
User impersonation is automatically enabled with your Starburst (Trino) integration, but the authenticated user must be given the IMPERSONATE_USER permission in Immuta or match the Starburst (Trino) immuta.user.admin regex configuration property.
User impersonation is automatically enabled with your Starburst (Trino) integration, but the authenticated user must be given the IMPERSONATE_USER permission in Immuta or match the Starburst (Trino) immuta.user.admin regex configuration property.
To grant the user IMPERSONATE_USER permission, as an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Add Permissions.
Click the Select Permission dropdown, and select the IMPERSONATE_USER permission.
The Starburst (Trino) integration supports the native Starburst or Trino impersonation approaches:
JDBC method: In your JDBC connection driver properties, set the sessionUser property to the Immuta user you want to impersonate. See the Starburst JDBC driver documentation for details.
Trino CLI method: Set the --session-user property to specify the session user as the Immuta user you want to impersonate when invoking the Trino CLI. See the Starburst release notes for details.
To view the user you are impersonating, run SHOW SESSION like 'immuta.immuta_user'.
To end user impersonation, run RESET SESSION immuta.immuta_user.
To revoke permission to impersonate users, as an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Remove for the IMPERSONATE_USER permission.
The user's permissions to impersonate users are not checked until the query is run. If the user does not have the IMPERSONATE_USER permission in Immuta, they will be able to run the command to impersonate a role, but will not be able to query as that role.
Select Enable Impersonation when configuring the Snowflake integration on the App Settings page.
After enabling user impersonation with your Snowflake integration, there are two ways to give a user permission to use the feature: in the Immuta UI or in Snowflake. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Add Permissions.
Click the Select Permission dropdown, and select the IMPERSONATE_USER permission.
As a Snowflake user with the ACCOUNTADMIN role,
Navigate to your Snowflake instance.
In a worksheet run GRANT ROLE <<Impersonation_Role>> TO USER "<<Snowflake User>>".
In this example, the Impersonation Role is the name entered on the Immuta App Settings page when the feature was enabled. The default is IMMUTA_IMPERSONATION, but the admin may have customized it. The Snowflake User is the username of the Snowflake user that will now have permission to impersonate other users.
To impersonate another user in Snowflake,
Open a New Worksheet and set your role to the impersonation role specific to your organization.
Run SET immuta_user = '<<Immuta username of the user to impersonate>>'.
Run queries within that worksheet.
There are two ways to revoke permission to impersonate users: in the Immuta UI or in Snowflake. Use the tabs below to select one method.
As an Immuta user with the permission USER_ADMIN,
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Remove for the IMPERSONATE_USER permission.
As a Snowflake user with the ACCOUNTADMIN role,
Navigate to your Snowflake instance.
In a worksheet run the following: REVOKE ROLE <<Impersonation Role>> FROM USER "<<Snowflake User>>"
In this example, the Impersonation Role is the name entered on the Immuta App Settings page when the feature was enabled. The default is IMMUTA_IMPERSONATION, but the admin may have customized it. The Snowflake User is the username of the Snowflake user that will now have permission to impersonate other users.
Native impersonation is specific to the workspace and session in which it was set. Opening a new worksheet will revert the user back to themselves.
Snowflake auditing will show the user running the queries as the user logged in to Snowflake not as the user they are impersonating.
Immuta policies are dynamic and change for the user accessing data. Every user accessing policy-protected data must exist in Immuta, regardless of if they will interact with the Immuta UI.
Manage personas and permissions: Add, edit, and delete the permissions on your Immuta users.
Use native user impersonation: Enable, grant, and use user impersonation for Azure Synapse Analytics, Databricks, Redshift, Snowflake, or Starburst (Trino).
Manage attributes and groups: Add, edit, and delete user's attributes and groups.
Map user IDs: Ensure policies and audit work correctly by mapping the user's ID from the integration to Immuta.
Configure an external user info endpoint: Configure your IAM in Immuta to retrieve users' groups and attributes from an external HTTP endpoint.
Personas and permissions: This reference guide describes Immuta's permissions and the user personas that they apply to.
Attributes and groups: This reference guide describes attributes and groups in Immuta.
Click the People icon in the navigation and select the Users tab.
Click the New User button.
Fill out the Full Name and Email fields in the dialog. Note: The user's email address will be used as the username and must be unique.
Click the Create button.
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Add Permissions.
Click the Select Permission dropdown, and select the permission you want to give the user.
Click the People icon in the navigation and select the Users tab.
Select the user you want to disable, and click the more actions icon.
Select Disable User.
Click Disable in the confirmation dialog.
Requirement: USER_ADMIN permission
Note: This action permanently deletes all data associated with this user from Immuta, including data source subscriptions, and a timestamp of this event will be captured in the audit logs. The ability to create governance reports against this user will no longer be possible. This action cannot be undone.
Click the People icon in the navigation and select the Users tab.
Select the user you want to disable, and click the more actions icon.
Select Permanently Delete.
Click Permanently Delete User in the confirmation dialog.
Type Delete to confirm deleting the user permanently.
Click the Confirm Permanent Delete button.
Click the People icon in the navigation and select the Users tab.
Click the more actions icon and select Migrate User.
Enter their username in the modal that appears and click Migrate User.
Click the People icon in the navigation and select the Users tab.
Select the user you want to edit and select the Settings tab.
Click Remove on the permission you want to remove.
Click the People icon in the navigation and select the Users tab.
Click the Metrics button.
Complete the Number of Days field in the dialog that appears, and then click Download to download the JSON file.
Once an account has been disabled, it will not appear in the list of current Immuta users. To show the disabled accounts,
Click the People icon in the navigation and select the Users tab.
Use Filters to filter the table to Include Accounts and check the Disabled box.
Permissions are a system-level mechanism that control what actions a user is allowed to take through the Immuta API and UI and reflect their user persona. Permissions can be added to any user by a user admin, but the permissions themselves are managed by Immuta and cannot be added or removed in the Immuta UI.
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.
Auditors: Auditors can see and inspect all audit logs associated with Immuta and its integrations. This includes query, authentication, policy, project, and tag events from your Immuta users and data sources.
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. Once registered as a data source, the data owners have permission to set and on those data sources. Data owners can also build just like governors, but they are .
Data users: Data users consume the data available through Immuta in their data platform as usual.
Domain delegates: These users accountable to manage actions on data sources in a particular domain. This currently includes applying policies and auditing activity.
Governors: Governors set within Immuta, meaning they can apply policies across all data sources. Governors can ; manage all and ; and create , which are containers of data sources where users can be assigned a domain-specific permission to manage policies on only the data sources in those domains.
Project managers: These users inspect, manage, approve, and deny various project changes, including purpose requests and project data sources.
Project owners: These users can create their own project to get approvals for .
User admins: These users are 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.
The table below illustrates the global and domain permissions associated with each user persona.
| Permission | Scope | Persona | Actions |
|---|
Collecting Immuta usage metrics from customers helps Immuta gain insight into how customers are using Immuta (not who they are or what their data looks like) to understand what features are heavily used. These metrics guide improvements to the user experience.
The metrics collected are anonymized data points that provide information on Immuta feature usage but cannot be linked to an individual user or data source. Specifically, Immuta collects what workflows the users are completing and what the users are touching in the UI.
Workflows users are completing: These workflow metrics (creating policies, data sources, projects, etc.) are aggregates, such as the number of data sources created in a day, not individual events.
What users are touching: These metrics indicate what users click in Immuta, such as the create a data source button.
Product input: Input from customer metrics helps Immuta make product decisions. Providing your metrics is the best way to provide product feedback directly to Immuta.
Improve user experience: Insights into the activity of different personas (governors, data owners) can be used to improve the Immuta user interface and create meaningful feedback loops.
Internal insights: Gaining insights into your own Immuta use can reveal habit loops or pain points that users experience that may not be obvious. Metrics will enable those to be identified and improved.
Prove value: Quantifying the areas of Immuta that you are using the most is the key to understanding the value that Immuta brings to your organization.
External IDs for integrations can be mapped in for Snowflake, Databricks, Starburst (Trino), Redshift, and Azure Synapse Analytics based on attributes from an external IAM system, allowing you to link an external account to the corresponding Immuta account even when usernames do not match between Immuta and the external system.
External IDs for integrations can be mapped in for Snowflake, Databricks, Starburst (Trino), Redshift, and Azure Synapse Analytics based on attributes from an external IAM system.
Click the App Settings icon in the left sidebar and click Identity Management.
After you have clicked Add IAM, define the mapping in the Profile Schema section.
Note: Mappings can also be disabled on the App Settings page, so it’s possible that not all of these fields will be available.
Click Save.
Test a login to ensure that the values are picked up correctly.
For IAMs where no mapping has been defined (including Immuta's built-in IAM), the external user ID mappings can be set manually.
Click the People icon and select the Users tab.
Select the user you want to edit.
In the Usernames section, click Edit for the technology username you want to change.
Complete the Username field in the modal that appears and click Save.
For Databricks usernames,
Select Databricks Username to map the Databricks username to the Immuta user and enter the Databricks username in the field. Username mapping for Databricks is case insensitive.
Select Unset (fallback to Immuta username) to use the Immuta username as the assumed Databricks username. Use this option if the user's Databricks username exactly matches the user's Immuta username. Username mapping for Databricks is case insensitive.
Select None (user does not exist in Databricks) if this is an Immuta-only user. This option will improve performance for Immuta users who do not have a mapping to Databricks users and will be automatically selected by Immuta if an Immuta user is not found in Databricks. To ensure your Databricks users have policies correctly applied, manually map their usernames using the first option above.
For S3 usernames, use the dropdown menu to select the User Type. Then complete the S3 field. When selecting Unset (fallback to Immuta username), the S3 username is assumed to be the same as the Immuta username. User and role names are case-sensitive. See the for details.
All external IDs are displayed on the user details page and their user profile.
Identity access management best practice: Organize user attributes and groups in Immuta and then transfer them to your IAM.
Note: User Admins can add attributes in Immuta to external IAM groups using the Add Attributes button.
Attributes can be added to individual users or groups and then included in and to restrict what data users can see. They can be created by a User Admin in the Immuta UI or mapped in from an .
To learn how to add attributes to a user or group, navigate to the .
Individual users are added into groups, and then groups are used in and to restrict what data users in each group can see. Groups are also used in assigning members to . Users can belong to any number of groups and can be added or removed from groups at any time.
To learn how to create a group, navigate to the .
Click the People icon and select the Groups tab.
Click the New Group button.
In the modal, enter the new group's name. You can opt to enter a description of and email address for the new group.
Click Save.
Click the People icon and select the Groups tab.
Select the group you want to edit and select the Settings tab.
Click the Add Members button.
Begin typing in the Search by Member Name or Email text box.
Click on the name from the dropdown list to add this user to the group.
Authentication best practice: Use an for authentication and Immuta's internal IAM to manage attributes.
Click the People icon and select the Groups tab.
Select the group you want to edit and select the Settings tab.
Click Add Attributes.
Begin typing the attribute name in the Attribute text box.
If the attribute already exists, select it from the dropdown list.
If the attribute does not exist yet, enter the full name of the attribute, and then select it from the dropdown.
In the Attribute Value text box, enter a value.
If the value already exists, select it from the dropdown list.
If the value does not exist, enter the full name, and then select it from the dropdown.
Click Close.
Click the People icon and select the Groups tab.
Select the group you want to edit and select the Settings tab.
In the members section, click Remove to the right of the member you want to remove.
Click Delete to confirm.
Click the People icon and select the Groups tab.
Select the group you want to edit.
Click the more actions icon, and select Delete.
Click Delete to confirm.
Click the People icon and select Users or Groups.
Select the user or group you want to edit and select the Settings tab.
In the Attributes section, click the more actions icon on the attribute value you want to remove.
Click Remove and Confirm.
Immuta can consume user attributes from an external HTTP endpoint in an out-of-band fashion. This feature allows you to retrieve users' groups and authorizations from an additional resource, alongside the user attributes retrieved in the authentication flow. Such an external endpoint can be configured on any of the Identity Provider types that Immuta supports.
The following section instructs how to implement the HTTP service.
The service can authenticate requests with both or either of the following methods:
Basic username and password Authorization header
SSL cert validation
For more information, refer to .
Note: Immuta will expect non 200 error codes when the user info cannot be retrieved.
The user info endpoint will be called each time Immuta needs to synchronize with a remote IAM on user groups and authorizations. Immuta will query the endpoint with the user ID specified in request's query.
Note: The endpoint's path does not necessarily have to be /user-info.
Parameters
| Name | Located in | Description | Required | Schema |
|---|
Responses
Response Schema
Below is an example value that could be returned by the endpoint:
Click the App Settings icon in the left sidebar.
If you are modifying an existing IAM, click the name of the IAM. If you are creating a new IAM, click Add IAM.
At the very bottom of the IAM section, check the External Groups and Authorizations Endpoint checkbox.
In the External User Info URI field, enter the full path to your customer HTTP endpoint.
Optionally, check the Use Authentication checkbox and provide the username and password with which Immuta should authenticate when querying the user info endpoint. Immuta will subsequently send requests to the service with a Basic authorization header.
Optionally, enable SSL by checking the Enable SSL checkbox.
Optionally, if SSL is enabled, check the Require SSL Request Cert if your service requires SSL certificate validation. This step will require that you upload three files:
The SSL key file (*.pem)
The SSL cert file (*.pem)
The SSL CA file (*.pem)
Prerequisite:
You can also , which should be used for assigning .
There are several roles that can be assigned to users and groups for a specific data source. See the for a list of data source roles and descriptions.
| Code | Description |
|---|
| Name | Example |
|---|
200 | successful operation - user info retrieved successfully |
groups |
|
authorizations |
|
| query | The unique user identifier (username in Immuta) | Yes | string |
APPLICATION_ADMIN | Global | Application admin | Gives the user access to administrative actions for the configuration of Immuta. These actions include configuring integrations, adding external IAMs, and connecting external catalogs. |
AUDIT | Global | Auditor | Gives the user access to the audit logs |
Audit Activity | Domain delegate | Audit domain-related activity within particular domain(s) |
CREATE_DATA_SOURCE | Global | Create data sources |
CREATE_DATA_SOURCE_IN_PROJECT | Global |
CREATE_FILTER | Global | N/A | Create and save a search filter (This permission has been deprecated.) |
CREATE_PROJECT | Global | Project owner | Create projects |
FETCH_POLICY_INFO | Global | Data owner | Granted access to an endpoint that returns visibilities, masking information, and filters for a given data source |
GOVERNANCE | Global | Governor |
|
IMPERSONATE_USER | Global | Data user | Impersonate other Immuta users |
Manage Policies | Domain delegate | Create policies that apply to the domain(s) they are authorized to |
PROJECT_MANAGEMENT | Global | Project manager | Create purposes, approve and deny purpose requests in projects |
USER_ADMIN | Global | User admin | Manage user permissions, including domain-specific permissions on all domains |
Create within a project (This permission has been deprecated.)