User Types

Private preview: The Marketplace app is available to select accounts. Contact your Immuta representative for details.

Marketplace user types

By leveraging the Marketplace app, you introduce three new user types in your Immuta deployment:

Data product manager: These users own the management of the metadata around the data products and publish the data products.

Data steward: These users process the data consumer access requests to deny or approve access. Currently, these are users with the global GOVERNANCE or the domain-specific Manage Data Products permission.

Data consumers: These are the users who search for, discover, and request access to published data products. Once approved, the data consumer can query the data product natively in the data platform, where the access is provisioned automatically.

Data product managers

Data product managers are able to manage data product metadata, what data sources they contain, and publish data products to the data marketplace.

Any user with GOVERNANCE permission is able to publish data products. However, it is possible to delegate data product management to users without giving them the power that comes with GOVERNANCE permission.

Delegating to data product managers

The first step to delegating data product management is to create domains in Immuta, which can be completed by a user with GOVERNANCE permission.

Domains 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 data sources assigned to those data products can only be sourced from a domain where they have this Manage Data Products permission.

Why domains?

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:

1. It avoids data product managers publishing data products that contain data sources they should not be publishing.

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

3. 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:

   1. The HR users in charge of policies (subscription and data policies) Manage Policy permission in the HR Domain,
   2. The HR users in charge of tagging Manage Tags permission in the HR Domain and finally,

   3. The HR users in charge of publishing data products Manage Data Products permission in the HR Domain.

Data stewards

Data stewards process the data consumer access requests to deny or approve access. Currently, these are users with the global GOVERNANCE or the domain-specific Manage Data Products permission.

Request details

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 Data Marketplace, specifically the approval 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 access page.

• 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 existing access details:

  • If the user already has access via a birthright subscription policy

  • If the user cannot gain access due to an existing birthright subscription policy

What happens once approved or denied?

If approved, access 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 tables/views/S3 objects directly from the data platform. This provisioning is represented as an understandable and scalable Immuta policy that will be combined with any existing policies.