Introduction
The Request app is how you manage request / approve workflows in Immuta. It was built from the ground up with security and provisioning of access in mind. Access can refer to either access to a single asset in a catalog (including databases, schemas, tables, etc.), to an entire data product and its objects, or even access to the unmasked data within specific masked columns.
Using the Request app allows for the following actions:
Data consumers can quickly discover and request access to data within the data catalogs they are already working in.
The delegation of data stewards to receive requests for access and make determinations on requests.
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.
The delegation of data product managers to publish and manage data products in Immuta.
Personalization of the Request app with your brand's logo and colors to give it your own look and feel.
Use cases
The Request app is flexible and allows for two different solutions for your request and provisioning workflows.
If you choose to start from your data catalog, you get all the benefits of using Immuta to manage your access requests and provisioning access to data, in addition to allowing your data consumers to request access in the data catalogs they are already using.
See the Walkthrough guide for details on how to set up Immuta with your data catalog.
Choose this use case if
You want data consumers to request access to data, not database roles, which is far more intuitive.
You want requests for data or masking exceptions to be initiated from your catalog but fulfilled and provisioned in an automated manner.
You want data consumers to request masking exceptions on masked columns with requests that capture user details and justifications.
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.
By using Immuta as a marketplace, data product managers can curate data products and data consumers can browse them in the Immuta UI. Then access requests can be made and determined by your data stewards. And finally, Immuta will automatically provision access to the requested data.
See the Use Immuta as a marketplace guide for details on how to set up Immuta as a marketplace.
Choose this use case if
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.
The following are not recommended use cases:
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.
Architecture
The Request app is a separate experience from the existing Governance app, but some actions to set up the Request app must be completed in the Governance app.
Governance app
Application admins register connections
Governance users set up domains and users
Application admins customize the Request app branding
Request app
Governance users configure request forms for assets
Data product managers publish data products
Data consumers fill out request forms to request access to data
Data stewards review access requests
For more details about how to set up the Request app, see the Prerequisites page.
Last updated
Was this helpful?