Snowflake Exfiltration Controls, Service Users, Key-Pair Auth and AI Access

1.Closing data-exfiltration paths with account parameters

Data usually leaves an account by being unloaded to cloud storage that someone controls. The most dangerous case is when that storage is reached with credentials typed straight into SQL. Snowflake provides a set of account parameters that restrict data unloading. The exam guide names two of them: PREVENT_UNLOAD_TO_INLINE_URL and REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION. Both are set with ALTER ACCOUNT.

When REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION is TRUE, any new external stage for a private cloud storage location must use a storage integration object as its credentials. When it is FALSE (the default), a stage can instead hold explicit cloud credentials such as secret keys or access tokens. Those are exactly the credentials that can point data at an outside bucket. The parameter can be set only at the account level. A related parameter, REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_OPERATION, covers loads and unloads rather than stage creation: when it is TRUE, those operations must use a named external stage that references a storage integration.

Sources123

2.Service users and key-pair authentication

A user object's TYPE property says what kind of identity it is. PERSON is a human; NULL behaves the same as PERSON; SERVICE is an application that connects without a person. SERVICE users cannot log in with a password or with SAML SSO, cannot enroll in MFA, and cannot have properties such as PASSWORD or FIRST_NAME. That leaves programmatic methods, and key-pair authentication is the main one. It needs at least a 2048-bit RSA key pair. You generate the key pair yourself, and Snowflake stores only the public key.

openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.p8

The passphrase only protects the private key file and is never sent to Snowflake. Assigning a public key requires OWNERSHIP of the user, or the narrower MODIFY PROGRAMMATIC AUTHENTICATION METHODS privilege. Granting that privilege lets a team look after its own service user's credentials without owning the user:

GRANT MODIFY PROGRAMMATIC AUTHENTICATION METHODS ON USER my_service_user
  TO ROLE my_service_owner_role;

ALTER USER example_user ADD KEY PAIR my_key
  PUBLIC_KEY = 'MIIBIjANBgkqh...';

With named key pairs, ROTATE KEY PAIR keeps the old key valid for 24 hours by default so running clients can switch over without downtime. EXPIRE_ROTATED_KEY_PAIR_AFTER_HOURS changes that window; 0 expires the old key immediately. The older property approach lets a user hold up to two public keys and rotates by swapping between them. To confirm a key was registered correctly, compare the RSA_PUBLIC_KEY_FP value from DESC USER with a SHA-256 fingerprint of your local public key.

Sources45

3.Controlling access to Cortex AI functions

Cortex AI functions are controlled through roles like everything else. A role is given the SNOWFLAKE.CORTEX_USER database role, and you can add per-function account privileges of the form USE AI FUNCTION <function_name>. Granting several of these to one role builds a custom set of allowed functions, such as AI_COMPLETE and AI_EXTRACT but not other AI functions:

USE ROLE ACCOUNTADMIN;

CREATE ROLE ai_analyst_role;

GRANT USE AI FUNCTION AI_COMPLETE ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_CLASSIFY ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_EXTRACT ON ACCOUNT TO ROLE ai_analyst_role;
GRANT USE AI FUNCTION AI_TRANSLATE ON ACCOUNT TO ROLE ai_analyst_role;

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE ai_analyst_role;
GRANT ROLE ai_analyst_role TO USER analyst_user;

Revoking access works the same way, for example REVOKE USE AI FUNCTION AI_COMPLETE ON ACCOUNT FROM ROLE ai_analyst_role;. There is a catch: a per-function revoke does not block a role that still holds the blanket USE AI FUNCTIONS privilege. SHOW GRANTS TO ROLE or SHOW GRANTS ON ACCOUNT lists per-function grants as USE AI FUNCTION <function_name>. With restricted caller's rights, both the session role and the service or application owner role need the privilege.

Where inference runs is set with an account parameter: CORTEX_ENABLED_CROSS_REGION = { 'DISABLED' | 'ANY_REGION' | '<list_of_regions>' }. If governance forbids processing outside the account's region, this is the setting to use. Gap in the sources: the material available here does not document a model allowlist parameter or the default grant of CORTEX_USER to PUBLIC. Check the Cortex privileges and model access page for those.

Sources62

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Setting RSA_PUBLIC_KEY with ALTER USER gives the same controls as ADD KEY PAIR, including key expiration.Why is that wrong?

   Only named key pairs (ADD KEY PAIR) support role restriction, named key management and expiration. The RSA_PUBLIC_KEY property does not.

   Covered in Service users and key-pair authentication

2. 2.A service user can keep a password as a fallback in case its key is lost.Why is that wrong?

   SERVICE users cannot log in with a password or SAML SSO and cannot enroll in MFA, so key-based programmatic authentication is the only route.

   Covered in Service users and key-pair authentication

3. 3.Revoking USE AI FUNCTION AI_COMPLETE always stops a role from calling AI_COMPLETE.Why is that wrong?

   If the role still holds the blanket USE AI FUNCTIONS privilege, it can still call AI_COMPLETE after the per-function revoke.

   Covered in Controlling access to Cortex AI functions

Practise it for real

Set up key-pair authentication for a user and confirm that the registered key matches your local key.

1. 1.Run: openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.p8

   Why: This creates an encrypted 2048-bit PKCS#8 private key, the minimum size Snowflake accepts.

   You should see: A passphrase prompt, then a file rsa_key.p8 that begins with -----BEGIN ENCRYPTED PRIVATE KEY-----

2. 2.Run: openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

   Why: The public key is the only part Snowflake stores.

   You should see: A file rsa_key.pub that begins with -----BEGIN PUBLIC KEY-----

3. 3.As a role with OWNERSHIP or MODIFY PROGRAMMATIC AUTHENTICATION METHODS on the user, run ALTER USER example_user ADD KEY PAIR my_key PUBLIC_KEY = '<key body without delimiters>';

   Why: A named key pair supports role restriction, expiration and rotation with a grace period.

   You should see: SHOW USER KEY PAIRS lists my_key for example_user

4. 4.Compare RSA_PUBLIC_KEY_FP from DESC USER with the output of: openssl rsa -pubin -in rsa_key.pub -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

   Why: Matching fingerprints prove the key in Snowflake matches your private key.

   You should see: The same base64 string from both sides