New Connections Reference Guide
Learn how connections work and about feature limitations
New connections
This new connections flow is available and released to select tenants.
This reference page is for Snowflake and Databricks Unity Catalog connections. For any other technologies, see the other connections reference guide.
Connections allow you to register your data objects in a technology through a single connection, making data registration more scalable for your organization. Instead of registering schema and databases individually, you can register them all at once and allow Immuta to monitor your data platform for changes so that data sources are added and removed automatically to reflect the state of data on your data platform.
Once you register your connection, Immuta presents a hierarchical view of your data that reflects the specific hierarchy of objects in your data platform. For example,
Host (e.g., account, metastore, etc.)
Database
Schema
Child data objects such as tables, views, and other supported object types. These objects can have policy sync enabled and be managed as Immuta data sources.
Beyond making the registration of your data more intuitive, connections provides more control. Instead of performing operations on individual schemas or tables, you can perform operations (such as object sync) at the connection level.
Connection settings
The following settings can be configured within your connections:
Connection details: These are the details about the technology that allow Immuta to register and maintain a healthy connection.
Object sync: This setting allows Immuta to monitor the connection for changes. The time and frequency of this setting can be configured.
Policy settings: These settings impact policy on your data objects in the connection.
Impersonation: This setting enables and defines the role for user impersonation for Snowflake connections.
Excluded users and groups: This setting controls the users or groups that will be excluded from data and subscription policies in your connection.
Query audit: When this setting is enabled, your users' queries will be audited in Immuta. Enable the query audit in the connection settings and configure the frequency on the app settings page.
Object settings: These settings impact the child objects within the connection.
Policy sync: Policy sync is the setting that controls if policy will be enacted on a child object. When policy sync is enabled, the child objects (e.g., tables, views, etc.) will have a linked data source and any policy that should be applied will be applied. If policy sync is disabled, then the child objects will not have data sources (or the data source will be disabled) and any policy that would apply to the object will not be applied until policy sync is enabled.
Data owners: This setting controls the data owners that will be added to the data objects within the connection.
Object sync
Immuta will ensure the objects in your database stay synchronous with the registered objects in Immuta. To do this, Immuta uses the account credentials provided during registration to check the remote technology for object changes:
If tables are added, new data objects are created in Immuta.
If remote tables are deleted, the corresponding data sources in Immuta will become disabled; however, the data object representing the table will still appear in the connections view until manually deleted.
If a column changes in a table, those changes will be reflected in the Immuta data source columns tab.
Your connection can be synced in two ways:
Automatic object sync: This happens once every 24 hours (at 12:00 AM UTC). You can update this frequency in the connection settings.
Manual object sync: You can manually run object sync on your whole connection or on any object in your connection.
Object sync excludes Immuta-managed internal objects created for connection operation and policy enforcement. These internal objects are used by Immuta and are not ingested as data objects.
Tracking new data source columns
If you would like to track when new data sources or new columns within a data source are discovered and registered via object sync, enable the New tag behavior option on the app settings page. The new tag behavior setting will ensure that
When new columns are detected and added to Immuta through object sync, they will each be automatically tagged with the Immuta-managed New tag.
When new securables are detected and policy sync is enabled for new objects, a data source will be registered and automatically tagged with the Immuta-managed New tag.
You can opt to have the New tags applied to only columns, only data sources, or both.
When enabling the New tag behavior option, you can also activate the seeded New Column Added global policy to mask columns with the New tag, since they could contain sensitive data. The New Column Added global policy is staged (inactive) by default.
See the Clone, activate, or stage a global policy guide to activate the seeded global policy if you want any columns with the New tag to be automatically masked.
Data source requests
When there is an active policy that targets the New tag, Immuta sends validation requests to data owners for the following changes made in the remote data platform:
Column added: Immuta applies the New tag on the column that has been added and sends a request to the data owner to validate if the new column contains sensitive data. Once the data owner confirms they have validated the content of the column, Immuta removes the New tag from it and as a result any policy that targets the New column tag no longer applies.
Column deleted: Immuta deletes the column from the data source's columns tab in Immuta. Then, Immuta sends a request to the data owner to validate the deleted column.
For instructions on how to view and manage your tasks and requests in the Immuta UI, see the Manage access requests guide. To view and manage your tasks and requests via the Immuta API, see the Manage data source requests section of the API documentation.
Tags
Tags can be applied to objects on any level of the connection and they will be inherited down to the child objects. If the child objects have policy sync enabled, the tags will be propagated on the data sources as well.
See the Manage connection tags guide for details on adding or removing tags within connections.
Automated tags
All data sources within the registered connection and found by object sync after will get an automated tag that represents the connection. These tags can be used like any other in Immuta to build policies, add data sources to domains, generate reports, etc. However, they cannot be edited or deleted.
The tag will be formatted similar to the following example and applied to data sources from child data objects:
Immuta Connections . The Technology . Your Connection Name . Your Database . Your Schema
Policy sync
Policy synchronization controls whether policies are applied to data objects within the connection. The connection must be in a healthy state for policy sync to function.
When policy sync is turned on, data objects will be represented in Immuta as data sources where you can view the active data policies on the columns and the subscribed users of the data. If policy sync is disabled, the object will not have a data source (or the data source will be in a disabled state).
Permissions
Within the connection, the Data Owner permission can be granted on any data object, and will allow that user to manage that object and any within it. For example, granting a user Data Owner on a schema will grant them Data Owner on tables within that schema as well. Data owners can complete the following actions:
View the connections UI
Access any connection where they are granted Data Owner anywhere in the hierarchy
Trigger object sync for their data objects
Delete their data objects
Granting Data Owner to a user on a table with policy sync enabled will also make them a data owner for the data source.
Limitations
When trying to enable a data object, it must have fewer than 100,000 child objects. The only exception is the second-to-lowest object (e.g., a Snowflake schema), which can be enabled with any number of child objects to ensure bulk actions can be completed.
Using periods (
.) in the display name of the connection or data object names should be avoided because periods are used as hierarchy delimiters in Immuta. If you must use periods in names, explicitly escape them to avoid issues.
Additional documentation
For information about each technology's features and a how-to guide, see these additional documentation guides:
Last updated
Was this helpful?