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."
If you manage access in AWS through IAM roles instead of users, user provisioning in Immuta must be done using IAM role principals. 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 access.
Enabling IDC does not impact any existing access controls; it is additive. Immuta will manage the GRANTs using IDC if enabled and configured to Immuta for you.
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 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 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.
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:
Immuta creates a single 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 taggedImmuta Marketplace Data Product
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 remote 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, review the for the specific data platform.
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.
Because this is a grant subscription policy, if this , it will be combined with the existing policy with OR. Should the policy it is being merged with be a , then it will be combined with this policy with AND, 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.
When a user requests access to a data product and is granted it for a set period of time, it works the same as described above; the user will be provisioned access through Immuta policies. However, once the set time duration is up, the user's access with be removed from the data product and its data sources automatically. They can re-request access if they should need it again.