# Snowflake The Veza integration connects to Snowflake (on AWS, GCP, or Azure) to gather metadata on identities, roles, and permissions and their relationships to data resources: databases, schema, tables, and views. This information is added to the Access Graph to enable search, intelligence, and access reviews, including support for [Activity Monitoring](/4yItIzMvkpAvMVFAamTf/features/activity-monitoring.md). This document provides steps to configure the Veza integration for Snowflake. For more details see [Notes and Supported Entities](#notes-and-supported-entities). * [Setup](#setup) * [Organization Accounts](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/organization-accounts.md) * [Veza Configuration](#veza-configuration) * [Enable Lifecycle Management](#enable-lifecycle-management) * [Notes and Supported Entities](#notes-and-supported-entities) ## Setup ### Deployment architecture Veza connects to Snowflake using either username/password or key pair authentication. The integration requires a Snowflake user with appropriate role permissions to access system metadata through the Snowflake database. This enables Veza to discover databases, schemas, roles, and effective user permissions and supports optional features such as tag extraction and masking policy evaluation. ![Veza for Snowflake](/files/3zEOTtZXXk51Wzn5wZ81) ### Snowflake configuration You will need to create a local Snowflake user for Veza to use at runtime. This user must: * Have a Snowflake role granting `usage` privilege on a virtual warehouse, enabling Veza to execute queries using the warehouse. The warehouse can be the default `compute_wh` already available in most Snowflake environments, or a dedicated warehouse created for Veza. * Have access to the read-only [`snowflake`](https://docs.snowflake.com/en/sql-reference/snowflake-db.html) system database, for collecting information about users, roles, and resources. You can share only the required views with Veza using an Alternative Snowflake Database Name. You can use the default `COMPUTE_WH`, your primary BI warehouse, or provision a new one specifically for Veza (such as an "X-Small" warehouse with a 60-second suspend time.). You can use a Snowflake [warehouse](https://docs.snowflake.com/en/user-guide/warehouses-overview.html##warehouse-size) other than the default by replacing `COMPUTE_WH` in the example commands with the name of another warehouse. ### Granting read access to the snowflake database To provision the account, connect to Snowflake and execute the following SnowSQL commands (update the bracketed values to use the correct user name, password, and role):
Click to expand: Basic Snowflake setup script ```sql -- create the Veza user create user password = ''; -- create a new role for the user create role ; -- grant read access to the shared system database grant imported privileges on database snowflake to ; -- grant `Usage` privilege on the default warehouse and system DB grant usage on warehouse compute_wh to role ; grant usage on database snowflake to ; -- apply the role to the Veza user grant role to user ; ```
**Optional: Enable Password Policy Extraction** Password Policy extraction requires an additional permission that is broader than other Snowflake integration permissions. To include Password Policies in your Veza discovery, add: ```sql -- Additional permission for Password Policy extraction (optional) grant monitor on account to role ; ``` {% hint style="info" %} The `MONITOR ON ACCOUNT` permission is broader than other Snowflake integration permissions. This permission is **only** required for Password Policy extraction. If you choose not to grant this permission, all other Snowflake integration functionality will work normally, but Password Policies will not be discovered. {% endhint %} ### Using an alternative system database It is not possible to restrict a custom role's access to specific views in the `ACCOUNT_USAGE` schema of the `snowflake` database. However, creating a new database containing copies of only the necessary views will limit Veza's access to the minimum required permissions. > **Important:** The alternative system database option provides enhanced security by limiting Veza's access to only the metadata needed for permissions analysis. It acts as a filtered version of the system database (`snowflake` by default). Using this method does **not** limit the other databases Veza discovers. > > Veza will not connect directly to other databases in the Snowflake account. The integration will query the system database or filtered alternative database to extract the metadata about all the other databases. It will never connect/read from other databases. > > To restrict which databases Veza discovers, use the **Database Allow List** or **Database Deny List** settings in the integration configuration. For large Snowflake environments, you should also consider adjusting the warehouse autosuspend time to reduce costs. Use the following SnowSQL commands to create a local user, create the required views, and grant minimum required permissions. Enter the custom database name when adding the integration to Veza. You will need to drop and recreate views to add additional permissions should the integration support more columns in the future.
Click to expand: Alternative system database setup script ```sql -- create the Veza user create user password = <'PASSWORD'>; -- create a new database and ACCOUNT_USAGE schema create database VEZA_SNOWFLAKE_DB; create schema VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE; -- create views containing system db tables create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.DATABASES as select database_name, created, comment, deleted, last_altered from SNOWFLAKE.ACCOUNT_USAGE.DATABASES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.USERS as select name, login_name, disabled, snowflake_lock, ext_authn_duo, has_mfa, created_on, deleted_on, last_success_login, default_role, has_password, has_rsa_public_key, email, comment, default_secondary_role, owner, type from SNOWFLAKE.ACCOUNT_USAGE.USERS; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.GRANTS_TO_USERS as select grantee_name, deleted_on, granted_to, role from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_USERS; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ROLES as select name, role_type, created_on, deleted_on, comment, role_database_name from SNOWFLAKE.ACCOUNT_USAGE.ROLES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.GRANTS_TO_ROLES as select grantee_name, privilege, granted_on, deleted_on, granted_to, name, grant_option, table_catalog, table_schema from SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.SCHEMATA as select schema_name, catalog_name, created, is_managed_access, comment, deleted, last_altered from SNOWFLAKE.ACCOUNT_USAGE.SCHEMATA; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.TABLES as select table_name, table_schema, table_catalog, table_type, created, comment, deleted, last_altered, last_ddl from SNOWFLAKE.ACCOUNT_USAGE.TABLES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.VIEWS as select table_name, table_schema, table_catalog, created, comment, deleted, last_altered, last_ddl from SNOWFLAKE.ACCOUNT_USAGE.VIEWS; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.QUERY_HISTORY as select query_id, user_name, role_name, database_name, warehouse_name, warehouse_id, query_type, execution_status, end_time, is_client_generated_statement, secondary_role_stats from SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ACCESS_HISTORY as select direct_objects_accessed, base_objects_accessed, objects_modified, objects_modified_by_ddl, query_id from SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.SECRETS as SELECT created_on, database, name, owner, owner_role_type, schema, secret_type, comment FROM SNOWFLAKE.ACCOUNT_USAGE.SECRETS; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.COLUMNS as select column_name, table_name, table_schema, table_catalog, deleted from SNOWFLAKE.ACCOUNT_USAGE.COLUMNS; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.MASKING_POLICIES as select policy_name, policy_signature, policy_body, policy_schema, policy_catalog, deleted from SNOWFLAKE.ACCOUNT_USAGE.MASKING_POLICIES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ROW_ACCESS_POLICIES as select policy_name, policy_signature, policy_body, policy_schema, policy_catalog, deleted from SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_POLICIES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.PROJECTION_POLICIES as select policy_name, policy_signature, policy_body, policy_schema, policy_catalog, deleted from SNOWFLAKE.ACCOUNT_USAGE.PROJECTION_POLICIES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.PASSWORD_POLICIES as select name, schema, database, owner, owner_role_type, comment, created, last_altered, password_min_length, password_max_length, password_min_upper_case_chars, password_min_lower_case_chars, password_min_numeric_chars, password_min_special_chars, password_min_age_days, password_max_age_days, password_max_retries, password_lockout_time_mins, password_history, deleted from SNOWFLAKE.ACCOUNT_USAGE.PASSWORD_POLICIES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.POLICY_REFERENCES as select policy_id, policy_name, policy_kind, ref_database_name, ref_schema_name, ref_entity_domain, ref_entity_name, ref_column_name, policy_db, policy_schema, ref_arg_column_names, policy_status from SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_POLICIES as select name, owner, owner_role_type, comment, created, last_altered, allowed_ip_list, blocked_ip_list, deleted from SNOWFLAKE.ACCOUNT_USAGE.NETWORK_POLICIES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_RULES as select name, schema, database, owner, owner_role_type, comment, created, last_altered, mode, type, value_list, deleted from SNOWFLAKE.ACCOUNT_USAGE.NETWORK_RULES; create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_RULE_REFERENCES as select network_rule_db, network_rule_schema, network_rule_name, network_rule_mode, network_rule_type, container_name, container_type, action_type from SNOWFLAKE.ACCOUNT_USAGE.NETWORK_RULE_REFERENCES; -- add a role for Veza create role ; -- grant warehouse and database usage permissions (execute queries) grant usage on warehouse COMPUTE_WH to role ; grant usage on database VEZA_SNOWFLAKE_DB to role ; grant usage on schema VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE to role ; -- grant read permissions to VEZA_SNOWFLAKE_DB views grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.DATABASES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.USERS to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.GRANTS_TO_USERS to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ROLES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.GRANTS_TO_ROLES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.SCHEMATA to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.TABLES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.VIEWS to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.QUERY_HISTORY to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ACCESS_HISTORY to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.SECRETS to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.POLICY_REFERENCES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.COLUMNS to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.MASKING_POLICIES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.ROW_ACCESS_POLICIES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.PROJECTION_POLICIES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.PASSWORD_POLICIES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_POLICIES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_RULES to role ; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.NETWORK_RULE_REFERENCES to role ; -- assign role to Veza user grant role to user ; -- Optional: Enable Password Policy extraction grant monitor on account to role ; ```
See this [Snowflake KB Topic](https://community.snowflake.com/s/article/Solution-Grant-access-to-specific-views-in-SNOWFLAKE-ACCOUNT-USAGE-to-custom-roles) for more details. ### Enable role type extraction If you were using an alternative database for the integration prior to the `2024.6.17` release, you will to update the views to collect role metadata (`role_type` and `role_database_name`). Update the bracketed values to match the actual database and role name, and run:
Click to expand: Role type extraction update script ```sql -- Delete the original view drop view {VEZA_SNOWFLAKE_DB}.ACCOUNT_USAGE.ROLES; -- Recreate it with role types included create view {VEZA_SNOWFLAKE_DB}.ACCOUNT_USAGE.ROLES as select name, role_type, created_on, deleted_on, comment, role_database_name from SNOWFLAKE.ACCOUNT_USAGE.ROLES; -- Allow the integration role to view grant select on view {VEZA_SNOWFLAKE_DB}.ACCOUNT_USAGE.ROLES to role {VEZA_ROLE}; ```
**Enable tag extraction** To also gather [Snowflake Tags](#snowflake-tags) when using an alternative database name, you will need to run the following script to create a view and a function allowing access to Snowflake's system tagging metadata for ``:
Click to expand: Tag extraction setup script ```sql create view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.TAG_REFERENCES as select tag_database, tag_schema, tag_name, tag_value, object_database, object_schema, object_name, domain, object_deleted from SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES; grant select on view VEZA_SNOWFLAKE_DB.ACCOUNT_USAGE.TAG_REFERENCES to role ; ```
### Create a Network Security Policy to block non Veza-IPs You should define a [Snowflake User Network Policy](https://docs.snowflake.com/en/user-guide/network-policies.html) to prevent connections from non-Veza IP addresses. Your support team can provide the list of IP addresses to allow. You can create a policy using the [CREATE NETWORK POLICY](https://docs.snowflake.com/en/sql-reference/sql/create-network-policy.html) SQL command: ```sql CREATE NETWORK POLICY ALLOWED_IP_LIST=('') ``` Where `ip_range` is the support-provided list of IPs in CIDR notation, for example `192.168.1.0/24` See [Creating Network Policies](https://docs.snowflake.com/en/user-guide/network-policies.html##creating-network-policies) for instructions that use Snowsight or the Snowflake web interface. ### Adjust warehouse autosuspend to reduce uptime after extractions By default, Snowflake warehouses enable [auto-suspend](https://docs.snowflake.com/en/user-guide/warehouses-considerations.html##automating-warehouse-suspension) to save credits when idle, with a 10-minute default wait time. Since Veza connects periodically to refresh entity metadata, reducing the auto-suspend interval can significantly limit unnecessary warehouse uptime. You can change this property (in seconds) using the [ALTER WAREHOUSE](https://docs.snowflake.com/en/sql-reference/sql/alter-warehouse.html) command. **Snowflake sync frequency:** Veza connects to Snowflake every 6 hours to discover changes and synchronize entities in the Access Graph. An administrator can customize the extraction and discovery interval on the **Administration** > **System Settings** page. ### Using key pair authentication As an alternative to user credentials, Veza can authenticate using an [RSA key pair](https://docs.snowflake.com/en/user-guide/key-pair-auth.html). Veza supports both encrypted and unencrypted private keys. Typically, an encrypted key is the safest option. You could also use an existing key pair for the connection. {% tabs %} {% tab title="Generate with Veza" %} 1. In the Veza integration form, optionally enter a password in the **Private Key Password** field to encrypt the private key. 2. Click **Generate & Download Certificate and Private Key**. Veza generates and downloads two files: a `.crt` certificate (public key) and a `.key` private key. 3. Upload the private key to the Veza integration form. 4. Assign the public key to your Snowflake user by using the SnowSQL [ALTER USER](https://docs.snowflake.com/en/sql-reference/sql/alter-user.html) command: ```sql alter user veza_user set rsa_public_key='MIIBIjANBgkqh...'; ``` > Exclude the public key delimiters from the key file. Only include the line containing the key string, without the BEGIN and END KEY statements. 5. Verify the operation was successful with [DESCRIBE USER](https://docs.snowflake.com/en/sql-reference/sql/desc-user.html): ```sql desc user veza_user; ``` The value for `RSA_PUBLIC_KEY` should match the one you created. {% endtab %} {% tab title="OpenSSL (Manual)" %} Generate an encrypted private key with `openssl`: ```shell openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 des3 -inform PEM -out rsa_key.p8 ``` > You'll be prompted to enter and verify a passphrase. Add the '-nocrypt' option to create an unencrypted certificate. The output file `rsa_key.p8` is the PEM-formatted private key file. Save the passphrase, which you will need when configuring Veza. Next, generate a public key for the private key you just created: ```shell openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub ``` Assign the key to your Snowflake user by using the SnowSQL [ALTER USER](https://docs.snowflake.com/en/sql-reference/sql/alter-user.html) command: ```sql alter user veza_user set rsa_public_key='MIIBIjANBgkqh...'; ``` > Exclude the public key delimiters from the key file. Only include the line containing the key string, without the BEGIN and END KEY statements. Verify the operation was successful with [DESCRIBE USER](https://docs.snowflake.com/en/sql-reference/sql/desc-user.html): ```sql desc user veza_user; ``` The value for `RSA_PUBLIC_KEY` should match the one you created. Upload the private key file (and the passphrase, if encrypted) when configuring the Veza integration. {% endtab %} {% endtabs %} ## Organization Accounts [Snowflake Organization Accounts](https://docs.snowflake.com/en/user-guide/organizations) provide centralized visibility and management across multiple Snowflake accounts within the same organization. When enabled, Veza will automatically create separate data sources for each account in the organization, providing comprehensive coverage of your entire Snowflake estate. > **Important:** Organization accounts currently support basic Snowflake metadata extraction (users, roles, databases, permissions) but do not support advanced features like Activity Monitoring (audit log extraction) and Lifecycle Management (user provisioning/deprovisioning). For detailed setup instructions, configuration steps, and limitations, see [Snowflake Organization Accounts](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/organization-accounts.md). ## Veza Configuration From the Veza **Integrations** page, click *Add New* above the list of integrations. Choose *Snowflake* as the integration type. Enter a friendly name to identify the account in Veza, and complete the required fields: **Basic Configuration** * **Insight Point**: Choose a deployed Insight Point or use the internal Veza Insight Point * **Name**: Enter a unique name to identify the integration ### Connection settings * **Connection Type**: specify the Snowflake account to connect to using the account locator or name: * **Account Locator** * Account Locator (e.g., `xy12345`) * Region (e.g., `us-west-2`) * Cloud (`AWS`, `Azure`, or `GCP`) * **Account Name** * Account Name (e.g., `account_name`) * Region (e.g., `us-west-2`) * Cloud (`AWS`, `Azure`, or `GCP`) * **Private Connectivity** (optional) * Connect using AWS PrivateLink or Azure Private Link. If specified, the integration will use the URL `https://{account_locator}.{region}.privatelink.snowflakecomputing.com` to connect to the Snowflake instance. The account region is the AWS, GCP, or Azure region for the Snowflake account, in the provider's standard format (such as `us-west-2`). See the Snowflake documentation on [Regions](https://docs.snowflake.com/en/user-guide/intro-regions.html) for possible valid regions for your cloud provider, and the exact format based on the provider (AWS, Azure, or Google). **Authentication** * **Authentication Method** (choose one): * **Basic Authentication** * User (e.g., `veza_db_user`) * Password * **Key Pair Authentication** * Private Key: Upload the RSA private key file (PEM format) * Private Key Password: Optional password for encrypted certificate **Access Configuration** * **Role** * Name of the role granting privileges (e.g., `veza_db_role`) * **Warehouse** * Default: `compute_wh` * Optionally, enter a warehouse name to use for extraction at runtime **Database Settings** * **Database Access Controls** * **Database Allow List** (optional) * When configured, only databases explicitly listed here will be added to the Access Graph * Use this option to limit discovery to only the specific databases you want to monitor * Format as a comma-separated list of database names (e.g., `DB1,DB2,DB3`) * **Database Deny List** (optional) * When configured, the specified databases will be excluded during extractions * Use this option when you want to discover most databases but exclude specific ones * Format as a comma-separated list of database names (e.g., `TEST_DB,DEV_DB`) * **Alternative Database Name** (optional) * Name of the alternate database to collect metadata from (e.g., `VEZA_SNOWFLAKE_DB`) * This restricts Veza's access to system metadata but does NOT filter which databases are discovered * See [Using an alternative system database](#using-an-alternative-system-database) for more details **Additional Features** * **Check if this is an organization account** * Toggle to enable Organization Account mode for multi-account discovery * When enabled, Veza will create separate data sources for each account in the organization * See [Organization Accounts](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/organization-accounts.md) for detailed setup instructions * **Extract Tags** * Toggle to enable extraction of Snowflake Tags * **Enable Usage for Lifecycle Management** * Toggle to enable [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/provisioning.md) capabilities * **Gather User Login Information** * Toggle to enable extraction of the latest successful login event for each Snowflake user * When enabled, Veza extracts the client IP address, authentication factors, login timestamp, and client type from the most recent successful login * These properties appear as additional attributes on the **Snowflake Local User** node ### Retrieving Snowflake region and account locators To configure the connection to Veza, you will need the region and account locators for the Snowflake account. You can retrieve these with the queries: ```sql select current_region(); ``` ```sql select current_account(); ``` Note that the region format can vary depending on your cloud provider. See [Regions](https://docs.snowflake.com/en/user-guide/intro-regions) in the Snowflake documentation for a list of cloud-specific IDs. ## Enable Lifecycle Management The Snowflake integration supports automated user lifecycle management, including user provisioning, role assignment management, and attribute synchronization. When enabled, Veza can create and manage Snowflake users based on changes in your source identity system. **Additional Permissions Required:** Beyond the basic integration setup, Lifecycle Management requires: * `CREATE USER` privilege on the account for user provisioning * `GRANT ROLE` privilege for role assignments * `OWNERSHIP` privilege on target roles for role management * The Snowflake user should have `USERADMIN` role or equivalent privileges **Supported Capabilities:** The integration supports user creation and updates, role assignment management, and secure deprovisioning. Users can be created with appropriate default settings and assigned roles based on their attributes from the source identity system. To enable Lifecycle Management, check the **Enable Usage for Lifecycle Management** option in your Snowflake integration configuration. For detailed information about supported actions, attributes, and workflow examples, see the [Snowflake Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/provisioning.md) guide. ## Notes and Supported Entities ### Snowflake Tags Snowflake tags are custom metadata labels that can be applied to objects such as databases, schemas, tables, and columns in Snowflake. Discovery of tags is provided as an optional feature. * Enable the **Extract Tags** checkbox when configuring a new Snowflake integration or editing an existing integration to enable tag discovery. This option only applies to non-Standard Edition Snowflake instances. * If implementing an [alternative database name](#using-an-alternative-system-database) for least-privilege connections to Snowflake, you will need to run the additional script included in the documentation. * You can review the Snowflake Tags Veza has found under **Data Catalog** > **Tags** > **Snowflake Tags**. ### Supported Entities The integration discovers the following entity types: * **Snowflake Account** * **Snowflake Application Role** * **Snowflake Database Local Role** * **Snowflake Database** * **Snowflake Local Role** * **Snowflake Local User** * **Snowflake Masking Policy** * **Snowflake Network Policy** * **Snowflake Network Rule** * **Snowflake Network Rule Reference** * **Snowflake Password Policy** * **Snowflake Projection Policy** * **Snowflake Row Access Policy** * **Snowflake Schema** * **Snowflake Secret** * **Snowflake Table Column** * **Snowflake Table** * **Snowflake View Column** * **Snowflake View** ### Entity Properties The metadata that Veza collects enables highly granular queries for search, rules, and workflows. To see any special properties Veza has discovered for an entity, search for the entity in Access Graph, click on it to open the actions sidebar, and click *View Details* on the action sidebar. The available properties depend on the provider: * A. Properties defined by the provider, collected during discovery (such as activity status, MFA status, or creation date). * B. Veza-defined system properties, such as `ID`, `Provider ID`, or `Type`. * C. Properties such as `Full Admin` and `User Type`, which are not necessarily defined by the provider, but derived from the properties Veza has discovered. These are intended to provide a more consistent search experience for providers with different concepts of "Administrators" or "Service Accounts." > You can view all possible entity properties when adding a [Search](/4yItIzMvkpAvMVFAamTf/features/search.md) constraint. Any attributes can be used to filter Access Review queries, or shown for reviewers in optional columns. **Snowflake Local User** | Property | Details | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Snowflake user `NAME` unique ID | | **Email** | Snowflake user `EMAIL` email address | | **Login Name** | Snowflake user `LOGIN_NAME` | | **Is Disabled** | Specifies whether the user is `DISABLED` (true/false) | | **Has Password** | Whether the user has a password (true/false) | | **Has RSA Key** | Whether the user has an RSA public key (true/false) | | **Is Locked** | Whether the user or account is locked by Snowflake (true/false) | | **MFA Enabled** | Whether multi-factor authentication is enabled for the user. Detects any Snowflake-supported MFA provider including Duo Security, Azure, and other methods. For older Snowflake versions without `HAS_MFA` support, this falls back to Duo status. | | **Duo Security Enabled** | Whether Duo Security specifically is enabled for the user, sourced from Snowflake's `EXT_AUTHN_DUO` column. | | **Default Role** | The primary role active by default for the user's session upon login | | **Created At** | Snowflake user creation date | | **Type** | User type as specified in Snowflake (`PERSON`, `SERVICE`, `LEGACY_SERVICE`, or `SNOWFLAKE_SERVICE`) | | **Full Admin** | System field (indicates the ability to assume system admin permissions) | | **User Type** | System field (indicates whether an identity is a `human` or `service_account`) | | **Identity Unique Id** | System field (specifies the property used for cross-service identity mapping) | | **Provider Id** | System field (specifies the Snowflake data provider instance) | | **Datasource Id** | System field (specifies the Snowflake data source instance) | | **Last Used At** | Timestamp of the most recent successful login (requires **Gather User Login Information**) | | **Client IP** | IP address of the client that initiated the most recent successful login | | **Reported Client Type** | Client application type reported at most recent successful login (e.g., `PYTHON_DRIVER`, `JDBC_DRIVER`) | | **First Authentication Factor** | Primary authentication method used at most recent successful login (e.g., `PASSWORD`, `SAML_SSO`) | | **Second Authentication Factor** | Secondary authentication factor if multi-factor authentication was used | * Veza applies the `service account` **User Type** to Snowflake users with no password AND configured to use an RSA public key. * A Snowflake role is marked as *Full Admin* if it's the `ACCOUNTADMIN` system role. Snowflake local users are marked as *Full Admin* when they can assume `ACOUNTADMIN`. ### Cross Service Connections When an Okta Identity Provider integration is configured, Veza discovers relationships between Okta users and groups, the Snowflake roles they can assume, and the effective permissions on each Snowflake resource. * Okta users are mapped to local Snowflake users * Okta groups are mapped to local Snowflake roles ### Masking Policies Veza can evaluate Masking Policies to determine whether a user or role has unmasked access to a Table, View, or Column. See [Snowflake Masking Policies](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/snowflake-masking-policies.md) for details. ### Network Policies Veza discovers Snowflake Network Policies to help visualize network-level access controls and their relationships to users and the Snowflake account. Network Policies control access to Snowflake accounts by specifying which IP addresses are allowed or blocked, and can be applied at the account or user level. See [Snowflake Network Policies](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/snowflake-network-policies.md) for details. ### Password Policies Veza discovers Snowflake Password Policies to help visualize password security controls and their relationships to users and the Snowflake account. Password Policies define rules for user account passwords, including requirements for length, complexity, expiration, and reuse. See [Snowflake Password Policies](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/snowflake-password-policies.md) for details. ### Projection Policies Veza can evaluate Projection Policies to determine whether a user or role has access to specific columns through column-level access controls based on projection policies. See [Snowflake Projection Policies](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/snowflake-projection-policies.md) for details. ### Row Access Policies Veza can evaluate Row Access Policies to determine whether a user or role has access to rows in a Table protected by a Row Access Policy. See [Snowflake Row Access Policies](/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake/snowflake-row-access-policies.md) for details. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/snowflake.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.