Snowflake Secrets, API Authentication and External Functions for Secure Egress

1.Secrets: one object, four credential shapes

A secret is a schema-level object that holds sensitive information. Access to it is controlled by role-based access control (RBAC), and its contents are encrypted with keys from Snowflake's key encryption hierarchy. Once a secret exists, only specific Snowflake components, such as integrations and external functions, can read its contents. A user who runs DESCRIBE SECRET never sees the stored password.

For external endpoints, choose the TYPE that matches how the endpoint authenticates:

CREATE [ OR REPLACE ] SECRET [ IF NOT EXISTS ] <name>
  TYPE = PASSWORD
  USERNAME = '<username>'
  PASSWORD = '<password>'
  [ COMMENT = '<string_literal>' ]

CREATE OR REPLACE SECRET bp_maps_api
  TYPE =  ? 
  SECRET_STRING = 'replace-with-your-api-key';

Sources1

2.API authentication integrations behind OAuth secrets

For external API authentication, Snowflake supports three methods: basic authentication, OAuth with the authorization code grant flow, and OAuth with the client credentials flow. Basic authentication only needs a PASSWORD secret. The OAuth flows also need a security integration for external API authentication. It holds the values the OAuth flow requires, such as the client ID, client secret and token endpoint. An OAUTH2 secret points to that security integration through API_AUTHENTICATION. Snowflake calls this pattern a best practice for OAuth endpoints.

The two OAuth flows use different secret properties. In the authorization code grant flow, the secret stores OAUTH_REFRESH_TOKEN, which is used to get a new access token when the current one expires, along with its expiry time. In the client credentials flow, the secret can set OAUTH_SCOPES. These scopes must be a subset of the OAUTH_ALLOWED_SCOPES defined on the security integration.

CREATE OR REPLACE SECRET oauth_token
  TYPE = OAUTH2
  API_AUTHENTICATION = google_translate_oauth
  OAUTH_REFRESH_TOKEN = 'my-refresh-token';

In handler code, a Python UDF gets the token with _snowflake.get_oauth_access_token('cred'). Here 'cred' is the name that the function's SECRETS clause binds to the secret, so the token value never appears in the code. This setup also supports separation of duties. One team manages the secret. The roles that use a connector need only the secret's name and never see what it contains.

Sources12

3.External functions: API integrations and proxy services

An external function is the other way to reach outside code from SQL. Unlike a UDF that uses an external access integration, it has no handler code of its own. It calls a remote service that runs outside Snowflake, such as an AWS Lambda function. Snowflake never calls that remote service directly. It sends the request to a cloud provider's proxy service, such as Amazon API Gateway, which passes it on. The security information is stored in an API integration, created with CREATE API INTEGRATION. Creating one requires ACCOUNTADMIN or a role with CREATE INTEGRATION. The author of the function needs USAGE on the API integration.

API integrations do not store credentials. Instead, the administrator sets up a trust policy that uses the cloud provider's own authentication. On AWS, you edit the IAM role's trust relationship: set Statement.Principal.AWS to the integration's API_AWS_IAM_USER_ARN, and add a StringEquals condition on sts:ExternalId set to its API_AWS_EXTERNAL_ID.

The integration's API_ALLOWED_PREFIXES lists the proxy endpoints that functions may call, and you should keep that list as narrow as you can. Unless the function is meant to be public, protect the proxy too. Require AWS_IAM authorization on the method and restrict the API Gateway with a resource policy. An optional API_KEY adds a subscription key, but it does not replace IAM.

Sources3456

4.Egress paths: public internet, private connectivity and Data Connectivity Proxy

Each external route has to cross a network. By default it uses the public internet. For stricter requirements, outbound traffic can instead use private connectivity: Azure Private Link, AWS PrivateLink or Google Cloud Private Service Connect. This applies to external access integrations, external functions, external stages and other features. It has three conditions: the account must be Business Critical Edition or higher, the person configuring it must have ACCOUNTADMIN, and there are extra charges for each endpoint and for the total data processed. In the network rule, TYPE = PRIVATE_HOST_PORT replaces HOST_PORT.

Some private sources cannot be reached through a cloud-provider private endpoint: on-premises systems, cross-cloud sources and sources not native to a cloud provider. For these, Snowflake offers Data Connectivity Proxy. You add a network rule with MODE = DATA_CONNECTIVITY_PROXY_EGRESS to the integration. Then you attach the integration to the proxy object with EXTERNAL_ACCESS_INTEGRATIONS on CREATE DATA CONNECTIVITY PROXY or ALTER DATA CONNECTIVITY PROXY. The provided sources go no further than that, and Snowflake's setup procedure is documented separately.

Sources789

Exam traps

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

1. 1.An OAuth access or refresh token can go in a GENERIC_STRING secret because it is just a string.Why is that wrong?

   Snowflake says GENERIC_STRING must not hold any kind of OAuth token. Use an OAUTH2 secret that references a security integration.

   Covered in Secrets: one object, four credential shapes

2. 2.Adding an API_KEY to an API integration secures the proxy, so IAM authorization can be skipped.Why is that wrong?

   An API key (subscription key) is an extra layer on top of IAM, not a replacement. Keep AWS_IAM authorization and a resource policy on the proxy.

   Covered in External functions: API integrations and proxy services

Practise it for real

Give a Python UDF access to one external API host and confirm that every other host is blocked

1. 1.Create a network rule with MODE = EGRESS, TYPE = HOST_PORT and VALUE_LIST set to the vendor's host.

   Why: The rule names the one location the handler will be allowed to reach.

   You should see: The rule exists in your security schema; no port given means 443.

2. 2.Create a secret whose TYPE matches the vendor's authentication: OAUTH2 with API_AUTHENTICATION for OAuth, GENERIC_STRING for an API key.

   Why: Credentials live in an encrypted, RBAC-controlled object, not in handler code.

   You should see: DESCRIBE SECRET shows the secret's metadata, not its value.

3. 3.Run CREATE EXTERNAL ACCESS INTEGRATION with ALLOWED_NETWORK_RULES and ALLOWED_AUTHENTICATION_SECRETS listing your rule and secret, and ENABLED = true.

   Why: The integration is the allowlist that functions will reference.

   You should see: Succeeds only for a role with CREATE INTEGRATION and USAGE on the secret and its schema.

4. 4.As the developer role (USAGE on the integration, READ on the secret), create the UDF with EXTERNAL_ACCESS_INTEGRATIONS and SECRETS clauses.

   Why: The function opts in to the integration and binds the secret to a name the handler uses.

   You should see: Calls to the allowed host succeed; calls to any other host are denied.

5. 5.Query the EXTERNAL_ACCESS_HISTORY view.

   Why: Administrators monitor outbound requests here.

   You should see: Your UDF's requests to the external location are recorded.