Upgrading to a Connection
Public preview
This feature is public preview and available to select accounts. Reach out to your Immuta support professional to enable it on your tenant.
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.
Native integrations
Native integrations are now connections. Once the upgrade is complete, you will control most integration settings at the connection level via the Infrastructure tab in Immuta.
| Integrations (existing) | Connections (new) |
|---|---|
Integrations are set up from the Immuta app settings page or via the API. These integrations establish a connection between Immuta and the native platform for policy orchestration. Then tables are registered as data sources through an additional step with separate credentials. Schemas and databases are not reflected in the UI. | Integrations and data sources are set up together with a single connection per account between Immuta and the native platform. Based on the privileges granted to the Immuta system user, metadata from databases, schemas, and tables is automatically pulled into Immuta and continuously monitored for any changes. |
Supported technology and authorization methods
Snowflake
Snowflake OAuth
Username and password
Key pair
Databricks
Token
*M2M OAuth is not yet supported.
Unsupported technologies
The following technologies are not yet supported with connections:
Azure Synapse Analytics
Databricks Spark
Google BigQuery
Redshift
S3
Starburst (Trino)
Supported features
The tables below outline Immuta features, their availability with integrations, and their availability with connections.
Snowflake
| Feature | Integrations (existing) | Connections (new) |
|---|---|---|
User impersonation | ||
Project workspaces | ||
Snowflake lineage | Supported | Supported |
Query audit | Supported | Supported |
Tag ingestion | Supported | Supported |
Databricks Unity Catalog
| Feature | Integrations (existing) | Connections (new) |
|---|---|---|
User impersonation | Not supported | Not supported |
Project workspaces | Not supported | Not supported |
Query audit | Supported | Supported |
Tag ingestion | Supported | Supported |
Catalog isolation support | Supported | Not supported |
Data sources
There will be no policy downtime on your data sources while performing the upgrade.
Supported object types
The supported object types are the same for both data sources with integrations and data sources with connections.
Snowflake
Table
View
Materialized view
External table
Event table
Iceberg table
Dynamic table
Databricks Unity Catalog
Table
View
Materialized view
Streaming table
External table
Foreign table
Hierarchy
With connections, your data sources are ingested and presented to reflect the infrastructure hierarchy of your connected data platform. For example, this is what the new hierarchy will look like for a Snowflake host:
| Integrations (existing) | Connections (new) |
|---|---|
Integration | Host |
- | Database |
- | Schema |
Data source | Data source (once activated, becomes available for policy enforcement) |
Tags
Connections will not change any tags currently applied on your data sources.
Consideration
If you previously ingested data sources using the V2 /data endpoint this limitation applies to you.
The V2 /data endpoint allows users to register data sources and attach a tag automatically when the data sources are registered in Immuta.
The V2 /data endpoint is not supported with a connection, and there is no substitution for this behavior at this time. If you require default tags for newly onboarded data sources, please reach out to your Immuta support professional before upgrading.
Data discovery
Connections will not change any of your settings related to sensitive data discovery (SDD).
The data discovery flow for a user who wants sensitive data discovery (SDD) to run on all data sources:
| Data sources with integrations | Data sources with connections |
|---|---|
Create data source (manually or automatically with schema detection) | Register a connection and activate data sources |
SDD automatically runs on data source | SDD automatically runs on data source |
Users and permissions
With integrations
| Permission | Action | Object |
|---|---|---|
APPLICATION_ADMIN | Configure integration | Integration |
CREATE_DATA_SOURCE | Register tables | Data source |
Data owner | Manage data sources | Data source |
With connections
| Permission | Action | Object |
|---|---|---|
CREATE_DATA_SOURCE | Register a connection | Host, database, schema, data source |
GOVERNANCE | Manage all connections | Host, database, schema, data source |
Infrastructure admin | Manage a connection | Host, database, schema, data source |
Data owner | Manage data objects | Host, database, schema, data source |
Schema monitoring
Schema monitoring is renamed to object sync with connections, as it can also monitor for changes at database and connection level.
During object sync, Immuta crawls your connection to ingest metadata for every database, schema, and table that the Snowflake role or Databricks account credentials you provided during the configuration has access to. Upon completion of the upgrade, the tables' states depend on your previous schema monitoring settings:
If you had schema monitoring enabled on a schema: All tables from that schema will be registered in Immuta as active data sources.
If you had schema monitoring disabled on a schema: All tables from that schema (that were not already registered in Immuta) will be registered as inactive data sources. They are visible from the infrastructure view, but are not listed as data sources until they are activated.
After the initial upgrade, your connection is periodically crawled every 24 hours to keep your tables in Immuta in sync. Additionally, users can also manually crawl metadata via the UI or API.
Additional settings
Object sync provides additional controls compared to schema monitoring:
Object status: Hosts, databases, schemas and tables can be marked active, which for tables make them appear as data sources, or inactive. These statuses are inherited to all lower objects by default, but that can be overridden. For example, if you make a database inactive, all schemas and tables within that database will also be inactive. However, if you want one of those tables to be a data source, you can manually activate it.
Activate new data objects: This setting controls what state new objects are registered as in Immuta when found by object sync.
Active: New data objects found by object sync will automatically be activated and tables will be registered as data sources.
Inactive: This is the default. New data objects found by object sync will be inactive.
Comparison
| Integrations (existing) | Connections (new) | |
|---|---|---|
Name | Schema monitoring and column detection | Object sync |
Where to turn on? | Enable (optionally) when configuring a data source | Enabled by default |
Where to update the feature? | Enable or disable from the schema project | Object sync cannot be disabled |
Default schedule | Every 24 hours | Every 24 hours |
Can you adjust the default schedule? | No | No |
Databricks Unity Catalog
Data sources with integrations, required users to manually create the schema monitoring job in Databricks. However, this job has been fully automated on data sources with connections, and this step is no longer necessary.
Immuta APIs
Consolidating integration setup and data source registration into a single connection significantly simplifies programmatic interaction with the Immuta APIs. Actions that used to be managed through multiple different endpoints can now be achieved through one simple and standardized one. As a result, multiple API endpoints are blocked once a user has upgraded their integration to leverage connections.
All blocked APIs will send an error indicating "400 Bad Request - [...]. Use the /data endpoint." This error indicates that you will need to update your processes that are calling the Immuta APIs to leverage the new /data endpoint instead. For details, see the API changes page.
Last updated