In certain cases you are able to use your own Snowflake account to host the data from Keboola Connection. Currently, we only support this for the Snowflake backend.
For the integration to work, your Snowflake account needs to be accessible from a subset of our IP addresses.
We don’t support SCIM authentication (AAD, Okta).
Because Keboola Connection manages access to the data, you need to only use the provided roles and not grant any grants on Keboola-managed resources.
If the project has the read-only input mapping feature enabled, then you have a role KEBOOLA_$PROJECTID_RO
for each project. This role has read-only access to all the schemas and tables in the project. You can grant this role to any of your own roles or users to give them access to the project’s storage.
You can use the in-built functionality of transformation workspaces. The user created for the workspace has the abovementioned role granted automatically. This workflow works even if you don’t use your own Snowflake account.
The dynamic backends feature requires you to have one Snowflake warehouse for each backend size. The actual sizes of warehouses are independent of the representation in Keboola (small, medium, and large). You can have XSmall, Small and XLarge. We recommend that the warehouses are set up with an aggressive AUTO_SUSPEND value, even as low as 1 second.
KEBOOLA_
prefix (SAPI_
for https://connection.keboola.com
stack) unless explicitly approved on case-by-case basis by KeboolaKEBOOLA_$PROJECTID
)
KEBOOLA_$PROJECTID_RO