View access requests

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Opt to filter by status or sort the table by data product, status, or date.

View the access requests of a specific data product

In the Marketplace app,

1. Navigate to the Data Product you want to view requests for.

2. Click the Access Requests tab.

3. Opt to filter by status or sort the table by data product, status, or date.

View the approval record for a request

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Click the request you want the details for.

Respond to an access request

In the Marketplace app,

1. Navigate to the Access Requests page.

2. Click the request you want to approve or deny.

3. Review the request details, data sources, and data use agreement.

4. Select Deny or Approve:

   1. Deny: Enter your reason to deny access to the data product and click Confirm denial.

   2. Approve: Enter your reason to approve access to the data product and click Confirm approval.

Introduction

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.

Prerequisites

• Data platform integration configured in Immuta

• Users and data sources registered in Immuta

• The private preview of Marketplace has been enabled by your Immuta customer success representative

Governance and user admin users

Any user with the Immuta GOVERNANCE permission is able to publish data products in the Marketplace app. However, this job can be delegated by creating data product owners. You create data product owners by giving them the Manage Data Product 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 Product permission is handled by a user with USER_ADMIN permission.

These actions are completed in the Governance app, not the Marketplace app.

Data product owner user

This user is able to publish the data products, manage their metadata, and manage request policies. As mentioned above, to be a data product owner, one must have the global GOVERNANCE permission or the domain-specific Manage Data Products permission in a domain.

From there, data product owners are able to create and manage data products, from their domains, as depicted in Figure 3.

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 Product permission.

Making data sources available to a domain

Typically, you would give a data product owner CREATE permission in a schema or database that they can use as their sandbox for generating new tables/views natively in their data platform using data engineering tools like dbt. Those newly generated tables/views (or even S3 objects) are what they can use as the data sources for their data products.

How do you get these new data objects from the data platform as registered in Immuta and assigned to a domain so that they can be published in data products?

• Immuta automatically registers objects through periodic polling to detect changes in the data platform and represent those changes in Immuta, as data sources. These checks can also be manually triggered.

• Once the objects are registered in Immuta as data sources; they are assigned to a domain manually through the Governance app (or API). A user with GOVERNANCE permission must be involved to add new data sources to domains as they are created. However, this is a short-term limitation, Immuta will soon support automatically adding data sources to a domain based on the schema or database they reside in or based on how they are tagged.

Data consumer user

A data consumer can be anyone with a login to the Immuta. They can visit the Marketplace app, search for data products, and request access, as shown in Figure 4.

Data steward user

The data stewards are tasked with making determinations on Marketplace access requests, the final step in the workflow depicted in Figure 5.

Currently, in the Marketplace private preview, the users with the global GOVERNANCE permission or the domain-specific Manage Data Product permission in the domain must make the determinations on access requests to the data product. It is the default setting in the request policy for the data product. However, soon you will be able to assign any user as data stewards while creating the data product.

When an access request is made that requires approval, that request will appear as pending in the Marketplace, signaling a determination is required. The data steward can make the determination by approving or denying it with a reason, and if approved, Immuta will automatically provision the access, completing the workflow. Soon, there will be an option to approve temporarily access.

Soon the Marketplace app will support notifications (email, Teams, Slack, webhooks) which will allow the users assigned to make an determination on a request to be notified of this, as well as the requestors notified when a determination has been made.

Optional consideration

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.

Marketplace user types

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 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 to published data products. Once approved, the data consumer can query the data product , where the access is provisioned automatically.

Data product owners

Data product owners are able to manage data product metadata, what they contain, and .

Delegating to data product owners

The first step to delegating data product ownership is to establish domains in Immuta.

are containers for data sources that allow you to assign permissions scoped to the data sources in that domain. The permission for data product owners 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.

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 ownership for several reasons:

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

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

   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.

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

Data product owners are able to create, publish, and manage .

Requirement: Immuta permission GOVERNANCE or Manage Data Product in a domain

Creating a data product

From the Marketplace app,

1. Click Publish product.

