Snowflake (Native API) | Anjana Data Documentación

This page documents the integration of Anjana Data Platform with Snowflake through the tot-plugin-snowflake plugin, based on the Snowflake SQL API (REST access) and External OAuth authentication with Microsoft Entra ID. Unlike the integration via the JDBC connector (documented on the Snowflake page), this plugin operates on Snowflake's native APIs and extends the scope with access permission management. It covers three functional blocks: metadata extraction, data sampling and permission management.

Integration model

The tot-plugin-snowflake plugin integrates with Snowflake through the Snowflake SQL API, an access mechanism based on REST services that allows SQL statements to be executed via HTTP requests, without the need for a persistent JDBC connection. The user starts an operation from Anjana Data, which is sent to the plugin; the plugin first requests an access token from the identity provider (Entra ID) via OAuth2, includes it in the Authorization header and invokes the Snowflake SQL API, which executes the query and returns the result for processing in Anjana.

Metadata extraction

The plugin is able to extract metadata from Snowflake tables, views and materialized views, as well as from the databases and schemas they belong to. The plugin discovers the objects available in Snowflake, extracts the technical information of the selected assets and imports them into entities of subtype DATASET and DATASET_FIELD. This block includes:

Discovery of databases and schemas.
Listing of available tabular objects.
Metadata extraction of the object and its columns.
Contextual metadata of database and schema.
Native tags from Snowflake, including those inherited from ancestor assets.

To consult the list of metadata that Anjana Data discovers for the different types of Snowflake assets and how it is mapped to the attributes of the DATASET and DATASET_FIELD templates, see the documentation in Snowflake (Native API) - Anjana Configuration

Data sampling

The plugin allows a limited sample of records to be obtained from a Snowflake object (tables, views and materialized views) in order to preview and validate the content of the assets governed from Anjana. Sampling is performed through SELECT queries on the object, applying a row limit that is configurable via the sampleRows parameter. The values of sensitive fields (pi = true) are replaced by the string defined in obfuscation-string.

For the obfuscation of the data sample to take effect, the pi attribute must be included in the DATASET_FIELD template and declared explicitly.

Permission management

The plugin manages read permissions on Snowflake objects through a role-based model: permissions are assigned to Snowflake roles (which represent the DSA groups), not directly to users. Management is carried out by means of Data Sharing Agreements (DSA) and requires:

Having the Entra ID plugin deployed (which controls groups and users) or using the DSA physicalName functionality to reuse existing groups
Having user synchronization enabled in order to manage adherences properly.

This block includes:

Creation or reuse of roles associated with DSAs.
Granting of USAGE permissions on database and schema, and SELECT on tables, views or tabular objects contained in an approved DSA.
Revocation of SELECT permissions on specific objects (when objects contained in a DSA are deleted or expire).
Reassignment of SELECT permissions on an object that becomes active again in the DSA.
Deletion of roles where applicable (when a DSA is deleted or expires).
Idempotent handling of repeated operations.

When an object included in a DSA becomes active again (it changes from DISABLED to APPROVED), the plugin reassigns to the affected roles the privileges that correspond to them on that object, through the editObject operation. The plugin identifies the DSAs in which the object is included, deduces the roles that must regain access and grants them SELECT on the object again, adding USAGE on the database and the schema if the role did not already have it. The operation is idempotent: if the privilege is already granted, it completes successfully without duplicating the grant.

Deletion of reused roles. When a DSA has been configured with physicalName to reuse an existing group, the deleteGroup operation still executes DROP ROLE on that role when the DSA expires or is deleted, without distinguishing whether the role was created by the plugin or already existed. If the plugin's technical identity has OWNERSHIP on the role, it will be deleted. This should be taken into account when reusing roles managed outside the platform

Snowflake SQL API

API request

The Snowflake SQL API allows SQL statements to be executed via HTTP requests: the client sends the statement in the request body and Snowflake processes the operation and returns the response. Access is performed via OAuth: the application first obtains an access token and includes it in the Authorization header of each request, avoiding the need to send user credentials. External OAuth is used, so the token is not issued by Snowflake but by the external identity provider (Entra ID), and Snowflake validates it through the configured security integration.

Role-based permission model

Snowflake's access control is based on a model oriented to roles. Roles are created associated with a set of privileges on objects (databases, schemas, tables) and are subsequently assigned to users, who automatically inherit those permissions. Any change to the privileges of a role affects all of its users, which facilitates consistent, scalable and traceable management. For this reason, the groups of the system are modelled as Snowflake roles.

Consumption permissions on assets

Consumption permissions are the minimum privileges required to access and query an asset without administration capabilities. To access an object, the permission on the object itself is not enough: access is also required on the database and the schema that contain it. The scope of the plugin covers:

