Snowflake Key Pairs, PATs, Secrets, Session Policies and Threat Protection

1.Key-pair authentication for programmatic clients

Programmatic clients and service users authenticate without a human typing a password. Key-pair authentication is the established option. Snowflake's security overview calls workload identity federation the preferred method for service-to-service workloads. A user configured for it shows HAS_WORKLOAD_IDENTITY = TRUE in DESC USER. A related capability lets Snowflake workloads authenticate to external services, with Snowflake acting as the OIDC provider. The minimum key is a 2048-bit RSA pair. Snowflake also accepts RS256/384/512 signatures, plus ECDSA keys in the Python driver only. An encrypted private key is generally safer. Its passphrase protects only the local key file and is never sent to Snowflake. Use AES-256-CBC, because Triple DES is not recommended.

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

Assigning a public key requires OWNERSHIP of the user or the MODIFY PROGRAMMATIC AUTHENTICATION METHODS privilege on it. That privilege lets a service team manage its own service user's keys without owning the user. Snowflake recommends a named key pair, because it supports role restriction, named key management and expiry. The older SET RSA_PUBLIC_KEY approach supports none of these.

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

To verify the setup, compare the user's RSA_PUBLIC_KEY_FP from DESC USER with the SHA-256 digest of your local public key. When they match, point the client at the private key.

Role restriction also applies to PATs, which are controlled through the PAT_POLICY of an authentication policy. By default, a PAT for a service user must specify a role restriction. Setting REQUIRE_ROLE_RESTRICTION_FOR_SERVICE_USERS = FALSE lifts that for service users, on the account or on specific users. Changing it from FALSE back to TRUE invalidates service-user tokens that were generated without a role restriction. For person users, no role restriction is required by default. Setting REQUIRE_ROLE_RESTRICTION_FOR_PERSON_USERS to TRUE requires one.

Sources123

2.Programmatic access tokens (PATs)

A programmatic access token (PAT) is a bearer credential. It works against the REST and SQL APIs, Snowpark Container Services endpoints and SCIM. It can also stand in for a password in drivers, the CLI and tools such as Tableau. Both human users (TYPE=PERSON) and service users (SERVICE, SERVICE_AGENT) can have PATs, and you generate one with ALTER USER … ADD PROGRAMMATIC ACCESS TOKEN. By default, service users must give each token a role restriction. That role is used for privilege evaluation in sessions the token authenticates.

The default safeguard is a network policy requirement, and it applies differently to each user type. A service user can neither generate nor use a token unless a network policy applies to them. A service agent user needs no network policy at all. A human user can generate a token without one but needs one to authenticate with it. The NETWORK_POLICY_EVALUATION setting in an authentication policy's PAT_POLICY changes this default:

Two more PAT settings matter. First, any authentication policy that limits AUTHENTICATION_METHODS has to list 'PROGRAMMATIC_ACCESS_TOKEN', or PATs stop working entirely. Second, expiry is controlled by the policy. Tokens default to 15 days, and the ceiling is 365 days unless MAX_EXPIRY_IN_DAYS lowers it.

CREATE AUTHENTICATION POLICY my_authentication_policy
  PAT_POLICY=(
    MAX_EXPIRY_IN_DAYS=100
  );

Sources3

3.Rotating credentials without downtime

Rotate keys on your internal schedule. With named key pairs, generate a new pair and swap in the new public key. In-flight clients keep working on the old key during the grace period. Set EXPIRE_ROTATED_KEY_PAIR_AFTER_HOURS to change the period, where 0 expires the old key immediately.

ALTER USER example_user  ?  KEY PAIR my_key PUBLIC_KEY = 'JERUEHtcve...';

Users set up the legacy way have two key slots, RSA_PUBLIC_KEY and RSA_PUBLIC_KEY_2. Load the new key into the unused slot and switch clients to the new private key. Snowflake matches whichever key is active. Then run ALTER USER example_user UNSET RSA_PUBLIC_KEY; to remove the old key.

For PATs, the default lifetime and the MAX_EXPIRY_IN_DAYS cap force regular replacement. A token can be revoked with ALTER USER … REMOVE PROGRAMMATIC ACCESS TOKEN. The SHOW USER PROGRAMMATIC ACCESS TOKENS output includes a rotated_to column alongside expires_at and status. These sources do not show the syntax of a dedicated PAT rotate command, so check the current command reference for it.

Passwords are credentials too. DESC USER shows PASSWORD_LAST_SET_TIME, the time the last non-NULL password was set. MUST_CHANGE_PASSWORD set to TRUE forces the user to change their password on next login. After a leaked-password detection, an administrator sends a reset link, and the new password must meet the account's password policies.

Sources14

4.Secrets for authenticating to external APIs