2. Select the Domain from the dropdown. You will only be able to include data source from this domain in your data product.

3. Click Next.

4. Select the data sources you want to in the data product. .

5. Click Next.

6. Enter the following metadata for your new data product:

   • Name of the data product

   • Description of the data product (optional)

   • Enter the subject matter expert (optional). This should be a user that data consumers and stewards can reach out to for any questions about the data product.

7. Click Next.

8. Choose if you would like to require approval for access to this data product:

   • Yes: When the user requests access, in addition to acknowledging the data use agreement and answering the required question, they will need to be approved by one of the approvers. Approvers must have the global GOVERNANCE or domain-specific Manage Data Products permission.

   • No: When the user requests access, they will be automatically approved once they acknowledge the data use agreement and answer any question required for access.

9. Add a data use agreement (optional). You can create a data use agreement yourself or use the default data use agreement. The data use agreement is what the data consumer must agree to when requesting access to your data product.

10. Click Publish Data Product.

Editing data products

Once a data product has been created, many components can be edited from different parts of the data product:

• Details: Edit the name, description or subject matter expert

• Data sources: Add or remove data sources from the data product

• Request settings: Edit the required approval or the data use agreement

From the Marketplace app,

1. Select the data product.

2. Navigate to the tab with the information you want to edit.

3. Click Edit.

4. Make your edits and click Save.

Unpublishing data products

Data products can be unpublished. Unpublishing revokes all access to data sources in the data product that was gained from the manual approvals in the Marketplace. But the data product can be re-published to grant the approvals again.

From the Marketplace app,

1. Select the data product.

2. Navigate to the Advanced settings tab.

3. Click Edit.

4. Select Unpublished.

5. Click Save.

Deleting data products

It is also possible to completely delete data products which will also unpublish them, removing all users' access to the data sources through this data product. Deleting a data product cannot be undone.

From the Marketplace app,

1. Select the data product.

2. Navigate to the Advanced settings tab.

3. Click Edit.

4. Click Delete and then click Delete again.

Data products are what are published to the Data Marketplace by data product owners. They are typically highly curated and ready for consumption by the business.

They contain the following metadata:

• Name

• Description (optional)

• Subject matter expert (optional)

• Data use agreement (optional)

• Questions that must be answered by the requestor

• A collection of data sources

Data sources

represent any type of data that could be provided by a data product and registered in Immuta. These are currently tables and views from your data platform and objects from S3 storage. What data sources are available for the data product owner to add are dependent on the domain specified when creating the data product.

Editing the data product

Note that all data product settings are point-in-time of when the access request was made and approved. For example, if you change the data use agreement for a data product after it was approved for five users, those five users would remain approved under the previous data use agreement. Said another way: Immuta only updates the data product with the changes for new requests, not approved or pending requests.

The Immuta Data Marketplace was built from the ground up with security and provisioning of access in mind. It allows for the following actions:

• The delegation of to publish and manage on the Marketplace app.

• Data consumers can quickly discover and to published data products in the Marketplace app.

• Approvals have a direct impact on access. Once a user is approved, access is in the underlying data platform using powerful access policy management features.

Why use the Immuta Data Marketplace?

Supported use cases:

1. You have a concept of data products that need to be exposed to your internal lines of business for broader consumption.

2. You want data consumers to , not database roles, which is far more intuitive.

3. Your data products can be accessed from .

4. You want the option for data stewards to .

5. You want approvers to have about the request so they can make the correct determination.

6. You want approvals to automatically natively in the data platform.

7. You want the provisioning of approvals to be instead of one-user-at-a-time grants.

You should not use the Immuta Data Marketplace if:

1. You are trying to share and/or monetize data externally unless you own the data platform those external consumers leverage to query the data.

Immuta Data Marketplace architecture

The Immuta Data Marketplace 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.

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 and query activity.

• Discover and tag data automatically.

The Marketplace app:

Marketplace provisioning is really about making exceptions for specific users to get access to data when requested and approved. The key word there is "users".

