Snowflake#

Cartography inventories a single Snowflake account: its identities and RBAC model, its data hierarchy, its network access controls, and the integrations that connect it to object storage and cloud IAM.

Two Data Sources#

The Snowflake REST API v2 covers most of the object inventory, but several security-relevant surfaces exist only as SQL. Cartography reads both through the same credential:

  • The object API (/api/v2/...) provides accounts, users, roles, grants, warehouses, databases, schemas, tables, stages, external volumes, network policies, secrets, tasks, pipes, and the Snowpark Container Services objects.

  • The SQL API (POST /api/v2/statements) provides what the object API omits: security and storage integrations, programmatic access tokens, MFA enrollment, account-level grants, shares and listings, replication and failover groups, resource monitors, and policy attachments.

No Snowflake driver is installed. Both surfaces are plain authenticated HTTP.

Surfaces that a given account cannot answer are skipped rather than failing the sync, and a skipped surface also skips its own cleanup, so a missing privilege or an edition limitation never deletes data Cartography previously collected. Standard-edition accounts have no masking or row-access policies and no failover groups; accounts without ORGADMIN cannot list sibling accounts in the organization; ACCOUNT_USAGE views require IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE and lag real time by up to two hours.

Shared Object Labels#

Objects that can receive privileges through GRANT carry the shared SnowflakeSecurable label. Grantees that can hold privileges carry the shared SnowflakePrincipal label. Together they let a single HAS_PRIVILEGE relationship connect any grantee to any grantable object, rather than needing one relationship per label pair. Neither is a standalone node type.

Identifiers#

Snowflake object names are unique only within their own namespace and their own object type: a stage, a pipe, a stream and a task can all be named FOO in one schema, and a role and a warehouse can share a name at the account level. Node ids are therefore account-scoped and type-tagged, of the form <ORG>.<ACCOUNT>/<object type>/<qualified name>, for example MYORG.MYACCT/table/PROD.SALES.ORDERS.

Because Snowflake folds unquoted identifiers to uppercase while preserving the case of quoted ones, a name that is not a plain uppercase identifier stays quoted inside the qualified name, as in MYORG.MYACCT/schema/PROD."my schema".

Cross-Provider Connections#

Cartography links Snowflake to cloud resources that other modules already ingested:

  • External volume storage locations and external stages connect to AWSS3Bucket, GCPBucket and AzureStorageAccount nodes, and to the AWSKMSKey that encrypts them.

  • Storage, API, catalog and notification integrations connect to the AWSRole they assume, and notification integrations and auto-ingest pipes connect to their AWSSNSTopic.

Ontology Integration#

Snowflake accounts are Tenants, human users are UserAccounts and service users are ServiceAccounts, roles of every kind are PermissionRoles, databases are Databases, network policies and rules are NetworkAccessControls, external stages and external volume storage locations are ObjectStorage, secrets are Secrets, programmatic access tokens are APIKeys, and SAML / OAuth / SCIM security integrations are IdentityProviders. This makes Snowflake identities and grants comparable with the equivalent AWS, Azure, GCP and Databricks structures.