The connection API is a REST API that allows users to register an AWS Lake Formation to Immuta with a single set of credentials rather than configuring an integration and creating data sources separately. Then Immuta can manage and enforce access controls on your data through that connection. To manage your connection, see the Manage a connection reference guide.
These are permissions that the user registering the connection must have in order to successfully complete setup.
APPLICATION_ADMIN Immuta permission
DESCRIBE AWS permission. You must have the DESCRIBE permission on the required resources in AWS:
All databases that should be registered in the connection
All tables that should be registered in the connection
Any LF-Tags you are using on the resources that should be registered in the connection
The AWS account credentials or you provide for the Immuta service principal must have permissions to perform the following actions to register data and apply policies:
glue:GetDatabase
glue:GetTables
glue:GetDatabases
glue:GetTable
lakeformation:ListPermissions
lakeformation:BatchGrantPermissions
lakeformation:BatchRevokePermissions
lakeformation:CreateLFTag
lakeformation:UpdateLFTag
lakeformation:DeleteLFTag
lakeformation:AddLFTagsToResource
lakeformation:RemoveLFTagsFromResource
lakeformation:GetResourceLFTags
lakeformation:ListLFTags
lakeformation:GetLFTag
lakeformation:SearchTablesByLFTags
lakeformation:SearchDatabasesByLFTags
Data lake is set up in AWS Lake Formation. The account in which this is set up is referred to as the admin account. This is the account that you will use to initially configure IAM and AWS Lake Formation permissions to give the Immuta service principal access to perform operations. The user in this account must be able to manage IAM permissions and Lake Formation permissions for all data in the Glue Data Catalog.
No AWS Lake Formation connections configured in the same Immuta instance for the same Glue Data Catalog.
The databases and tables you want Immuta to govern must be configured in AWS to respect the AWS Lake Formation permissions. Immuta cannot govern resources that use IAM access control or hybrid access mode. To ensure Immuta can govern your resources, verify that the default Data Catalog settings in AWS are unchecked. See the screenshot below and AWS documentation for instructions on changing these settings:
: IDC is the best approach for user provisioning because it treats users as users, not users as roles. Consequently, access controls are enforced for the querying user, nothing more. This approach eliminates over-provisioning and permits granular access control. Furthermore, IDC uses trusted identity propagation, meaning AWS propagates a user's identity wherever that user may operate within the AWS ecosystem. As a result, a user's identity always remains known and consistent as they navigate across AWS services, which is a key requirement for organizations to properly govern that user. Enabling IDC does not impact any existing access controls; it is additive. See the map users section for instructions on mapping users from AWS IDC to user accounts in Immuta.
The Immuta service principal is the to perform operations in your AWS account. This role must have all the necessary permissions in AWS Glue and AWS Lake Formation to allow Immuta to register data sources and apply policies.
Create an IAM policy with the following AWS Lake Formation and AWS Glue permissions. You will attach this to your service principal once created.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:GetTables",
"glue:GetDatabases",
"glue:GetTable",
"lakeformation:ListPermissions",
"lakeformation:BatchGrantPermissions",
"lakeformation:BatchRevokePermissions",
"lakeformation:CreateLFTag",
"lakeformation:UpdateLFTag",
"lakeformation:DeleteLFTag",
"lakeformation:AddLFTagsToResource",
"lakeformation:RemoveLFTagsFromResource",
"lakeformation:GetResourceLFTags",
"lakeformation:ListLFTags",
"lakeformation:GetLFTag",
"lakeformation:SearchTablesByLFTags",
"lakeformation:SearchDatabasesByLFTags"
],
"Resource": "*"
}
]
}Create an IAM role and select AWS Account as the trusted entity type. This role will be used by Immuta to set up the connection and orchestrate AWS Lake Formation policies. Immuta will assume this IAM role from Immuta's AWS account in order to perform any operations in your AWS account.
Add the IAM policy from step 1 to your service principal. These permissions will allow the service principal to register data sources and apply policies on Immuta's behalf.
Add the service principal as an LF-Tag Creator.
In the Lake Formation console, navigate to Permissions.
Select LF-Tags and permissions.
Select LF-Tag creators, and then Add LF-Tag creators.
Enter your service principal, and grant it the Create LF-Tag permission and grantable permission.
Click Add to save your changes.
Grant the service principal permissions on any tables that will be registered in Immuta. There are two ways to give the service principal these permissions: either make a new LF-Tag that gives the appropriate permissions and apply it to , or make the role a superuser in Lake Formation.
This method follows the principle of least privilege and is the most flexible way of granting permissions to the service principal. LF-Tags cascade down from databases to tables, while allowing for exceptions. This means that when you apply this tag to a database, it will automatically apply to all tables within that database and allow you to remove it from any tables if those should be out of the scope of Immuta’s governance.
Create a new LF-Tag, giving yourself permissions to grant that tag to a user, which will ultimately be your service principal.
In the Lake Formation console, navigate to LF-Tags and permissions and click Add LF-Tag. You will need the Create LF-Tag permission to do this.
Create a single tag key with one tag value. For example,
Tag key: immuta_governed
Tag value: true
On the LF-Tag key-value pair, grant the ASSOCIATE LF-Tag permission to your own IAM principal.
Grant this tag to the Immuta service principal.
In the Lake Formation console, navigate to Data permissions and click Grant.
Enter the service principal’s IAM role.
Add the key-value pair of the tag you created in step 1.
Under Table Permissions, select the following grantable permissions: SELECT, DESCRIBE, INSERT, DELETE .
Click Grant.
Apply this tag to the resources you would like Immuta to govern. The Immuta service principal will now have the minimum required permissions on these resources. If new resources are created in AWS, you must repeat this process of applying this tag to those resources if you want Immuta to govern them.
This option enables all Lake Formation operations on all data in the Glue Data Catalog. This is highly privileged and runs the risk of managing permissions on data you did not intend to.
This method will grant all necessary permissions to the service principal, but grants more than the service principal needs without being as flexible, since it does not allow for exceptions like the LF-Tag method. You can make the service principal a superuser on the entire catalog or specify individual resources.
In the Lake Formation console, navigate to Data permissions and click Grant.
Enter your service principal’s IAM role.
Select Named Data Catalog resources, and input the Glue Data Catalog ID and any databases or tables you wish to specify.
Under Grantable permissions, select Super and click Grant.
Follow the AWS documentation to grant ALL permissions to the DataLakePrincipalIdentifier for the Immuta service principal ARN.
POST /data/connection
Copy the request and update the <placeholder_values> with your connection details. Then submit the request.
Find descriptions of the editable attributes in the table below.
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Glue",
"authenticationType": "accessKey",
"region": "us-east-1",
"accountId": "<your-aws-account-id>",
"accessKeyId": "<your-access-key-id>",
"secretAccessKey": "<your-secret-access-key>"
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
}
}'Immuta will assume this IAM role from Immuta's AWS account in order to perform any operations in your AWS account.
Before proceeding,
Contact your Immuta representative, and Immuta will
Provide the AWS account to add to your trust policy.
Update the Immuta AWS configuration to allow Immuta to assume the role of your service principal.
Set the external ID Immuta provides to you in a condition on the trust relationship for the cross-account IAM specified above. See the AWS documentation for guidance.
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Glue",
"authenticationType": "assumedRole",
"region": "us-east-1",
"accountId": "<your-aws-account-id>",
"roleARN": "<your-iam-role-arn>"
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
}
}'connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes of the AWS Lake Formation connection.
Yes
connection.technology string
The technology backing the new connection.
Yes
connection.authenticationType string
The authentication type to register the connection.
Yes
connection.region string
The region of the AWS account associated with the Glue Data Catalog.
Yes
connection.accountId string
The Amazon account ID of the Glue Data Catalog that contains the data you want to register.
Yes
connection.accessKeyId string
The access key ID of an AWS account with the .
Required if authenticationType is accessKey.
connection.secretAccessKey string
The secret access key of an AWS account with the .
Required if authenticationType is accessKey.
connection.roleARN string
The Amazon resource name of the role Immuta will assume from Immuta's AWS account in order to perform any operations in your AWS account.
Required if authenticationType is assumedRole.
settings object
Specifications of the connection's settings, including active status.
No
settings.isActive boolean
When false, data objects will be inactive by default when created in Immuta. Set to false for the recommended configuration.
No
options object
Specification of the connection's default behavior for object crawls.
No
options.forceRecursiveCrawl boolean
If false, only active objects will be crawled. If true, both active and inactive data objects will be crawled; any child objects from inactive objects will be set as inactive. Set to true for the recommended configuration.
No
objectPath string
The list of names that uniquely identify the path to a data object in the remote platform's hierarchy. The first element should be the associated connectionKey.
bulkId string
A bulk ID that can be used to search for the status of background jobs triggered by this request.
{
"objectPath": ['<your-connection-key-name>'],
"bulkId": "a-new-uuid"
}The connection API is a REST API which allows users to register a Databricks Unity Catalog to Immuta with a single set of credentials rather than configuring an integration and creating data sources separately. Then Immuta can manage and enforce access controls on your data through that connection. To manage your connection, see the Manage a connection reference guide.
APPLICATION_ADMIN Immuta permission
The Databricks user registering the connection and running the script must have the following privileges:
CREATE CATALOG privilege on the Unity Catalog metastore to create an Immuta-owned catalog and tables
See the Databricks documentation for more details about Unity Catalog privileges and securable objects.
Unity Catalog metastore created and attached to a Databricks workspace.
Unity Catalog enabled on your Databricks cluster or SQL warehouse. All SQL warehouses have Unity Catalog enabled if your workspace is attached to a Unity Catalog metastore. Immuta recommends linking a SQL warehouse to your Immuta tenant rather than a cluster for both performance and availability reasons.
Complete the following steps to register a Databricks Unity Catalog connection:
Create a service principal in Databricks Unity Catalog with the proper Databricks privileges for Immuta to use to manage policies in Unity Catalog.
Set up Unity Catalog system tables for query audit.
Use the /integrations/scripts/create endpoint to receive a script.
Run the script in Databricks Unity Catalog.
Use the /data/connection endpoint to finish registering your connection in Immuta.
Create a Databricks service principal with the Databricks privileges listed below and set up with personal access token (PAT), which can be an on-behalf token created in Databricks, or OAuth machine-to-machine (M2M) authentication. Immuta uses this service principal continuously to orchestrate Unity Catalog policies and maintain state between Immuta and Databricks.
USE CATALOG and MANAGE on all catalogs containing securables registered as Immuta data sources.
USE SCHEMA on all schemas containing securables registered as Immuta data sources.
MODIFY and SELECT on all securables you want registered as Immuta data sources. The MODIFY privilege is not required for materialized views registered as Immuta data sources, since MODIFY is not a supported privilege on that object type in Databricks.
Grant the service principal from step 1 access to the Databricks Unity Catalog system tables. For Databricks Unity Catalog audit to work, Immuta must have, at minimum, the following access.
USE CATALOG on the system catalog
USE SCHEMA on the system.access and system.query schemas
SELECT on the following system tables:
system.access.table_lineage
system.access.column_lineage
system.access.audit
system.query.history
Access to system tables is governed by Unity Catalog. No user has access to these system schemas by default. To grant access, a user that is both a metastore admin and an account admin must grant USE_SCHEMA and SELECT permissions on the system schemas to the service principal. See Manage privileges in Unity Catalog.
POST /integrations/scripts/create
Using the example request, update the <placeholder_values> with your connection details.
Copy the config object to use later in the setup process.
Run the request.
Copy the returned script and use it in the next step.
Find descriptions of the editable attributes in the table below and of the full payload in the Integration configuration payload reference guide.
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Databricks",
"autoBootstrap": false,
"config": {
"workspaceUrl": "<www.your-workspace.cloud.databricks.com>",
"httpPath": "<sql/protocolv1/o/0/your-path>",
"authenticationType": "token",
"token": "<service-principal-pat>",
"catalog": "<new-catalog>",
"groupPattern": { "deny": "<your-exemption-group>" },
"audit": {"enabled": true}
}
}'Create a separate Immuta catalog for each Immuta tenant
If multiple Immuta tenants are connected to your Databricks environment, create a separate Immuta catalog for each of those tenants. Having multiple Immuta tenants use the same Immuta catalog causes failures in policy enforcement.
Payload parameters
config.workspaceUrl string
Your Databricks workspace URL.
Yes
config.httpPath string
The HTTP path of your Databricks cluster or SQL warehouse.
Yes
config.token string
The Databricks personal access token for the service principal created in step one for Immuta.
Yes
config.catalog string
The name of the Databricks catalog Immuta will create to store internal entitlements and other user data specific to Immuta. This catalog will only be readable for the Immuta service principal and should not be granted to other users. The catalog name may only contain letters, numbers, and underscores and cannot start with a number.
Yes
config.groupPattern object
This object allows you to exclude an account-level group in Databricks from data policies. See the for details.
No
config.audit object
This object enables Databricks Unity Catalog query audit.
No
config.audit.enabled boolean
If true, Databricks Unity Catalog query audit is enabled. Set to true for the recommended configuration.
No
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Databricks",
"autoBootstrap": false,
"config": {
"workspaceUrl": "<www.your-workspace.cloud.databricks.com>",
"httpPath": "<sql/protocolv1/o/0/your-path>",
"authenticationType": "oAuthM2M",
"oAuthClientConfig": {
"useCertificate": ,
"clientId": "<your-client-ID>",
"clientSecret": "<your-client-secret>",
"": "all-apis",
"authorityUrl": "<your.authority.com>"
},
"catalog": "<new-catalog>",
"groupPattern": { "deny": "<your-exemption-group>" },
"audit": {"enabled": true}
}
}'Create a separate Immuta catalog for each Immuta tenant
If multiple Immuta tenants are connected to your Databricks environment, create a separate Immuta catalog for each of those tenants. Having multiple Immuta tenants use the same Immuta catalog causes failures in policy enforcement.
Payload parameters
config.workspaceUrl string
Your Databricks workspace URL.
Yes
config.httpPath string
The HTTP path of your Databricks cluster or SQL warehouse.
Yes
config.oAuthClientConfig object
The oAuthClientConfig object represents your OAuth configuration in Databricks Unity Catalog.
Yes
config.oAuthClientConfig.clientId string
The client identifier of the Immuta service principal you configured. This is the client ID displayed in Databricks when creating the client secret for the service principal.
Yes
config.oAuthClientConfig.clientSecret string
.
Yes
config.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
config.catalog string
The name of the Databricks catalog Immuta will create to store internal entitlements and other user data specific to Immuta. This catalog will only be readable for the Immuta service principal and should not be granted to other users. The catalog name may only contain letters, numbers, and underscores and cannot start with a number.
Yes
config.groupPattern object
This object allows you to exclude an account-level group in Databricks from data policies. See the for details.
No
config.audit object
This object enables Databricks Unity Catalog query audit.
No
config.audit.enabled boolean
If true, Databricks Unity Catalog query audit is enabled. Set to true for the recommended configuration.
No
The previous step will return a script. Copy the script and run it in your Databricks Unity Catalog environment as a user with the privileges listed in the requirements section.
The script will use the service principal that will authenticate using the authentication that you specified. Additionally, the script will create the catalog you specified.
POST /data/connection
Copy the request and update the <placeholder_values> with your connection details. Note that the connection details here should match the ones used when generating the script. Then submit the request.
Find descriptions of the editable attributes in the table below and of the full payload in the Databricks Unity Catalog connection payload table. All values should be included and those you should not edit are noted.
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Databricks",
"hostname": "<www.your-workspace.cloud.databricks.com>",
"port": <your-Databricks-port>,
"httpPath": "<your-Databricks-warehouse-path>",
"authenticationType": "token",
"token": "<your-service-principal-pat>"
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
: {
"type": "Databricks",
: false,
: true,
"config": {
"authenticationType": "token",
"token": "<your-service-principal-pat>",
"host": "<www.your-workspace.cloud.databricks.com>",
"port": <your-Databricks-port>,
"catalog": "<your-immuta-catalog>",
"audit": { "enabled": true },
"workspaceIds": ["<your-workspace>", <"another-workspace">],
: false,
"groupPattern": { "deny": "<your-exemption-group>" },
"jobConfig": {
: "/Workspace/ImmutaArtifacts",
: "undefined"
}
}
}'Create a separate Immuta catalog for each Immuta tenant
If multiple Immuta tenants are connected to your Databricks environment, create a separate Immuta catalog for each of those tenants. Having multiple Immuta tenants use the same Immuta catalog causes failures in policy enforcement.
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.technology string
The technology backing the new connection.
Yes
connection.hostname string
Your Databricks workspace URL. This is the same as host and workspaceURL.
Yes
connection.port integer
The port to use when connecting to your Databricks account.
Yes
connection.httpPath string
The HTTP path of your Databricks cluster or SQL warehouse.
Yes
connection.authenticationType string
The authentication type to register the connection. Make sure this auth type is the same used when requesting the script.
Yes
connection.token string
The Databricks personal access token for the service principal created in step one for Immuta.
Yes
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.
If you set this to true for a data object and it has no subscription policy set on it, Immuta will REVOKE access to the data in Databricks for all Immuta users, even if they had been directly granted access to the table in Unity Catalog.
If a user is not registered in Immuta, Immuta will have no effect on that user's access to data in Unity Catalog. See the for more details.
No
options object
Specification of the connection's default behavior for object crawls.
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.type string
Same as connection.technology
Yes
nativeIntegration.autoBootstrap boolean
Use the same setting as the script generation.
Yes
nativeIntegration.unityCatalog boolean
Use the same setting as the script generation.
Yes
nativeIntegration.config.authenticationType string
Same as connection.authenticationType
Yes
nativeIntegration.config.token string
Same as connection.token
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.catalog string
Use the same setting as the script generation.
Yes
nativeIntegration.config.audit object
Use the same setting as the script generation.
Yes
nativeIntegration.config.workspaceIds array
Use the same setting as the script generation.
No
nativeIntegration.config.enableNativeQueryParsing boolean
Use the same setting as the script generation.
No
nativeIntegration.config.groupPattern object
Use the same setting as the script generation.
No
nativeIntegration.config.jobConfig.workspaceDirectoryPath string
Use the same setting as the script generation.
No
nativeIntegration.config.jobConfig.jobClusterId string
Use the same setting as the script generation.
No
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Databricks",
"hostname": "<www.your-workspace.cloud.databricks.com>",
"port": <your-Databricks-port>,
"httpPath": "<your-Databricks-warehouse-path>",
"authenticationType": "oAuthM2M",
"oAuthClientConfig": {
"useCertificate": ,
"clientId": "<your-client-ID>",
"clientSecret": "<your-client-secret>",
"": "all-apis",
"authorityUrl": "<your.authority.com>"
}
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
: {
"type": "Databricks",
: false,
: true,
"config": {
"host": "<www.your-workspace.cloud.databricks.com>",
"port": <your-Databricks-port>,
"authenticationType": "oAuthM2M",
"oAuthClientConfig": {
"useCertificate": ,
"clientId": "<your-client-ID>",
"clientSecret": "<your-client-secret>",
"": "all-apis",
"authorityUrl": "<your.authority.com>"
},
"catalog": "<your-immuta-catalog>",
"audit": { "enabled": true },
"workspaceIds": ["<your-workspace>", <"another-workspace">],
: false,
"groupPattern": { "deny": "<your-exemption-group>" },
"jobConfig": {
: "/Workspace/ImmutaArtifacts",
: "undefined"
}
}
}'Create a separate Immuta catalog for each Immuta tenant
If multiple Immuta tenants are connected to your Databricks environment, create a separate Immuta catalog for each of those tenants. Having multiple Immuta tenants use the same Immuta catalog causes failures in policy enforcement.
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.technology string
The technology backing the new connection.
Yes
connection.hostname string
Your Databricks workspace URL. This is the same as host and workspaceURL.
Yes
connection.port integer
The port to use when connecting to your Databricks account.
Yes
connection.httpPath string
The HTTP path of your Databricks cluster or SQL warehouse.
Yes
connection.authenticationType string
The authentication type to register the connection. Make sure this auth type is the same used when requesting the script.
Yes
connection.oAuthClientConfig object
The oAuthClientConfig object represents your OAuth configuration in Databricks Unity Catalog.
Yes
connection.oAuthClientConfig.clientId string
The client identifier of the Immuta service principal you configured. This is the client ID displayed in Databricks when creating the client secret for the service principal.
Yes
connection.oAuthClientConfig.clientSecret string
.
Yes
connection.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.
If you set this to true for a data object and it has no subscription policy set on it, Immuta will REVOKE access to the data in Databricks for all Immuta users, even if they had been directly granted access to the table in Unity Catalog.
If a user is not registered in Immuta, Immuta will have no effect on that user's access to data in Unity Catalog. See the for more details.
No
options object
Specification of the connection's default behavior for object crawls.
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.type string
Same as connection.technology
Yes
nativeIntegration.autoBootstrap boolean
Use the same setting as the script generation.
Yes
nativeIntegration.unityCatalog boolean
Use the same setting as the script generation.
Yes
nativeIntegration.config.authenticationType string
Same as connection.authenticationType
Yes
nativeIntegration.config.oAuthClientConfig object
Same as connection.oAuthClientConfig
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.catalog string
Use the same setting as the script generation.
Yes
nativeIntegration.config.audit object
Use the same setting as the script generation.
Yes
nativeIntegration.config.workspaceIds array
Use the same setting as the script generation.
No
nativeIntegration.config.enableNativeQueryParsing boolean
Use the same setting as the script generation.
No
nativeIntegration.config.groupPattern object
Use the same setting as the script generation.
No
nativeIntegration.config.jobConfig.workspaceDirectoryPath string
Use the same setting as the script generation.
No
nativeIntegration.config.jobConfig.jobClusterId string
Use the same setting as the script generation.
No
objectPath string
The list of names that uniquely identify the path to a data object in the remote platform's hierarchy. The first element should be the associated connectionKey.
bulkId string
A bulk ID that can be used to search for the status of background jobs triggered by this request.
{
"objectPath": ['<your-connection-key-name>'],
"bulkId": "a-new-uuid"
}Data API reference guide
This section details the /data v1 API, which allows users to register a to Immuta with a single set of credentials rather than configuring an integration and creating data sources separately.
Required Immuta permission: APPLICATION_ADMIN
You can register a connection from the following technologies to Immuta using supported authentication methods:
AWS access key and secret access key
AWS IAM role
Personal access token (PAT)
OAuth machine-to-machine (M2M)
Username and password
Key pair
Snowflake External OAuth
The connection API is a REST API which allows users to register a Snowflake to Immuta with a single set of credentials rather than configuring an integration and creating data sources separately. Then Immuta can manage and enforce access controls on your data through that connection. To manage your connection, see the Manage a connection reference guide.
The following permissions and personas are used in the registration process:
APPLICATION_ADMIN Immuta permission
The Snowflake user registering the connection and running the script must have the following privileges:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
No Snowflake integration configured in Immuta. If your Snowflake integration is already configured on the app settings page, follow the Use the connection upgrade manager guide.
Complete the following steps to register a Snowflake connection:
Create an Immuta system account with the proper Snowflake privileges for Immuta to use to manage policies in Snowflake.
Use the /integrations/scripts/create endpoint to receive a script.
Run the script in Snowflake.
Use the /data/connection endpoint to finish registering your connection in Immuta.
Complete the following actions in Snowflake:
Create a new user in Snowflake to be the Immuta system account. Immuta will use this system account continuously to orchestrate Snowflake policies and maintain state between Immuta and Snowflake.
Create a Snowflake role with a minimum of the following privileges:
USAGE on all databases and schemas with registered data sources.
REFERENCES on all tables and views registered in Immuta.
.
Grant the new Snowflake role to the system account you just created.
POST /integrations/scripts/create
Using the example request, update the <placeholder_values> with your connection details and the authentication credentials for the system account you just created.
Copy the config object to use later in the setup process.
Run the request.
Copy the returned script and use it in the next step.
Find descriptions of the editable attributes in the table below and of the full payload in the Integration configuration payload reference guide.
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "<your-Snowflake-hostname-url>",
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"authenticationType": "userPassword",
"username": "<new-Snowflake-username>",
"password": "<new-Snowflake-password>",
"audit": {"enabled": true},
"workspaces": {"enabled": false},
"impersonation": {"enabled": false},
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}'Payload parameters
config.host string
The URL of your Snowflake account.
Yes
config.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
config.username string
The new username of the system account that can act on Snowflake objects and register the connection.
Yes
config.password string
The password of the system account that can act on Snowflake objects and register the connection.
Yes
config.audit object
This object enables Snowflake query audit. Omit for the recommended configuration: audit enabled.
No
config.audit.enabled boolean
If true, Snowflake query audit is enabled.
No
config.workspaces object
This object represents Immuta project workspaces configured for Snowflake. Omit for the recommended configuration: workspaces disabled.
No
config.workspaces.enabled boolean
If true, Snowflake project workspaces are enabled. If you use Snowflake table grants, project workspaces cannot be used.
No
config.impersonation object
This object enables user impersonation. Omit for the recommended configuration: impersonation disabled.
No
config.impersonation.enabled boolean
If true, user impersonation is enabled. If you use Snowflake low row access policy mode, impersonation cannot be used.
No
config.lineage object
This object enables Snowflake lineage ingestion. Omit for the recommended configuration: lineage disabled.
No
config.lineage.enabled boolean
If true, Snowflake lineage is enabled.
No
config.userRolePattern object
This object excludes roles and users from authorization checks. Omit for the recommended configuration: no users or roles excluded.
No
config.userRolePattern.exclude array
This array is a list of roles and users (both case-sensitive) to exclude from authorization checks. Wildcards are unsupported. The roles and users will not have policies applied to them when querying Immuta protected Snowflake tables.
No
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "<your-Snowflake-hostname-url>",
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"authenticationType": "keyPair",
"username": "<the-Snowflake-username>",
"privateKey": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->",
"audit": {"enabled": true},
"workspaces": {"enabled": false},
"impersonation": {"enabled": false},
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}'Payload parameters
config.host string
The URL of your Snowflake account.
Yes
config.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
config.username string
The username of the system account that can act on Snowflake objects and register the connection.
Yes
config.privateKey string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
Yes
config.audit object
This object enables Snowflake query audit. Omit for the recommended configuration: audit enabled.
No
config.audit.enabled boolean
If true, Snowflake query audit is enabled.
No
config.workspaces object
This object represents Immuta project workspaces configured for Snowflake. Omit for the recommended configuration: workspaces disabled.
No
config.workspaces.enabled boolean
If true, Snowflake project workspaces are enabled. If you use Snowflake table grants, project workspaces cannot be used.
No
config.impersonation object
This object enables user impersonation. Omit for the recommended configuration: impersonation disabled.
No
config.impersonation.enabled boolean
If true, user impersonation is enabled. If you use Snowflake low row access policy mode, impersonation cannot be used.
No
config.lineage object
This object enables Snowflake lineage ingestion. Omit for the recommended configuration: lineage disabled.
No
config.lineage.enabled boolean
If true, Snowflake lineage is enabled.
No
config.userRolePattern object
This object excludes roles and users from authorization checks. Omit for the recommended configuration: no users or roles excluded.
No
config.userRolePattern.exclude array
This array is a list of roles and users (both case-sensitive) to exclude from authorization checks. Wildcards are unsupported. The roles and users will not have policies applied to them when querying Immuta protected Snowflake tables.
No
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "<your-Snowflake-hostname-url>",
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"provider": "<your-provider>",
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"": true,
"publicCertificateThumbprint": "<your-certificate-thumbprint>",
"oauthPrivateKey": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->",
"": "session:role-any",
"audit": {"enabled": true},
"workspaces": {"enabled": false},
"impersonation": {"enabled": false},
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'Payload parameters
config.host string
The URL of your Snowflake account.
Yes
config.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
config.oAuthClientConfig.provider string
The identity provider for OAuth, such as Okta.
Yes
config.oAuthClientConfig.clientId string
The client identifier of your registered application.
Yes
config.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
config.oAuthClientConfig.publicCertificateThumbprint string
Your certificate thumbprint.
Yes
config.oAuthClientConfig.oauthPrivateKey string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added.
Yes
config.audit object
This object enables Snowflake query audit. Omit for the recommended configuration: audit enabled.
No
config.audit.enabled boolean
If true, Snowflake query audit is enabled.
No
config.workspaces object
This object represents Immuta project workspaces configured for Snowflake. Omit for the recommended configuration: workspaces disabled.
No
config.workspaces.enabled boolean
If true, Snowflake project workspaces are enabled. If you use Snowflake table grants, project workspaces cannot be used.
No
config.impersonation object
This object enables user impersonation. Omit for the recommended configuration: impersonation disabled.
No
config.impersonation.enabled boolean
If true, user impersonation is enabled. If you use Snowflake low row access policy mode, impersonation cannot be used.
No
config.lineage object
This object enables Snowflake lineage ingestion. Omit for the recommended configuration: lineage disabled.
No
config.lineage.enabled boolean
If true, Snowflake lineage is enabled.
No
config.userRolePattern object
This object excludes roles and users from authorization checks. Omit for the recommended configuration: no users or roles excluded.
No
config.userRolePattern.exclude array
This array is a list of roles and users (both case-sensitive) to exclude from authorization checks. Wildcards are unsupported. The roles and users will not have policies applied to them when querying Immuta protected Snowflake tables.
No
curl -X 'POST' \
'https://<your-immuta-url>/integrations/scripts/create' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"host": "<your-Snowflake-hostname-url>",
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"provider": "<your-provider>",
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"clientSecret": "<your-client-secret>",
"": false,
"": "session:role-any",
"audit": {"enabled": true},
"workspaces": {"enabled": false},
"impersonation": {"enabled": false},
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'Payload parameters
config.host string
The URL of your Snowflake account.
Yes
config.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
config.database string
Name of a new empty database that the Immuta system user will manage and store metadata in.
Yes
config.oAuthClientConfig.provider string
The identity provider for OAuth, such as Okta.
Yes
config.oAuthClientConfig.clientId string
The client identifier of your registered application.
Yes
config.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
config.oAuthClientConfig.clientSecret string
Client secret of the application.
Yes
config.audit object
This object enables Snowflake query audit. Omit for the recommended configuration: audit enabled.
No
config.audit.enabled boolean
If true, Snowflake query audit is enabled.
No
config.workspaces object
This object represents Immuta project workspaces configured for Snowflake. Omit for the recommended configuration: workspaces disabled.
No
config.workspaces.enabled boolean
If true, Snowflake project workspaces are enabled. If you use Snowflake table grants, project workspaces cannot be used.
No
config.impersonation object
This object enables user impersonation. Omit for the recommended configuration: impersonation disabled.
No
config.impersonation.enabled boolean
If true, user impersonation is enabled. If you use Snowflake low row access policy mode, impersonation cannot be used.
No
config.lineage object
This object enables Snowflake lineage ingestion. Omit for the recommended configuration: lineage disabled.
No
config.lineage.enabled boolean
If true, Snowflake lineage is enabled.
No
config.userRolePattern object
This object excludes roles and users from authorization checks. Omit for the recommended configuration: no users or roles excluded.
No
config.userRolePattern.exclude array
This array is a list of roles and users (both case-sensitive) to exclude from authorization checks. Wildcards are unsupported. The roles and users will not have policies applied to them when querying Immuta protected Snowflake tables.
No
Using your generated script, run it in your Snowflake environment as a user with the permissions listed in the requirements section.
The script will use the provided Immuta system user credentials to create the database you specified in the earlier step and set up Immuta-managed resources in Snowflake.
POST /data/connection
Using the tabs below, copy the request and update the <placeholder_values> with your connection details. The connection details here should match the ones used when generating the script, and the payload from the script generation should be pasted exactly into nativeIntegration. Then submit the request.
Find descriptions of the editable attributes in the table below and of the full payload in the Connection registration payloads reference guide. The recommended setting values are included in the example.
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Snowflake",
"hostname": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"role": "<your-Snowflake-role>",
"authenticationType": "userPassword",
"username": "<your-Snowflake-username>",
"password": "<your-Snowflake-password>",
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
"nativeIntegration": {
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"authenticationType": "userPassword",
"username": "<your-Snowflake-username>",
"password": "<your-Snowflake-password>",
"host": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"impersonation": { "enabled": false },
"audit": { "enabled": true },
"workspaces": { "enabled": false },
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.hostname string
The URL of your Snowflake account. This should be the same as nativeIntegration.config.host.
Yes
connection.port integer
The port to use when registering your Snowflake connection.
Yes
connection.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
connection.role string
The privileged Snowflake role used by the Immuta system account when registering the Snowflake connection. At minimum, it must be able to see the data that Immuta will govern.
Yes
connection.username string
The username of the system account that can act on Snowflake objects and register the connection.
Yes
connection.password string
The password of the system account that can act on Snowflake objects and register the connection.
Yes
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint. See the for descriptions.
Yes
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Snowflake",
"hostname": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"role": "<your-Snowflake-role>",
"authenticationType": "keyPair",
"username": "<the-Snowflake-username>",
"privateKeyPassword": "<your-Snowflake-key-password>",
"privateKey": {
"": "PRIV_KEY_FILE",
"userFilename": "<your-private-key-file-name>",
"content": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->"
}
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
"": {
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"authenticationType": "keyPair",
"username": "<the-Snowflake-username>",
"privateKeyPassword": "<your-Snowflake-key-password>",
"privateKey": {
"": "PRIV_KEY_FILE",
"": "<your-private-key-file-name>",
"": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->"
}
"host": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"impersonation": { "enabled": false },
"audit": { "enabled": true },
"workspaces": { "enabled": false },
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.hostname string
The URL of your Snowflake account. This is the same as host.
Yes
connection.port integer
The port to use when registering your Snowflake connection.
Yes
connection.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
connection.role string
The privileged Snowflake role used by the Immuta system account when registering the Snowflake connection. At minimum, it must be able to see the data that Immuta will govern.
Yes
connection.username string
The username of the system account that can act on Snowflake objects and register the connection.
Yes
connection.privateKeyPassword string
The Snowflake private key password. Required if the private key is encrypted.
No
connection.privateKey.userFilename string
The name of your private key file on your machine.
Yes
connection.privateKey.content string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added. This is the same as config.privateKey.
Yes
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
If false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.config.username string
Same as connection.username
Yes
nativeIntegration.config.privateKeyPassword string
Same as connection.privateKeyPassword
No
nativeIntegration.config.privateKey.keyName string
Same as connection.keyName
Yes
nativeIntegration.config.privateKey.userFilename string
Same as connection.userFilename
Yes
nativeIntegration.config.privateKey.content string
Same as connection.content
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.warehouse string
Same as connection.warehouse
Yes
nativeIntegration.config.database string
Use the same setting as the script generation.
Yes
nativeIntegration.config.impersonation object
Use the same setting as the script generation.
Yes
nativeIntegration.config.audit object
Use the same setting as the script generation.
Yes
nativeIntegration.config.workspaces object
Use the same setting as the script generation.
Yes
nativeIntegration.config.lineage object
Use the same setting as the script generation.
Yes
nativeIntegration.userRolePattern object
Use the same setting as the script generation.
Yes
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Snowflake",
"hostname": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"role": "<your-Snowflake-role>",
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"useCertificate": true,
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"": "session:role-any",
"publicCertificateThumbprint": "<your-certificate-thumbprint>",
"resource": "<your-optional-resource>",
"oauthPrivateKey": {
"": "oauth client certificate",
"userFilename": "<your-user-file.pem>",
"content": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->"
}
}
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
"": {
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"useCertificate": true,
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"": "session:role-any",
"publicCertificateThumbprint": "<your-certificate-thumbprint>",
"resource": "<your-optional-resource>",
"oauthPrivateKey": {
"": "oauth client certificate",
"": "<your-user-file.pem>",
"": "<-----BEGIN PRIVATE KEY-----your-private-key-----END PRIVATE KEY----->"
}
}
"host": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"impersonation": { "enabled": false },
"audit": { "enabled": true },
"workspaces": { enabled": false },
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.hostname string
The URL of your Snowflake account. This is the same as host.
Yes
connection.port integer
The port to use when registering your Snowflake connection.
Yes
connection.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
connection.role string
The privileged Snowflake role used by the Immuta system account when registering the Snowflake connection. At minimum, it must be able to see the data that Immuta will govern.
Yes
connection.oAuthClientConfig.clientId string
The client identifier of your registered application.
Yes
connection.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
connection.oAuthClientConfig.publicCertificateThumbprint string
Your certificate thumbprint.
Yes
connection.oAuthClientConfig.resource string
An optional resource to pass to the token provider.
No
connection.oAuthClientConfig.oauthPrivateKey.userFilename string
The name of your private key file on your machine.
Yes
connection.oAuthClientConfig.oauthPrivateKey.content string
The private key. Replace new lines in the private key with a backslash before the new line character: "\n". If you are using another means of configuration, such as a Python script, the "\n" should not be added. This is the same as config.oauthPrivateKey in the script request.
Yes
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration.
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.config.oAuthClientConfig.clientId string
Same as connection.oAuthClientConfig.clientId
Yes
nativeIntegration.config.oAuthClientConfig.authorityUrl string
Same as connection.oAuthClientConfig.authorityUrl
Yes
nativeIntegration.config.oAuthClientConfig.publicCertificateThumbprint string
Same as connection.oAuthClientConfig.publicCertificateThumbprint
Yes
nativeIntegration.config.oAuthClientConfig.resource string
Same as connection.oAuthClientConfig.resource
No
nativeIntegration.config.oAuthClientConfig.oauthPrivateKey.userFilename string
Same as connection.oAuthClientConfig.oauthPrivateKey.userFilename
Yes
nativeIntegration.config.oAuthClientConfig.oauthPrivateKey.content string
Same as connection.oAuthClientConfig.oauthPrivateKey.content
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.warehouse string
Same as connection.warehouse
Yes
nativeIntegration.config.database string
Use the same setting as the script generation.
Yes
nativeIntegration.config.impersonation object
Use the same setting as the script generation.
Yes
nativeIntegration.config.audit object
Use the same setting as the script generation.
Yes
nativeIntegration.config.workspaces object
Use the same setting as the script generation.
Yes
nativeIntegration.config.lineage object
Use the same setting as the script generation.
Yes
nativeIntegration.userRolePattern object
Use the same setting as the script generation.
Yes
curl -X 'POST' \
'https://<your-immuta-url>/data/connection' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-H 'Authorization: <your-bearer-token>' \
-d '{
"connectionKey": "<your-connection-key-name>",
"connection": {
"technology": "Snowflake",
"hostname": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"role": "<your-Snowflake-role>",
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"useCertificate": false,
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"": "session:role-any",
"resource": "<your-optional-resource>",
"clientSecret": "<your-client-secret>"
}
},
"settings": {
"isActive": false
},
"options": {
"forceRecursiveCrawl": true
},
"nativeIntegration": {
"type": "Snowflake",
"autoBootstrap": false,
"config": {
"authenticationType": "oAuthClientCredentials",
"oAuthClientConfig": {
"useCertificate": false,
"clientId": "<your-client-ID>",
"authorityUrl": "<your-example.authority.com>",
"": "session:role-any",
"resource": "<your-optional-resource>",
"clientSecret": "<your-client-secret>"
}
"host": "<your-Snowflake-hostname-url>",
"port": <your-Snowflake-port>,
"warehouse": "<your-Snowflake-warehouse>",
"database": "<your-Snowflake-database>",
"impersonation": { "enabled": false },
"audit": { "enabled": true },
"workspaces": { "enabled": false },
"lineage": { "enabled": false },
"userRolePattern": { "exclude": [] }
}
}
}'
Payload parameters
connectionKey string
A unique name for the connection.
Yes
connection object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
connection.hostname string
The URL of your Snowflake account. This is the same as host.
Yes
connection.port integer
The port to use when registering your Snowflake connection.
Yes
connection.warehouse string
The default pool of compute resources the Immuta system user will use to run queries and perform other Snowflake operations.
Yes
connection.role string
The privileged Snowflake role used by the Immuta system account when registering the Snowflake connection. At minimum, it must be able to see the data that Immuta will govern.
Yes
connection.oAuthClientConfig.clientId string
The client identifier of your registered application.
Yes
connection.oAuthClientConfig.authorityUrl string
Authority URL of your identity provider.
Yes
connection.oAuthClientConfig.clientSecret string
Client secret of the application.
Yes
connection.oAuthClientConfig.resource string
An optional resource to pass to the token provider.
No
settings object
Specifications of the connection's settings, including status.
No
settings.isActive boolean
When false, data objects will be inactive (disabled) by default when created in Immuta. Set to false for the recommended configuration
No
options.forceRecursiveCrawl boolean
If false, only active (enabled) objects will be crawled. If true, both active (enabled) and inactive (disabled) data objects will be crawled; any child objects from inactive (disabled) objects will be set as inactive (disabled). Set to true for the recommended configuration.
No
nativeIntegration object
Configuration attributes that should match the values used when getting the script from the integration endpoint.
Yes
nativeIntegration.config.oAuthClientConfig.clientId string
Same as connection.oAuthClientConfig.clientId
Yes
nativeIntegration.config.oAuthClientConfig.authorityUrl string
Same as connection.oAuthClientConfig.authorityUrl
Yes
nativeIntegration.config.oAuthClientConfig.resource string
Same as connection.oAuthClientConfig.resource
No
nativeIntegration.config.oAuthClientConfig.clientSecret string
Same as connection.oAuthClientConfig.clientSecret
Yes
nativeIntegration.config.host string
Same as connection.hostname
Yes
nativeIntegration.config.port integer
Same as connection.port
Yes
nativeIntegration.config.warehouse string
Same as connection.warehouse
Yes
nativeIntegration.config.database string
Use the same setting as the script generation.
Yes
nativeIntegration.config.impersonation object
Use the same setting as the script generation.
Yes
nativeIntegration.config.audit object
Use the same setting as the script generation.
Yes
nativeIntegration.config.workspaces object
Use the same setting as the script generation.
Yes
nativeIntegration.config.lineage object
Use the same setting as the script generation.
Yes
nativeIntegration.userRolePattern object
Use the same setting as the script generation.
Yes
objectPath string
The list of names that uniquely identify the path to a data object in the remote platform's hierarchy. The first element will be the associated connectionKey.
bulkId string
A bulk ID that can be used to search for the status of background jobs triggered by this request.
Example response
{
"objectPath": ['<your-connection-key-name>'],
"bulkId": "a-new-uuid"
}