With AWS, unless you have recently migrated to AWS Identity Center (IDC) then all your access is managed through IAM roles and not individual users. Because of this, Marketplace provisioning must be done to IAM roles instead of users, which means that if users share IAM roles then you end up in a situation where you over-provision (to everyone in the IAM role) upon Marketplace approval.

See below for the best practices to avoid this behavior.

Best and recommended option: Migrate to IDC

IDC is the best and AWS recommended approach because it treats users as users, not users as roles. And because of this, Marketplace provisioning upon approval is for the user that requested access and was approved, nothing more. No over-provisioning, only granular exceptions.

Second best option: IAM role per user

Create an IAM role per user that is unique to that user and assign that IAM role to each corresponding user in Immuta. Ensure that the IAM role cannot be shared with other users. However, this approach can be a challenge because there is an IAM role max limit of 5,000 per AWS account which is one reason why IDC is the better approach.

Final option: Request on behalf of IAM roles

In this approach, you create "users" in Immuta that map to each of your existing IAM roles. Then, when users request access to data products through the Marketplace, they request on behalf of the IAM role "user" rather than themselves.

This is a poor approach because, again, it will mean everyone in that role will gain access, and adding future users to that role will also bypass approvals. But worse, it requires the approver to understand what role should have access to what (not to mention what users are already in that role) in order to make a reasonable determination on the request.

This section is for understanding Marketplace and data products.

How-to guides

• Manage data products: Create and manage new data products in Marketplace.

• View and respond to access requests: Approve and deny access requests from users trying to access your data products.

Reference guides

• Data products reference guide: This reference guide describes data products and their features.

• Marketplace permissions matrix: This reference guide describes Immuta permission and the actions users with those permissions can take in the Governance and Marketplace app.

• Understanding access provisioning and underlying policies: This reference guide describes how Marketplace data products and actions work to create policies to govern access in the data platform.

• Integrating with existing catalogs: This reference guide describes how to connect data products in your existing catalogs with data products in Marketplace with automated deep links.

One of the key benefits of using the Immuta Marketplace app is that access provisioning is automatic: if you're approved access, Immuta is able to automatically provision the access to the data sources in the data product natively in the data platform(s) using existing Immuta Governance app capabilities.

Furthermore, how that provisioning occurs avoids leaking implementation details by not exposing roles to data consumers at all. Data consumers request access to data products, not roles, and Immuta calculates the most efficient policy within the data platform to represent that access, on demand, invisibly to the user. This is done by leveraging the Immuta attribute-based access control (ABAC) logic that Immuta has perfected since its inception.

Below are the actions Immuta takes in order to provision access:

Before any data products are created

Immuta creates a single policy that is on standby, ready to service data product access approvals. With just this single policy, all access requests can be provisioned. That policy has the following logic:

Allow users to subscribe when @hasTagAsAttribute('Immuta Marketplace', 'dataSource')

On data sources tagged Immuta Marketplace Data Product

The Share Responsibility option is also checked in the policy.

This policy is protected and cannot be altered or deleted.

When a data product is created

Each data source in the data product is automatically tagged with the following tag, which cannot be removed except by un-publishing or deleting the data product:

Immuta Marketplace Data Product.[data product ID]

The Immuta Marketplace Data Product tag is protected and cannot be applied to other data sources manually.

When a user is approved to a data product

The user that was approved access has the below attribute added to them, which cannot be removed unless the user is manually revoked access from the Marketplace or the data product is deleted:

Immuta Marketplace: Immuta Marketplace Data Product.[data product ID]

More explicitly, the attribute key = Immuta Marketplace and the attribute value = Immuta Marketplace Data Product.[data product ID]

The attribute key Immuta Marketplace is reserved and cannot be applied to users manually, nor can additional values be manually added to that attribute key.

That simple step of Immuta automatically adding that attribute to the user upon approval will trigger Immuta to provision the access in the native data platform(s) per the policy.

If you would like to understand how the policy is translated into an actual set of grants in your data platform, please review the integration documentation for the specific data platform.

Understanding the policy

Let's break the policy down step by step:

Allow users to subscribe when @hasTagAsAttribute('Immuta Marketplace', 'dataSource')

