Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.
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.
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.
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.
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.
Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.
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 it is beneficial to have a separate user experience for consuming data products (Marketplace app) from creating them (catalog).
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 mirrors the same data product in the Marketplace app
The consumer discovers data product in your catalog
The consumer initiates a redirect from your catalog to the request access page for that mirrored data product in the Marketplace app
From this point forward, the access request works the same
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 redirect 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.
To support redirects, Marketplace exposes deep link URLs to the request access page for each data product, that URL can be built two ways:
The data product ID can be found by examining the data product details page's URL here: https://app.immutacloud.com/marketplace/data-product/{data product id}/details or by simply clicking the Request access link button found on the data product details screen, which will place the above URL in your clipboard. These URLs will direct the user to the data product's access request screen, and if they are not authenticated, the Marketplace login screen, with a redirect back to the access request screen.
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.
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.
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.
This workflow is intended to be an example you can use and is not part of the Immuta software product nor SLAs.
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
Once complete, when you visit a Data Set in Collibra there should be a new action "Request Access through Immuta". When clicked, a modal will appear asking to request access, and when selected, will dynamically redirect to the appropriate data product in the Immuta Marketplace app using the data product name URL option. Note that although Collibra is supposed to URL encode special characters from this workflow, it only appears to do so for spaces and not other characters like parentheses, so limit special characters in your data product name.
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
Unlike Collibra, there is not a dynamic way to redirect to the Marketplace app to request access. Instead, we recommend that you include a Description in the Alation Domain which includes a hyperlink to request access using the data product ID URL option.
We hope to work closely with Alation to make this smoother in the future - ask them about it!
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
Unlike Collibra, there is not a dynamic way to redirect to the Marketplace app to request access. Instead, we recommend that you include a READ ME in the Atlan data product which includes a hyperlink to request access using the data product ID URL option.
We hope to work closely with Atlan to make this smoother in the future - ask them about it!
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
The person making a determination on a request is presented with details about the request in order to make a meaningful access decision. Furthermore, users doing approvals to data are different from the users doing approvals to applications, and require a more specific process and workflow more coupled to the data platform and its metadata
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)
Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.
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 that Immuta has perfected since its inception.
Below are the actions Immuta takes in order to provision access:
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.
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.
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.
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:
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.
Tag hierarchy is dot . notated in Immuta, so even though this only says Immuta Marketplace Data Product it will work on data sources tagged Immuta Marketplace Data Product.cm4bn6jpi0018wvprctnj5er2 because it matches the root tag in the hierarchy.
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.
If you would like to understand how the policy is translated into an actual set of grants in your data platform, please review the for the specific data platform.
Share Responsibility means that if this , 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 .
Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.
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.
Can act in each data product they are assigned to
Can act in the domain they have the Manage Data Product permission in
Can act across all of Immuta, regardless of domain
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:
Create a domain
Yes
Grant Manage Data Products in a domain
Yes
Manage a data product
Yes
Yes
Make access request determinations
Yes
Yes
Yes
Alter a data product
Yes
Yes
Yes (partial)
Create an access request
Yes
Yes
Yes
Yes
Revoke a member from a data product
Yes
Yes
Yes
Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.
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
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.
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.