Authentication also runs in the other direction, when Snowflake code calls an external service. Credentials for those calls belong in a secret, which is a schema-level object, rather than in code. Pick the secret's TYPE to match how the external API authenticates. OAuth secrets point at a security integration through API_AUTHENTICATION, and the integration holds the OAuth client configuration. A WORKLOAD_IDENTITY_FEDERATION secret is the type for workload identity federation, where Snowflake workloads authenticate to external services with Snowflake acting as the OIDC provider. Only roles granted READ on a secret may use an integration containing it in a UDF or procedure. How a secret is wired into an external access integration is covered in the external access lesson.

CREATE [ OR REPLACE ] SECRET [ IF NOT EXISTS ] <name>
  TYPE = OAUTH2
  API_AUTHENTICATION = <security_integration_name>
  OAUTH_SCOPES = ( '<scope_1>' [ , '<scope_2>' ... ] )
  [ COMMENT = '<string_literal>' ]

Sources52

5.Session policies and session monitoring

Authentication starts a session, and a session policy limits how long that session lasts. Snowflake sessions are independent of IdP sessions. If a Snowflake session expires while the IdP session is still active, the user can sign back in silently. A policy sets two limits: an idle timeout, and a maximum lifespan that ends the session even while it is in use. Each limit has separate properties for Snowsight and for programmatic clients:

You can set policies on the account and on individual users, and a user-level policy overrides the account one. When a session closes, its running queries are terminated shortly afterwards. To monitor sessions, query the SESSIONS view in ACCOUNT_USAGE, or open the Sessions tab under Governance & security » Network policies. The tab shows the user, start time, client driver, address and authentication method of each session.

Sources6

6.Leaked password and malicious IP protection

Two built-in services defend sign-in without any setup. Leaked password protection is always on and cannot be disabled. It runs in the background and checks whether passwords found in external breach data still work. All user types are scanned. If a leaked password still authenticates, Snowflake unsets it, permanently rejects it for that user, and emails both the user and the administrator. The user can still sign in by other methods, such as SSO. To get a password back, they ask an administrator for a reset link, and the new password must meet the account's password policies. If the leaked password belongs to an administrator and no other administrator can reset it, that administrator must contact Snowflake Support.

Malicious IP Protection blocks sign-in attempts from a curated threat-intelligence list of IPv4 and IPv6 addresses. All categories are blocked by default:

Blocked attempts appear in LOGIN_HISTORY with IS_SUCCESS = 'NO', ERROR_CODE 390422 and ERROR_MESSAGE 'INCOMING_REQUEST_BLOCKED'. Their login_details field shows the category, the risk classification and the result.

SELECT *
  FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
  WHERE NOT is_success AND login_details IS NOT NULL
  ORDER BY event_timestamp DESC;

The risk classification, LOW or HIGH, is recorded in login_details for each blocked IP address, so read it there rather than assuming it from the category name. The sources do not list which categories are low or high. ACCOUNTADMIN can opt out of blocking for a category when the blocked IPs in it were classified as low-risk, either account-wide or for a single user, by calling SYSTEM$OPT_OUT_MALICIOUS_IP_PROTECTION_BY_CATEGORY. IPs classified as high-risk can't be opted out of. Passing '' re-enables blocking.

USE ROLE ACCOUNTADMIN;
SELECT SYSTEM$OPT_OUT_MALICIOUS_IP_PROTECTION_BY_CATEGORY('ANONYMOUS_VPN', 'JSMITH');

Sources789

Exam traps

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

1. 1.Lowering MAX_EXPIRY_IN_DAYS only affects tokens generated afterwards.Why is that wrong?

   Existing tokens whose expiry exceeds the new maximum stop authenticating immediately.

   Covered in Programmatic access tokens (PATs)

2. 2.Calling the malicious-IP opt-out function again adds the new category to the existing opt-outs.Why is that wrong?

   Each call replaces the previous one. To keep several categories opted out, list all of them in a single call.

   Covered in Leaked password and malicious IP protection

3. 3.A short idle timeout is enough to cap how long an actively used session stays open.Why is that wrong?

   Idle timeout only ends inactive sessions. Capping an active session takes a maximum lifespan, which ends the session after a set duration regardless of activity.

   Covered in Session policies and session monitoring

Practise it for real

Set up key-pair authentication for a test user, then rotate the key without downtime

1. 1.Run: openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.p8, then openssl rsa -in rsa_key.p8 -pubout -out rsa_key.pub

   Why: Creates an AES-256-encrypted private key and derives its public key

   You should see: rsa_key.p8 starts with BEGIN ENCRYPTED PRIVATE KEY and rsa_key.pub with BEGIN PUBLIC KEY

2. 2.Run ALTER USER example_user ADD KEY PAIR my_key PUBLIC_KEY = '<key body without delimiters>'

   Why: Registers a named key pair, which supports expiry and role restriction

   You should see: SHOW USER KEY PAIRS lists my_key

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

   Why: Confirms Snowflake stored the key you generated

   You should see: Both outputs match

4. 4.Generate a second key pair and run ALTER USER example_user ROTATE KEY PAIR my_key PUBLIC_KEY = '<new key body>'

   Why: Replaces the key while the old one stays valid for the grace period

   You should see: Connections with either private key succeed until the 24-hour default grace period ends