What this policy is saying is that it will check the user's attributes under the key Immuta Marketplace and see if anything under that key matches a tag on the data source.

Using a real example, let's say our data product ID is cm4bn6jpi0018wvprctnj5er2 and user Taylor was approved access to it:

• Each data source in the data product would be tagged: Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2

• Taylor would be given the attribute value Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2 under the attribute key Immuta Marketplace. There could already be several other values (the values are an array) under that Data Product key providing Taylor access to other data products.

As you can see, at least one of Taylor's attribute values (Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2) under attribute key Immuta Marketplace matches the tag on the data source (Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2), so Taylor will be provisioned access by Immuta as soon as that attribute is attached to Taylor (or the tag is attached to the data source, as long as they both match, access is automatically provisioned). This is ABAC.

However, there's two additional pieces worth understanding:

1. On data sources tagged Immuta Marketplace Data Product means that this policy will only apply on data sources with the On data sources tagged Immuta Marketplace Data Product tag.

1. Share Responsibility means that if this policy is merged with existing birthright policies, it will be OR'ed together with the existing policy. Should the policy, the one being merged with, have Always Required then it will be AND'ed with this policy, which is what rightfully can cause access to not occur even if approval was given.

This single policy is able to handle all possible data products because it's driven purely based on matching the user attribute values to the data source tags. So simply updating the attributes and tags drives the policy into action.

Anything a Data Steward can do -> a Data Product Owner can do; anything a Data Product Owner can do -> a user with GOVERNANCE permission can do.

And the scope of their permissions grow as you move up the layers:

See the table below for the full breakdown of what Marketplace actions require which Immuta permissions:

If you would like data consumers to discover data products through your existing catalog rather than through the Immuta Marketplace app, this is possible, by redirecting requests for access from your catalog to the Marketplace app. However, we do feel .

Integration is made possible through deep link URLs provided by the Marketplace app that direct the user to the request access screen for any given data product. At a high level the workflow looks like this:

• A data product is created in your catalog that the same data product in the Marketplace app

• The consumer discovers data product in your catalog

• The consumer from your catalog to the request access page for that mirrored data product in the Marketplace app

• From this point forward, the works the same

Mirroring data products

In order to request access to a data product, your catalog must have a mirrored representation of the corresponding data product that exists in the Marketplace app. Depending how you configure the redirect, it's likely these need to be named exactly the same so that the works correctly and you don't confuse your data consumers.

Right now you must separately create the data product in your catalog, but once Marketplace supports webhooks, it will be possible to listen to those to automate creation in your catalog when created in the Marketplace app.

Redirecting in order to request access

To support redirects, Marketplace exposes deep link URLs to the request access page for each data product, that URL can be built two ways:

Data product name URL option

Data product ID URL option

Make sure that if you use the {data product name} URL option that if you change the data product name in the Marketplace app, you also change it in the URL/catalog. Note that in Marketplace all data product names must be unique.

Catalog redirect approach recommendations

The following are only recommendations for popular catalogs, you can do this however you feel appropriate and can reuse some of these approaches in different catalogs or custom marketplace applications you may have built yourselves.

Collibra

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. The most common approach we've seen customers take with Collibra is the following:

• Domain (which contains the data product(s)) = Collibra Collection

• Data product (which contains the data source(s)) = Collibra Data Set

• Data source = Collibra Data Asset

A Collibra custom workflow can be leveraged to redirect to the Marketplace app to request access. We have a sample workflow created you can download. This workflow was exported in a way that allows you to see its workflow "code" in the Collibra Workflow designer should you want to make changes.

Once you are happy with the workflow "code" you must deploy it (top right of the designer) and then configure Collibra:

• Uncheck "Show in global create"

• This workflow "attaches" to a Data Set by configuring the "Applies To" in Collibra to a Data Set. You can change this to whatever object you represent data products with in Collibra.

• Ensure the variables are empty

• For the "Start Events" choose "Workflow Started"

• Under "Other" ensure "Any user can start the workflow"

• Save

