Attributes

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 Data policies and Subscription policies to restrict what data users can see. They can be created by a User Admin in the Immuta UI or mapped in from an external IAM.

To learn how to add attributes to a user or group, navigate to the tutorial.

Groups

Individual users are added into groups, and then groups are used in Data policies and Subscription policies to restrict what data users in each group can see. Groups are also used in assigning members to projects. 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 tutorial.

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.

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. Once registered as a data source, the data owners have permission to set subscription policies and data policies on those data sources. Data owners can also build global policies just like governors, but they are restricted to only the data sources they own.

• Data users: Data users consume the data available through Immuta in their data platform as usual.

• Project owners: These users can create their own project to get approvals for purpose-based access controls (PBAC).

• Governors: Governors set global policies within Immuta, meaning they can apply policies across all data sources. Additionally they can leverage Detect, manage all tags, and manage all purposes.

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

• 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 Immuta permissions associated with each user persona:

Permissions

• 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 derived data sources within a project. This permission has been deprecated.

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

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

  • Adding and removing user permissions.

  • Creating and managing user attributes.

It is also possible to create custom permissions, which should be used for assigning manual subscription policy approvals.

User metrics

Purpose

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.

What is collected?

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.

Benefits

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