Level	Privilege
Database	USAGE
Schema	USAGE
Table	SELECT
View	SELECT
Materialized view	SELECT
External table*	SELECT
Dynamic table*	SELECT
Iceberg table*	SELECT
Event table*	SELECT

In this way, for a tabular asset the minimum granting pattern is: USAGE on the database, USAGE on the schema and SELECT on the table or view, granting read access without modification or administration permissions.

Note (*)

The scope of permission management covers any tabular object on which Snowflake supports a SELECT grant. Metadata extraction and data sampling, by contrast, are limited to tables, views and materialized views. An object of another type can be governed in a DSA and receive permissions, but its technical metadata is not imported and its content is not sampled from Anjana.

Lifecycle of USAGE permissions

Permission revocation is not symmetrical with respect to granting. The removeObject operation revokes only the direct grant on the object, that is, the SELECT privilege. The USAGE privileges on the database and the schema are not revoked during the lifetime of the role, not even when the last asset of a schema is removed from the DSA.

These privileges only disappear when the role is deleted with DROP ROLE, which happens when the DSA of the role of the current version expires or is deleted (deleteGroup). In practice, this means that a role that no longer has SELECT on any object retains the USAGE on the databases and schemas it accessed at some point. USAGE on a schema does not by itself allow data to be read: without SELECT on an object, the role can only see the metadata of the object.

Roles of previous versions. When the content of an already approved DSA is modified, Anjana generates a new version of the agreement and the plugin creates a new role associated with it, instead of modifying the existing one. The role of the previous version is neither revoked nor deleted, and retains the USAGE and SELECT privileges it had. These roles are not deleted when the DSA is deleted either, so they remain indefinitely in Snowflake. They do not represent improper access, since they retain no assigned users, but they do imply an accumulation of residual roles that should be taken into account in permission audits.

Required credentials

Metadata extraction and sampling

The technical identity of the plugin must have sufficient privileges to list the objects and extract the metadata. For more information see Snowflake (Native API) - Infra Configuration.

Permission management

The technical identity of the plugin must have sufficient privileges to execute the following statements on Snowflake:

SHOW ROLES, SHOW USERS, SHOW GRANTS TO ROLE, SHOW GRANTS TO USER and SHOW GRANTS OF ROLE, in order to check the current state before acting (idempotency).
CREATE ROLE and DROP ROLE.
GRANT / REVOKE USAGE on database and schema.
GRANT / REVOKE SELECT on the object.
GRANT / REVOKE ROLE TO / FROM USER.

For more information see Snowflake (Native API) - Infra Configuration.

End-user warehouse access

The plugin does not grant USAGE on any warehouse to the consumption roles it creates. The role receives USAGE on the database and the schema and SELECT on the objects of the DSA, but not the compute resource required to execute the queries.

Therefore, the end user must have access to a warehouse by another route, outside the scope of the plugin: through their default role, through PUBLIC or through another role already granted to them in Snowflake. This is a prerequisite of the integration: without warehouse access, a user with an approved DSA still cannot query the asset.

If a single warehouse is to be used for governed consumption, the usual approach is to grant USAGE on that warehouse to a role that all consumers already have, for example PUBLIC or a role granted to all the users of the organization.

Plugin operations

The plugin implements the following operations:

Operation	Description
`metadataList`	Discovers and lists the available databases, schemas and tabular objects.
`metadataExtract`	Extracts the detailed technical metadata of an object and its columns.
`sample`	Returns a sample of records of the object (`sampleRows` limit, with obfuscation of sensitive fields).
`createGroup`	Creates or reuses the Snowflake role associated with the DSA (via SCIM when it is enabled) and grants it the consumption permissions on the assets of the DSA.
`editObject`	Grants the role again the privileges that correspond to it on an object, when the object becomes active again in the DSA. Inverse operation of `removeObject`.
`removeObject`	Revokes the `SELECT` privilege of the role on a specific asset of the DSA.
`deleteGroup`	Deletes the role by means of `DROP ROLE` when the DSA expires or is deleted, including roles reused through `physicalName`.
`addUser`	Grants the role to the user (SCIM synchronization or direct `GRANT ROLE`).
`removeUser`	Revokes the role from the user by means of `REVOKE ROLE`.

Configuration

Connectivity

Connectivity is established against the Snowflake SQL API on the Snowflake account, authenticated by means of the OAuth2 token obtained from Entra ID. The connection, OAuth and SCIM parameters are defined in the application.yaml file of the plugin (oauth and scim blocks). For more information see Snowflake (Native API) - Infra Configuration and Example YAML

The infrastructure/technology /zone triplet selected when importing objects into Anjana must match the one configured in the application.yaml of the plugin for the connection to be resolved correctly.

For all plugins there are common guidelines in the Technical configuration and Tot plugin deployment sections. In addition, for each plugin there is a sample YAML that facilitates its setup, with the description of each property and its default values.