Alation

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. There is not an obvious approach to this in Alation; the best we've seen is:

• Domain (which contains the data product(s)) = Alation Glossary

• Data product (which contains the data source(s)) = Alation Domain

• Data source = Alation Data

We hope to work closely with Alation to make this smoother in the future - ask them about it!

Atlan

The first thing to consider when linking a catalog is how you appropriately represent a domain, data product, and data source in that catalog should it not have those object types. Thankfully, Atlan's object mapping is very close to the marketplace app:

• Domain (which contains the data product(s)) = Atlan Domain

• Data product (which contains the data source(s)) = Atlan Data Product

• Data source = Atlan Data Asset

We hope to work closely with Atlan to make this smoother in the future - ask them about it!

Always request/approve in the Marketplace app

While you are able to create request and approval flows in some catalogs and even other tools, we do not recommend you do this. Doing data request and approval flows in Immuta has various benefits and future benefits:

• When approved, the access is automatically provisioned in the data platform

• Provides full audit and reporting (coming soon) of requests/approvals

• • In the future, we intend to provide even more details to make the access determination as accurate and meaningful as possible:

    • More details about the requestor (attributes and groups)

    • What is in the data

    • Existing queries and types of questions asked of the data

    • Existing access/denials and why

• Request policies will be able to be dynamically configured based on the risk level of the data product (coming soon). For example, if the data product contains PII and the requestor is a contractor: require x approvers and y data use agreement. Conversely, if the data does not contain PII and the employee is an internal employee: grant automatic access, etc.

• Access requests can be temporarily approved which can avoid recertifications (coming soon)

• Access requests to data can be as granular as you need, even down to column and row (coming soon)

This section is for the data consumers that want to access data products in Marketplace. These data consumers are the users that search for, discover, and to published data products. Once approved, the data consumer can query the data product where the access is provisioned automatically.

How-to guides

• : Sign into Marketplace for the first time.

• : Request access to a new data product in Marketplace.

Reference guide

: This reference guide describes the way that Marketplace grants access to data sources through data products and how that combines with current policies in the Governace app.

The Marketplace app is a multi-tenant service that can talk to multiple Governance apps, but you can only login to one at a time.

Visit the Marketplace by going to this URL:

The login screen will ask you which Governance app account identifier to point Marketplace to when you login. This can be found in the your governance app URL:

Ensure you select the Governance app account identifier that has the Marketplace feature enabled.

Once logged in, it is possible to switch which Governance app you are pointing to using the "Sign into another account" option under your profile menu.

If the data consumer is interested in using the data product, from the listing or the detailed view, they are able to request access (READ only):

• If there is no approval necessary, they will be automatically granted access after acknowledging the data use agreement and answering the required question(s).

• If there is approval necessary, it will kick off the approval flow. While in the approval flow, the Marketplace will display that data product listing as Pending.

Once the user has been approved access to the data product, the data product listing will show Member. Data consumers are able to filter the data product list page by states to see what data products they already have access to.

Requesting access to a data product

From the Marketplace app,

1. Click into the Data Product you want access to.

2. Click the Request access button.

3. Review the on the Request Access page

4. Fill out your answer to the access question, if there is one (this is required even if there is no manually approval required).

5. Review and agree to the Data Use Agreement, if there is one.

6. Click Submit Request.

Marketplace is a private preview feature and has several known limitations that will be addressed by end of Q1 2025.

Known short term limitations

No API support

Everything will be backed by APIs, and APIs will be a first class citizen of Marketplace. However, we are still working through API authentication, and due to this, they are not available for use, yet, but will soon.

No notifications

Users must visit the Marketplace to see pending requests or request status. Soon notifications will be supported for email, webhooks, Teams, Slack.

Searching within the Marketplace

You are able to search by data product name and description. In the future, we intend to add rich search and discovery capabilities using LLMs that leverage details about the data, the users, the request question answers, and audit history to make recommendations based on described use case by the consumer (this will be an ongoing effort that will not be completed in Q1 2025).

Data stewards cannot be assigned

