Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Connect an external catalog to use tagging capabilities outside of Immuta and pull tags from external table schemas. Once the catalog has been connected, Immuta ingests a data dictionary from the catalog and applies data source and column tags directly to the data source. These tags can then be used to create policies.
This getting started guide outlines how to use external catalogs in Immuta to gain value from all three Immuta modules: Discover and Secure.
Configure an external catalog: Configure Alation, Collibra, or a custom REST catalog to ingest tags into Immuta.
External catalog integrations: This reference guide describes the requirements of the external catalogs Immuta supports.
Custom REST catalog introduction: This reference guide describes the custom catalog option for users to make API calls to retrieve metadata on their data.
Custom REST catalog interface endpoints: This reference guide describes the endpoints for configuring a custom REST catalog.
This page outlines how to connect an external catalog on the Immuta app settings page. For details on external catalogs in Immuta, see the External catalog reference guide.
Requirements:
APPLICATION_ADMIN Immuta permission
An Alation API access token connected to a user with the Server Admin permission
To change the default expiration period for your Alation catalog's API tokens, see configure the expiration period for Alation API tokens.
Navigate to the App Settings page.
Scroll to 2 External Catalogs, and click Add Catalog.
Enter a Display Name and select Alation from the dropdown menu.
Complete the URL and API key fields. The API key must be an API access token for your Alation instance connected to a user with the Server Admin permission.
Configure whether or not Alation tags and custom fields are imported as Immuta tags:
Link Alation tags: When selected, Immuta imports Alation tags as Immuta tags.
Link Alation Custom Fields: When selected, Immuta imports Alation custom fields as Immuta tags. Follow the Alation documentation to create an Alation custom field, add permissions to your custom field, and apply custom fields to tables and columns.
Opt to select Upload Certificates.
Upload the Certificate Authority, Certificate File, and Key File.
Opt to enable Strict SSL by selecting the checkbox.
Click the Test Connection button.
Once the connection is successful, click Save.
Requirement: APPLICATION_ADMIN Immuta permission
Navigate to the App Settings page.
Scroll to 2 External Catalogs, and click Add Catalog.
Enter the Display Name and select Collibra from the dropdown menu.
Enter the HTTP endpoint of the catalog in the URL field.
Complete the Username and Password fields. Note: This is the username and the password that Immuta can use to connect to the external catalog.
Complete the Asset Mappings modal to set which Collibra asset types align to the Immuta data source and column. Immuta will only link data sources from the asset types you specify.
Complete the Attributes as Tags modal to specify which Collibra attributes you want in Immuta. These attributes will come in as parent tags with their values as children tags.
Opt to select Upload Certificates.
Upload the Certificate Authority, Certificate File, and Key File.
Opt to enable Strict SSL by selecting the checkbox.
Click the Test Connection button.
Once the connection is successful, click Save.
Private preview
The Microsoft Purview catalog integration is only available to select accounts. Contact your Immuta representative to enable this feature.
Requirement: APPLICATION_ADMIN Immuta permission
Register an app in the Azure portal with the with the following settings:
Supported account type: "Accounts in this organizational directory only"
Microsoft-Graph: User.Read API permission
A client secret
Using that registered app, navigate to Immuta and complete the following:
Navigate to the App Settings page.
Scroll to 2 External Catalogs, and click Add Catalog.
Enter the Display Name and select Microsoft Purview from the dropdown menu.
Complete the following fields:
Enter the Microsoft Purview endpoint URL including the Azure Account Name, like https://<ACCOUNTNAME>.purview.azure.com, in the Purview Endpoint URL field.
Complete the Microsoft Entra Directory (tenant) ID and Microsoft Entra (client) ID fields.
Enter the Microsoft Entra Application Client Secret ID for Immuta to authenticate and connect to the Purview API. The secret cannot be expired.
Click the Test Connection button.
Once the test is successful, click Save.
Requirement: APPLICATION_ADMIN Immuta permission
Integrating a custom REST catalog service with Immuta requires implementing a REST interface. For details about the necessary endpoints that must be serviced, see the Custom REST catalog interface endpoints page.
Navigate to the App Settings page.
Scroll to 2 External Catalogs, and click Add Catalog.
Enter the Display Name and select Rest from the dropdown menu.
Select the Internal Plugin checkbox if the catalog has been uploaded to Immuta as a custom server plugin.
Complete the following fields:
Enter the HTTP endpoint of the catalog in the URL field.
Complete the Username and Password fields.
Enter the path of the Tags Endpoint.
Enter the path of the Data Source Endpoint.
Enter the path to the information page for a data source in the Data Source Link Template field.
Opt to enter the path to the information page for a column in the Column Link Template field.
Opt to upload a Catalog Image.
Opt to select Upload Certificates.
Upload the Certificate Authority, Certificate File, and Key File.
Opt to enable Strict SSL by selecting the checkbox.
Click the Test Connection button.
Click the Test Data Source Link.
Once both tests are successful, click Save.
See the Configure a Snowflake integration page for guidance on configuring tag ingestion.
If Snowflake data sources existed before configuring tag ingestion, Immuta will automatically sync those data sources to the catalog and apply tags to them. Immuta will automatically check the external catalog for changes and sync data sources to the catalog every 24 hours.
See the Configure a Databricks Unity Catalog integration page for guidance on configuring tag ingestion.
If Databricks Unity Catalog data sources existed before configuring tag ingestion, Immuta will automatically sync those data sources to the catalog and apply tags to them. Immuta will automatically check the external catalog for changes and sync data sources to the catalog every 24 hours.
You can manually link and remove external catalogs from data sources on the data source overview tab.
Navigate to your data source.
In the connection information section, click the Link Catalog icon (or Unlink Catalog to remove an external catalog from a data source).
Select your external catalog from the dropdown menu.
Click Link to confirm.
Navigate to your data source and click the data source Health dropdown menu.
Click Re-run in the External Catalog section.
Users who want to use tags from outside of Immuta can connect an external catalog to automatically pull and apply them to Immuta data sources. These tags can then be used to drive or .
Immuta supports the following external catalogs:
To configure an external catalog, see the .
Once an external catalog has been configured on the Immuta app settings page, there are two recurring process steps:
Linking to data sources and columns: Whenever a new data source is created or an external catalog is set up, Immuta will attempt to automatically link data sources to their corresponding assets in the external catalog. This is done by comparing the fully qualified name of a data source in Immuta with its corresponding asset name in the external catalog, so data sources must have the same name in Immuta and the external catalog. Alternatively, a user can also a data source to an asset in an external catalog. Once a data source has been linked to an external catalog, it can be seen on the data source's detail page.
Pull and apply tags in Immuta: Using the link established in the first step, Immuta polls the external catalog to ingest and apply tags to each data source and its columns. Immuta checks every 24 hours for any relevant metadata changes in the connected external catalog. Tags originating from an external catalog can be found on the tags list page and on the data dictionary page for each data source.
See below for more information about the way Immuta integrates with each supported external catalog provider.
Immuta's Alation integration supports importing both tags and custom fields, Alation's two primary ways of allowing data stewards to apply metadata to data assets.
Tags: Tags are a single word or phrase that can be attached to most Alation objects by nearly anyone. For instance, users can add a PCI tag for financial data.
Custom fields: Custom fields are key-value pairs that can only be attached and removed by authorized users. Unlike tags, custom fields can have multiple values associated with a single key. For example, the custom field DK_STEWARD could have MARKETING, FINANCE, and CUSTOMER values associated with it. Using Alation custom fields allows you to explicitly control who can modify information associated with that field inside of Alation, whereas Alation standard tags are modifiable by any user inside of Alation.
When pulled into Immuta, Alation tags and custom fields will be applied to data sources as either column or data source tags in Immuta. Importing both Alation tags and custom fields into Immuta provides full flexibility for customers leveraging the Alation enterprise data catalog, no matter what operating model they choose to document their metadata in Alation.
Immuta's Collibra integration supports importing both tags and attributes. Additionally, data source and column descriptions from the connected Collibra catalog will be pulled into Immuta.
Tags: Tags are a single word or phrase that can be attached to objects in Collibra. For instance, users can add a PHI tag on health-related data assets.
Attributes: Attributes in Collibra are a characteristic that describes an asset with an individual field. Unlike tags, attributes can have multiple values associated with a single key. For example, the attribute classification could have non sensitive, sensitive, and highly sensitive values associated with it. Using Collibra attributes allows you to explicitly control who can modify information associated with that field inside of Collibra, whereas Collibra standard tags are modifiable by any user inside of Collibra.
When pulled into Immuta, Collibra tags and attributes will be applied to data sources as either column or data source tags in Immuta. Importing both Collibra tags and attributes into Immuta provides full flexibility for customers leveraging the Collibra data catalog, no matter what operating model they choose to document their metadata in Collibra.
Collibra assets must have unique full names in order for Immuta to guarantee exact matching. If there are multiple Collibra assets with the same name, Immuta will link to the first asset it matches to.
Columns must have a direct relation to their parent asset in Collibra. Indirect/inherited relations are not supported and will result in column tags and attributes not being ingested into Immuta.
Private preview
The Microsoft Purview catalog integration is only available to select accounts. Contact your Immuta representative to enable this feature.
Linking to data sources and columns in Microsoft Purview: Immuta links data sources to assets in Microsoft Purview by looking up the fully qualified name of an entity. The composition of the fully qualified name in Microsoft Purview differs depending on the technology type backing the data source.
Pull and apply tags in Immuta from Microsoft Purview: Immuta polls Microsoft Purview every 24 hours for all tags.
Standard tags from Purview do not get ingested into Immuta
The current implementation only supports Databricks Unity Catalog, Snowflake and Azure Synapse Analytics data sources and their associated columns
Managed attributes are supported, but have the following limitations:
If a managed attribute is applied to an Immuta data source but later expires, it will still appear as a tag on the data source. Expired attributes must be removed from the object in Purview for the tag to be removed from the Immuta data source.
The following managed attribute data types are not supported and will not be applied to Immuta data sources as tags:
Dates
Number types
Rich text
If users have an unsupported catalog, or have customized their catalog integration, they can connect through the REST Catalog using the Immuta API.
Design partner preview: This feature is only available to select accounts. Reach out to your Immuta representative to enable this feature.
Tags ingested from external catalogs cannot be edited within Immuta. To edit, delete, or add a tag from an external catalog to a data source or column, make the change in the external catalog.
S3 data sources cannot currently be linked to external catalogs.
The custom REST catalog integration allows Immuta to make a to a Custom REST service you develop to retrieve metadata. The Custom REST service receives Immuta's calls, and then collects the relevant information and delivers it back to Immuta.
The diagram below highlights the main feature of Immuta's Custom REST Catalog integration.
Through a Custom REST Catalog, you can build and maintain your own solutions that provide metadata required to effectively use Immuta within your organization.
The how-to guides linked on this page illustrate how to link to ingest tags and add value to the Immuta modules: and .
Best practice: Use a single catalog; having more than one can lead to multiple truths and data leaks.
Requirement: A catalog with tags that correspond to your Immuta data sources
.
When changes are made to the external catalog, .
Requirements:
A physical data dictionary with assets that correspond to your Immuta data sources
The Collibra global role Catalog or Catalog Author
.
When changes are made to the external catalog, .
Requirements:
A catalog with assets that correspond to your Immuta data sources
The ability to create a registered app in the Azure portal
Requirements:
A catalog with tags that correspond to your Immuta data sources
Requirements:
Fewer than 2,500 Databricks Unity Catalog data sources registered in Immuta
Once you register data sources, table and column tags from Databricks Unity Catalog will be ingested and applied to the corresponding data sources in Immuta.
Requirements:
A Snowflake user who can set the following permissions:
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake
GRANT APPLY TAG ON ACCOUNT
Snowflake Enterprise Edition or higher
The diagram below contrasts Immuta's provided catalog integration architecture with this Customer REST Catalog interface - which gives the customer tremendous control over the metadata being provided to Immuta.
The custom-developed service must be built to receive and handle calls to the REST endpoints specified below. Immuta will call these endpoints as detailed below when certain events occur and at various intervals. The required responses to complete the connection are also detailed.
Tags are attributes applied to data - either at the top, data source, level or at the individual column level.
Tags in Immuta take the form of a nested tree structure. There are "parents", "children", "grand-children", etc.:
The REST Catalog interface interprets a tag's relationship mapping from a string based on a standard "dot" (.) notation, like:
Tags returned must meet the following constraints:
They must be no longer than 500 characters. Longer tags will not throw an error but will be truncated silently at 500 characters.
They must be composed of letters, digits, underscores, dashes, and whitespace characters. A period (.) is used as a separator as described above. Other special characters are not supported.
A tag object has a single id property, which is used to uniquely identify the tag within the catalog. This id may be of either a string or integer type, and its value is completely up to the designer of the REST Catalog service. Common examples include: a standard integer value, a UUID, or perhaps a hash of the tag's string value (if it is unique within the system).
For this Customer REST Catalog interface, tags are represented in JSON like:
For example, the object below specifies 3 different tags:
Descriptions are strings that, like tags, can be applied to either a data source or an individual column. These strings support UTF-8, including special and various language characters.
Immuta can make requests to your REST Catalog service using any of the following authentication methods:
Username and password: Immuta can send requests with a username and a password in the Authorization HTTP header. In this case, the custom REST service will need to be able to parse a Basic Authorization Header and validate the credentials sent with it.
PKI Certificate: Immuta can also send requests using a CA certificate, a certificate, and a key.
NO Authentication: Immuta can make unauthenticated requests to your REST Catalog service. However, this should only be used if you have other security measures in place (e.g., if the service is in an isolated network that's reachable only by your Immuta environment).
Authentication and specific endpoints
When accessing the /dataSource and /tags endpoints, Immuta will use the configured username and password. If you choose to also protect the human-readable pages with authentication, users will be prompted to authenticate when they first visit those pages.
/tagsThe /tags endpoint is used to collect ALL the tags the catalog can provide. It is used by Immuta to populate Immuta's tags list in the Governance section. These tags can then be used for policy creation ahead of actual data sources being created that make use of them. This enables policies to immediately apply when data sources are registered with Immuta.
As with all external catalogs, tags ingested by Immuta from the REST catalog interface are not able to be modified locally within Immuta as this catalog becomes the "source of truth" for them. This results in the tags showing in Immuta with either a lock icon next to them, or without the delete button that would allow a user to manually remove them from an assigned data source or column.
The /tags endpoint receives a simple GET request from Immuta. No payload nor query parameters are required.
Example request:
Example response:
/dataSourceThe /dataSource endpoint does the vast majority of the work. It receives a POST request from Immuta, and returns the mapping of a data source and its columns to the applied tags and descriptions.
Immuta will try to fetch metadata for a data source in the system at various times:
During data source creation. During data source creation, Immuta will send metadata to the REST Catalog service, most notably the connection details of the data source, which includes the schema and table name. It is important that the Custom REST service implemented can parse this information and search its records for an appropriate record to return with an ID unique to this data source in its catalogMetadata object.
When a user manually links the data source. Data sources that either fail to auto-link, or that were created prior to the Custom REST catalog being configured, can still be manually linked. To do so, a data source owner can provide the ID of the asset as defined by the Custom REST Catalog via the Immuta UI. In order for this to work, the Custom REST Catalog service must support matching data source assets by unique ID.
During various refreshes. Once linked, Immuta will periodically call the /dataSource endpoint to ensure information is up to date.
Immuta's POST requests to the /dataSource endpoint will consist of a payload containing many of the elements outlined below:
This object must be parsed by the in Custom REST Catalog order to determine the specific data source metadata being requested.
For the most part, Immuta will provide the id of the data source as part of the catalogMetadata. This should be used as the primary metadata lookup value.
When a data source is being created, such an id will not yet be known to Immuta. Immuta will instead send handlerInfo information as part of the request.
When an id is not specified, the schema and table name elements should be parsed in an attempt to identify the desired catalog entry and provide an appropriate id. If such a lookup is successful and an id is returned to Immuta in the catalogMetadata section, Immuta will establish an automatic link between the the new data source and the catalog entry, and future references will use that id.
Example response:
/dataSource/page/{id}This endpoint returns a human-readable information page from the REST catalog for the data source associated with {id}. Immuta provides this as a mechanism for allowing the REST catalog to provide additional information about the data source that may not be directly ingested by or visible within Immuta. This link is accessed in the Immuta UI when a user clicks the catalog logo associated with the data source.
Immuta will send a GET request to the /dataSource/page/{id} endpoint, where {id} will be:
Example request:
The Custom REST Catalog can either provide such a page directly, or can redirect the user to any resource where the appropriate page would be provided - for example a backing full service catalog such as Collibra, if this Custom REST catalog is simply being used to support a custom data model.
Example response:
/column/{id}This endpoint returns the catalog's human-readable information page for the column associated with {id}. Immuta provides this as a mechanism for allowing the REST catalog to provide additional information about the specific column that may not be directly ingested by or visible within Immuta.
Immuta will send a GET request to the /column/{id} endpoint, where {id} will be:
Example request:
The Custom REST Catalog can either provide such a page directly, or can redirect the user to any resource where the appropriate page would be provided - for example a backing full service catalog such as Collibra, if this Custom REST catalog is simply being used to support a custom data model.
Example response:
Collibra tags using the dot "." delimiter will be transformed into hierarchical tags in Immuta. To learn more about the benefits of hierarchical tags for policy authoring, see .
Linking to data sources and columns in Collibra: Immuta links data sources to assets in Collibra by looking up the full name. To ensure unique names that Immuta can easily link to, it is recommended that customers use to onboard their data sources into Collibra.
Pull and apply tags in Immuta from Collibra: Immuta checks Collibra every 24 hours by observing the linked for any relevant metadata changes. Based on these changes, Immuta then only polls and ingests tags from Collibra for the relevant data sources. However, if Immuta observes more than 25,000 metadata changes in Collibra within 24 hours, it will poll all data sources for tags during that run of external catalog tag synchronization.
The Microsoft Purview catalog integration with Immuta currently supports ingestion of and as tags. Additionally, data source and column descriptions from the connected Microsoft Purview catalog will be pulled into Immuta.
For more details about using a custom REST catalog with Immuta, see the .
Users can connect their Databricks Unity Catalog account to allow Immuta to ingest Databricks tags and apply them to Databricks data sources. To learn more about Databricks Unity Catalog tag ingestion, see the .
Users can connect a Snowflake account to allow Immuta to ingest Snowflake tags onto Snowflake data sources. To learn more about Snowflake tag ingestion, see the .
You can configure multiple external catalogs within a single tenant of Immuta, but only one external catalog can be .
To configure an external catalog, see the .
To learn more about how Immuta can automatically tag your data with Discover, see the .
: This page details the endpoints and data schemas of the API and contains example requests and responses.
.
When changes are made to the external catalog, .
.
When changes are made to the external catalog, .
Databricks privileges listed on the page
.
.
.
in Immuta.
When changes are made to the tags in Snowflake,
For more information on tags and how they are created, managed, and displayed within Immuta, see our .
The Custom REST service must respond with an object that maps all tag name strings to associated ids. The fully-qualifies the location of the tag in the tree structure as detailed previously, and the id is a globally unique identifier assigned by the REST catalog to that tag.
| Attribute | Data Type | Description |
|---|
The schema for the /dataSource response uses the same tag object structure from the , along with the following set of metadata keys for both data sources and columns.
| Attribute | Data Type | Description |
|---|
| Attribute | Data Type | Description |
|---|
| Attribute | Data Type | Description |
|---|
| dictionary | Object holding the data source's catalog metadata. |
| string or integer | The unique identifier of the data source in the catalog. |
| string | The name of the data source in the catalog. |
| dictionary | Object holding the data source's connection details. |
| string | The data source’s schema name in the source system. |
| string | The data source’s table name in the source system. |
| string | The data source’s connection schema in the source storage system. |
| integer | The data source’s connection port in the source storage system. |
| string | The data source’s connection schema in the source storage system, if applicable. |
| dictionary | Object holding general data source information from Immuta. This can be viewed with debugging, but is not usually required for catalog purposes. |
| dictionary | Object holding the data source's catalog metadata. |
| string or integer | The unique identifier of the data source in the catalog. |
| string | The name of the data source in the catalog. |
| string | A description of the data source. |
|
| Object containing the data source-level tags. |
| dictionary | Object containing the column names of the data source as its keys. |
| dictionary | Object containing a single column's metadata. |
| string or integer | The unique identifier of the column in the catalog. |
| string | A description of the column. |
|
| Object containing the column-level tags as keys. |
| URL Parameter, integer or string | The unique identifier of the data source in the remote catalog system. |
| URL Parameter, integer or string | The unique identifier of the column in the remote catalog system. |
