Figure 1 depicts the workflows available in the Immuta Marketplace. This walkthrough will guide you through these steps.
Some of these steps are performed by different user types in Immuta, so this walkthrough is organized by Marketplace user type.
See the Marketplace app requirements page.
The data sources that are exposed through your data products are sourced from a domain; so in order to publish a data product, you must have at least one domain with at least one data source in it. Any user with the Immuta GOVERNANCE permission is able to publish data products in the Marketplace app using any domain. However, this job can be delegated by creating data product managers. You create data product managers by giving them the Manage Data Products permission in a domain.
As shown in Figure 2, creating a domain and assigning data sources to it is handled by a user with GOVERNANCE permission. Assigning the Manage Data Products permission is handled by a user with USER_ADMIN permission.
These actions are completed in the Governance app, not the Marketplace app.
This user is able to publish the data products, manage their metadata, and manage request forms. As mentioned above, a data product manager must have the global GOVERNANCE permission or the domain-specific Manage Data Products permission in a domain.
From there, data product managers are able to publish and manage data products, from their domains, as depicted in Figure 3.
When a new data product is published, a webhook is sent off and users with Manage Data Products permission in that data product's domain will receive a notification.
However, the first step in creating a data product is ensuring that the data sources that make up the data product are contained in the domain where you have the Manage Data Products permission.
See the Setting up domains for Marketplace page for details about how to automatically have data sources be assigned to domains.
A data consumer can be anyone with a login to Immuta. They can visit the Marketplace app, search for data products and request access to them, or request masking exceptions on specific columns within those products, as shown in Figure 4.
Once they request access, a webhook is sent off and Immuta will send notifications to the data stewards of the data product.
The data stewards are tasked with making determinations on Marketplace access requests, the final step in the workflow depicted in Figure 5.
Data stewards are assigned to data products in the request form used; they can be assigned based on their group, attributes, or permissions or the exact user can be assigned. If the data stewards are not assigned in a request form, the data product owner will select them for each data product. The request form will also dictate if any data steward can approve an access request or if all of them must.
When an access request is made that requires approval, a webhook is sent off and data stewards will receive a notification with the request. Additionally, it will appear as pending in the Marketplace, signaling a determination is required.
The data steward can make the determination by approving, denying, or temporarily approving it with a reason. If approved, Immuta will automatically provision access by granting data product access in the data platform or unmasking the approved columns, completing the workflow depending on the request type. When any data steward can approve, just a single determination will dictate the user's access. However, if all data stewards must approve, one determination must be made by one data steward belonging to each of the assigned groups, attributes, or permissions. If a single data steward denies access, the user will not get access.
When a final determination is made for an access request, a webhook is sent off and the requester and all other data stewards for the data product will receive a notification with the decision.
Consider branding the Marketplace app with your own logo and colors, to give it the look and feel of your company.
If you would prefer that data consumers discover data products in your existing catalog, that is possible to configure. The Marketplace app is built in a way so it can present the access request page to the consumer via redirects from your catalog.
The Immuta Marketplace app was built from the ground up with security and provisioning of access in mind. Access can refer to either access to an entire data product and its objects or access to the unmasked data within specific masked columns within data products. Using the Marketplace app allows for the following actions:
The delegation of data product managers to publish and manage data products on the Marketplace app.
Data consumers can quickly discover and request access to published data products or request a masking exception for masked columns in the Marketplace app.
The delegation of data stewards to receive requests for access and make determinations on them.
Approvals have a direct impact on access.
Once a user's data access request is approved, access is auto-provisioned in the underlying data platform using powerful access policy management features.
Once a user's masking exception request is approved, Immuta data policies automatically unmask the specified columns.
Personalization of the Marketplace app with your brand's logo and colors to give it your own look and feel.
You have a concept of data products that need to be exposed to your internal lines of business for broader consumption.
You want data consumers to request access to data products, not database roles, which is far more intuitive.
You want data consumers to request masking exceptions on masked columns, with requests that capture user details and justifications.
Your data products can be accessed from multiple different data platforms.
You want the option for data stewards to approve (or deny) access.
You want the option to approve access for a set period of time.
You want approvers to have additional details about the access requests so they can make the correct determination.
You want approvals to either automatically provision access natively in the data platform or provide exceptions to masking policies on specific columns.
You want the provisioning of approvals to be represented as scalable policies instead of one-user-at-a-time grants.
You want requests for data to be initiated from your catalog but fulfilled and provisioned in an automated manner.
You already have tools in place to do some of the above, but want to streamline provisioning of access using the Marketplace APIs.
You are trying to share and/or monetize data externally (unless you own the data platform those external consumers leverage to query the data).
You want to automate access completely, doing away with manual approvals. You can accomplish this using data governance policies in the Governance app.
The Marketplace app is a separate experience from the existing Immuta Governance app, but some actions to set up the Marketplace app must be completed in the Governance app.
Register tables, views, or files as data sources.
Manage birthright policies with global subscription and data policies. Birthright policies are policies that are pre-computed through rules and do not require manual approvals.
View reports and monitor Immuta activity and user query activity.
Discover and tag data automatically.
Configure data domains and permission users to be data product managers, allowing them to publish data products from that domain.
Customize the branding of the Marketplace app.
Data product managers manage and publish data products (from their assigned domains).
Data stewards receive and process access requests to data products.
Data consumers discover and request access to data products.
By leveraging the Marketplace app, you introduce three new user types in your Immuta deployment:
: These users own the management of the metadata around the data products and publish the data products.
: These users process the data consumer access requests to approve, deny, or temporarily approve access to data products or masking exceptions on specific columns. They are assigned to data products or request forms.
Data consumers: These are the users who search for, discover, and to published data products or request masking exceptions on masked columns. Once approved, the data consumer can query the data product , where the access is provisioned automatically or the masking policy is updated to ensure the user can query data that is not masked.
Data product managers are able to manage data product metadata, add , , and actually .
Any user with GOVERNANCE permission is able to publish data products. However, you can also to users without giving them the power that comes with GOVERNANCE permission.
The first step to delegating data product management is to create domains in Immuta, which can be completed by a user with GOVERNANCE permission.
are containers for data sources that allow you to assign permissions scoped to the data sources in that domain. The permission for data product managers is Manage Data Products that can be assigned within a domain by a user with USER_ADMIN permission from within the Governance app.
When a user has the Manage Data Products permission and visits the Marketplace app, they can define and publish data products. Additionally, the assigned to those data products can only be sourced from a domain where they have this Manage Data Products permission.
The purpose of domains in Immuta is to create scoped areas of responsibility for Immuta permissions. If given a permission on a domain, that permission is scoped to and can only act upon the data sources in that domain.
This is optimal for delegation of data product management for several reasons:
It avoids data product managers publishing data products that contain data sources they should not be publishing.
It allows the organization of domains of your data into Immuta domains. For example, every data source tagged with HR could be configured to land in the HR Domain automatically, making them available for data products by the data product managers in that domain.
It allows you to group teams of users with different responsibilities together with permissions scoped to the same set of data sources. For example, you could give:
The HR users in charge of policies ( and ) Manage Policy permission in the HR Domain,
The HR users in charge of tagging Manage Tags permission in the HR Domain and finally,
The HR users in charge of publishing data products Manage Data Products permission in the HR Domain.
Data stewards process the data consumer access requests to approve, deny, or temporarily approve access to data products and masking exception requests. These users are assigned as data stewards in request forms or on specific data products. Data stewards can be granted stewardship based on the following sources:
Global permission (e.g., GOVERNANCE)
Domain-specific permission for the domain the data product is built from (e.g., Manage Identifiers)
Group
Attribute
Username (i.e., selecting a specific user)
The data steward has a difficult job; historically, they have been asked to make extremely subjective determinations on access requests with too little information. The Immuta Marketplace app, specifically the access requests page, resolves that problem by presenting a range of request details all in a single view, making the data steward's job much easier.
The following information is in each request to help the data steward with their decision:
The requestor's answers to the required question(s) from the request form.
Confirmation that the requestor has agreed to the data use agreement, if there is one. The data use agreement can also be viewed through a link.
The last five approvals (if available) and denials (if available) on the data product with details about each: when they happened, who was approved or denied, who approved or denied them, and why.
This will help the approver understand if the user requesting access aligns with the past five users and the people who have already made approvals in case there are questions.
For each data source in the data product, any :
If the user already has access via a birthright subscription policy
If the user cannot gain access due to an existing birthright subscription policy
Any other approvals that have already been given for the access request and the reason for approval.
Masking exception requests will also include column-level details about the requested columns including the following:
Column names
Column tags
Masking policies applied to the column
Access requests may require a single approval or the approval of all data stewards depending on the configured request form. This can impact the effect of the determination:
If an access request requires any data steward's determination, then once a single data steward makes a determination, it goes into effect.
If approved:
For data products, access to the data objects will be auto-provisioned in the data platform(s) to the data sources in the data product. This is done natively in the data platform, which means the requesting user can query those data objects directly from the data platform. This provisioning is represented as an that will be combined with any existing policies.
For masking exceptions, approved columns will be auto-provisioned with unmasked access in the data platform(s) where you have access to the data source. This exception to the masking policy is represented as an that will be combined with any existing policies.
If denied, the user will not be granted access to the data product or the columns requested.
If an access request requires all data stewards' determinations, then for every group, attribute, or permission listed in the request form, a data steward from that source must make a determination. If a data steward qualifies multiple sources, their determination will count for each of the sources they have. For example, if the request form lists users with the GOVERNANCE permission and users with the HR group as data stewards, then one user with the GOVERNANCE permission and one user with the HR group must approve to satisfy each of those conditions. A single user may approve for all conditions in a request form if they have the necessary permissions.
Once a determination is made by every source listed in the request form, it goes into effect.
If approved:
For data products, access to the data objects will be auto-provisioned in the data platform(s) to the data sources in the data product. This is done natively in the data platform, which means the requesting user can query those data objects directly from the data platform. This provisioning is represented as an that will be combined with any existing policies.
For masking exceptions, approved columns will be auto-provisioned with unmasked access in the data platform(s) where you have access to the data source. This exception to the masking policy is represented as an that will be combined with any existing policies.
If denied by even a single data steward, the entire access request is denied and the user will not be granted access to the data product or its data objects.
If there is a mix of approvals and temporary approvals, the user will be approved access to the data product or column for the shortest time period any of the data stewards picked.