cannot be assigned to manage approvals. Only users with GOVERNANCE permission or Manage Data Product in the domain where the data product was created can make determinations on requests. Soon assignment of data stewards will be supported.

Questions asked as part of an access request cannot be changed

All data products will have the same hard coded question asked of every user that requests access to it: What about your responsibilities, your use case, and this data requires you to have access to this data product? Soon, managing the questions asked will be fully configurable and reusable, similar to data use agreements.

Policy, tag, and user attribute administration in Immuta is unprotected

Domains do not support dynamically adding data sources

Always required subscription policies will revoke access

This is problematic for Marketplace because the policy that does the provisioning via Marketplace upon approval is merged with any existing subscription policies on the data sources in the data product. That means if your subscription policy is Always Required it will merge with the Marketplace policy using an AND and revoke all existing users access until they are approved through the Marketplace.

To avoid this, if you are not leveraging subscription policy merging today, convert your Allow users with specific groups/attributes subscription policies that touch data sources in your data products from Always Required to Share Responsibility.

Soon Immuta will alter this behavior in a way that allows you to keep using Always Required as normal, but not result in existing users losing access.

Some obsolete subscription policies and their settings still exist

• Subscription policy type Allow anyone who asks (and is approved) is still available, but is obsolete, because you should be doing this in Marketplace instead. If you have some of these policies, we recommend the following:

  • Convert the data sources the policy targets to a data product.

  • Publish the new data products in Marketplace to allow users to ask for access.

  • Delete the previous subscription policy.

• Subscription policy type Allow users with specific groups/attributes can still be used, but some of the settings are unnecessary with Marketplace:

  • Require Manual Subscription: If you are using this setting, instead use the following workaround:

    • Create a separate subscription policy that targets the same data sources:

      • The Allow users with specific groups/attributes requires you are in a group that contains no users (meaning it subscribes no one)

      • It is set to Share Responsibility

    • Uncheck the Require Manual Subscription option in the existing policy

    • Ensure all data sources this policy targets are published in the Marketplace in data products

    Once you complete those steps, the shorthand version of your merged policy per data source will look like this, achieving the same goal: allow users to subscribe who are members of group [your original requirement] AND (are members of group [nobody] OR approved in Marketplace). Soon Immuta will make it easier to set a "required" subscription policy that does not auto-subscribe until access is requested (and potentially auto-approved) in Marketplace.

  • Allow Data Source Discovery: Instead of this setting, simply publish the data source to the Marketplace in a data product.

  • Request Approval to Access: Instead of this setting, consider converting the data sources these policies target to data products in the Marketplace, and allow the approvals to happen there.

Soon these obsolete subscription types will be altered and/or deprecated.

Limited audit

Marketplace actions are not audited yet; that is coming soon.

Approvals cannot be time bound

Currently an access request can be approved or denied. Soon approvals will support being time bound. For example, you are temporarily approved for 30 days, or you are temporarily approved until December 25th 2024.

Pending requests

All pending requests by the data consumers are listed and contain:

• What data product was requested

• When the request was made

• What set of users can approve

• Its current state:

  • Pending (These can be canceled by the requestor.)

  • Processing

Mixing approvals with birthright policies that are required

Just because a data consumer is approved to a data product does not necessarily mean they will gain access to every data source in that data product. It is possible there are existing birthright policies on those data sources that the requesting user does not meet, and if those policies are , the user cannot gain access to the data product, even if approved.

For example, there may be sensitive employee salary data in a data source. Because of that, there is a birthright on that data source that is always required which states, only members of group HR can access this data source. This is effective; it provides global governance a guarantee that nobody can bypass policies on extremely sensitive data sources.

If that data source is now made part of a data product, the requesting user must be a member of group HR to gain access to that particular data source in the data product, even if approved to the data product. Should that policy change in a way that the user now meets the requirements or the user is added to group HR, Immuta will react by updating the policy. The user would then have access to that particular data source.

To provide transparency, the request access page will display the following information about each data source in the data product so the requestor is clear what they will, won't, and already have access to:

• 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 not)?