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. Attributes can be created by a user with the USER_ADMIN permission in the Immuta UI or mapped in from an external IAM. Attributes can be added to groups created in Immuta or ingested from an external IAM.
Attributes can be viewed on the attributes tab in the Immuta UI; however, they only exist in relation to users or groups. Once an attribute is no longer attached to any user or group, it will be automatically cleared from Immuta.
To learn how to add attributes to a user or group, navigate to the tutorial.
The following attribute-related events are and can be found on the :
: An attribute is applied to a user or group.
: An attribute is removed from a user or group.
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 .
The following group-related events are and can be found on the :
: A group is created in Immuta by user actions in the UI or ingested from an external IAM.
: A group is deleted in Immuta by user actions in the UI or from within an external IAM.
: A user is added to a group in Immuta by user actions in the UI or from within an external IAM.
: A user is removed from a group in Immuta by user actions in the UI or from within an external IAM.
GroupUpdated: A group's details (email, name, description, etc.) are updated.
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, auditing activity, managing identification, and creating Marketplace data products.
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.
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.
The following permission-related events are and can be found on the :
: A global permission is applied to a user.
: A global permission is removed from a user.
: A domain-specific permission is applied to or removed from a user or group.
License consumption is determined by the count of enabled users on your Immuta tenant. Enabled users are one of these user types:
Policy owners: Enabled users are counted as policy owners if they meet one of the following criteria:
User has one of the following global permissions (directly assigned or via group-based permission): CREATE_DATA_SOURCE, GOVERNANCE, USER_ADMIN, APPLICATION_ADMIN, IMPERSONATE_USER, PROJECT_MANAGEMENT,
To view the current level of license consumption for your Immuta tenant, see the .
Collecting Immuta usage metrics from tenants helps Immuta gain insight into how organizations 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 user 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.
CREATE_DATA_SOURCE
Global
Data owner
CREATE_DATA_SOURCE_IN_PROJECT
Global
Data owner
Create within a project. This permission has been deprecated.
CREATE_FILTER
Global
N/A
. This permission has been deprecated.
CREATE_PROJECT
Global
Project owner
FETCH_POLICY_INFO
Global
Data owner
Grants that returns visibilities, masking information, and filters for a given data source
GOVERNANCE
Global
Governor
that apply to any data sources (inside or outside domains)
IMPERSONATE_USER
Global
Data user
Manage Data Products
Domain delegate
in the
Manage Identifiers
Domain delegate
within a domain
Manage Policies
Domain delegate
(s) they are authorized to
PROJECT_MANAGEMENT
Global
Project manager
and
USER_ADMIN
Global
User admin
, including domain-specific permissions on all domains
FETCH_POLICY_INFOAUDITUser has the Manage Policies domain-level permissions on at least one domain (directly assigned or via group-based permission)
User has one of the following data source level permissions on at least one data source (directly assigned or via group-based permission): owner or expert
Data consumers: All enabled users that do not meet any of the criteria for policy owners are counted as data consumers.
APPLICATION_ADMIN
Global
Application admin
Gives the user access to administrative actions to configure Immuta (e.g., configuring connections, adding external IAMs, connecting external catalogs, etc.)
AUDIT
Global
Auditor
Gives the user access to the audit logs
Audit Activity
Domain delegate
Audit domain-related activity within particular domain(s)