What you will be able to do
- Say which privileges the owner, the author and the callers of an external function each need
- Explain how a credential-less API integration and its allowed-prefix list control which endpoints Snowflake can reach
- Use API keys correctly alongside IAM
- Choose SECURE and the transport protections that keep endpoint details and data in transit protected
1.Who needs which privilege
An external function is a UDF that runs its code in a remote service outside Snowflake. It reaches that service through a cloud proxy, using credentials stored in a Snowflake object called an API integration. For access control it follows the normal UDF rules: it has an owner, and the owner must grant privileges to anyone else who calls it. The API integration adds one more requirement. The function's author must hold USAGE on the integration the function names. Creating the integration takes ACCOUNTADMIN or a role with the CREATE INTEGRATION privilege. Account administrators can then grant and revoke ownership and usage on each integration. That split lets a small admin group control the cloud trust relationship while developers write functions against it.
| Who | Needs | Notes |
|---|---|---|
| Creator of the API integration | ACCOUNTADMIN, or a role with CREATE INTEGRATION | An API integration is a database object |
| Author of the external function | USAGE on the API integration | Applies in addition to the normal UDF rules |
| Callers other than the owner | Privilege(s) on the function granted by the owner | Future grants on external functions are not supported |
One limitation affects how you plan grants: future grants of privileges on external functions are not supported. A schema-level future grant won't cover an external function created later. Grant privileges on each function after you create it.
Checkpoint 1 of 5· Check yourself
A developer has CREATE FUNCTION on a schema, but their CREATE EXTERNAL FUNCTION statement fails. An admin already created the API integration. Which privilege is most likely missing?
The author of an external function must have USAGE on the API integration it references. CREATE INTEGRATION is needed only to create the integration itself.
“the author of the external function must be granted USAGE privilege on the API integration.”Source: docs.snowflake.com
Sources1
2.The API integration: trust policy, allowed endpoints and API keys
Snowflake authenticates to the proxy endpoint through credential-less API integrations. No password is stored in the function. Instead, an administrator sets up a trust policy between Snowflake and the cloud provider using the provider's own authentication and authorization. When Snowflake connects, the cloud provider checks the request against that trust policy. On AWS, the integration names an IAM role through API_AWS_ROLE_ARN. The administrator can also restrict which proxy endpoints the integration may call, which enforces organizational rules on data egress and ingress.
| Parameter | Purpose |
|---|---|
| API_PROVIDER | Proxy type, e.g. aws_api_gateway (regional endpoints) or aws_private_api_gateway (private endpoints) |
| API_AWS_ROLE_ARN | ARN of the cloud platform role that Snowflake uses |
| API_ALLOWED_PREFIXES | Limits the functions that use the integration to listed HTTPS proxy endpoints and resources, treated as URL prefixes |
Checkpoint 2 of 5· Fill the gap
Which clause names the object Snowflake uses to authenticate to the proxy service?
[ COMMENT = '<string_literal>' ]
? = <api_integration_name>
[ HEADERS = ( '<header_1>' = '<value_1>' [ , '<header_2>' = '<value_2>' ... ] ) ]API_INTEGRATION in CREATE EXTERNAL FUNCTION names the integration that authenticates the call. API_KEY and API_AWS_ROLE_ARN belong to CREATE API INTEGRATION, not to the function.
Source: docs.snowflake.comSome API gateways also expect subscription information, for example to confirm a paying customer or to enforce usage quotas. Snowflake supports this with API keys, which Azure calls subscription keys. You set one with the optional API_KEY clause of CREATE API INTEGRATION or ALTER API INTEGRATION. Three facts matter. First, the key is added on top of IAM; it doesn't replace it. Second, the key is treated as sensitive: it doesn't appear in query history, DESCRIBE INTEGRATION or DESCRIBE API INTEGRATION output. Third, the service developer chooses the key's format, and Snowflake neither interprets nor validates it.
Checkpoint 3 of 5· Check yourself
A team adds API_KEY to its API integration and wants to remove the IAM role trust to simplify setup. What is correct?
An API key adds subscription information on top of IAM authentication. It is never a substitute for it.
“An API_KEY is in addition to, not a substitute for, IAM (Identity and Access Management).”Source: docs.snowflake.com
3.SECURE functions, encrypted transport and the remote service
The function definition holds details you may not want callers to see: the proxy URL, custom HTTP headers and context headers. Creating it with CREATE SECURE EXTERNAL FUNCTION hides these from every user who doesn't own the function. Callers can still run it. SECURE is also one of the properties CREATE OR ALTER EXTERNAL FUNCTION can change on an existing function.
Checkpoint 4 of 5· Check yourself
For a SECURE external function, what is hidden, and from whom?
SECURE hides the endpoint and header details from non-owners. Owners still see them, and callers still get results.
“the URL, the HTTP headers, and the context headers are hidden from all users who are not owners of the function”Source: docs.snowflake.com
Next, protect the path the data travels. Traffic between Snowflake and the proxy is encrypted with HTTPS. On AWS, every request Snowflake sends to API Gateway is signed with AWS sigv4 authentication. Unless the function is meant to be public, Snowflake strongly recommends securing the proxy endpoints. On AWS you can add a resource policy to the API Gateway endpoint, and private endpoints can use PrivateLink. If you built the remote service yourself, secure it as well. In most cases it should use HTTPS, not HTTP. For response integrity, the remote service can return a Content-MD5 header. Snowflake checks it against the response body and fails the query if they don't match.
Finally, think about where the data goes. A third party's remote service could keep copies of every row you send it, so access controls inside Snowflake don't protect data once it has been sent out.
| Hop | Protection named in the docs |
|---|---|
| Snowflake to proxy | HTTPS encryption; AWS sigv4 request signing; credential-less API integration trust policy |
| Proxy endpoint | Resource policy on the API Gateway endpoint; PrivateLink for private endpoints; optional API key |
| Remote service | Secured by its implementer; HTTPS rather than HTTP in most cases |
| Response | Optional Content-MD5 header checked by Snowflake |
Checkpoint 5 of 5· Exam question
A platform team manages a single API integration that several teams will use to create external functions. To prevent one team from pointing a new external function at an unapproved endpoint while still sharing the same integration's credentials, what should the platform team configure on the integration object?
Correct answer: A — Set `API_ALLOWED_PREFIXES` on the integration so only URLs matching the approved proxy path can be used by any function referencing it.
- A. The allowed-prefixes list on an API integration restricts which URL patterns any external function created against it may target, which is exactly the control needed to stop teams from pointing new functions at unapproved endpoints.
- B. Batch row limits control how many rows are grouped into a single outbound request for performance and cost reasons, but they place no restriction on which URL an external function can call.
- C. Compression reduces the size of data transferred to the remote service; it has no bearing on which endpoint URLs are permitted for functions built on the integration.
- D. Context headers pass Snowflake session metadata to the remote service, which is useful for auditing on the receiving end, but it does not constrain which proxy URL a new function can be created against.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.An API key can replace the IAM role in an API integration.Why is that wrong?
API keys only add subscription information for the gateway. IAM authentication through the integration's trust policy is still required.
Covered in The API integration: trust policy, allowed endpoints and API keys
2.A future grant on functions in a schema will cover external functions created later.Why is that wrong?
Future grants are not supported for external functions. Grant privileges on each one explicitly.
Covered in Who needs which privilege
3.Marking an external function SECURE protects the data sent to a third-party remote service.Why is that wrong?
SECURE only hides the URL and headers from non-owners. Once data reaches a third party's service, that party could keep copies of it.
Covered in SECURE functions, encrypted transport and the remote service
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“To create an API integration, you need ACCOUNTADMIN privileges or a Snowflake role with the CREATE INTEGRATION privilege.”
↩︎ Who needs which privilege“The owner must grant callers (other than the owner) appropriate privilege(s) on the function.”
↩︎ Who needs which privilege“Snowflake uses credential-less API integration objects to authenticate to the proxy service endpoint.”
↩︎ The API integration: trust policy, allowed endpoints and API keys“The key is opaque to Snowflake, and Snowflake does not validate it.”
↩︎ The API integration: trust policy, allowed endpoints and API keys“For AWS, all Snowflake HTTP requests (going to the API Gateway) are signed using AWS sigv4 authentication.”
↩︎ SECURE functions, encrypted transport and the remote service“Unless your external function is intended to be publicly accessible, Snowflake strongly recommends securing your proxy service endpoints.”
↩︎ SECURE functions, encrypted transport and the remote service“An API_KEY is in addition to, not a substitute for, IAM (Identity and Access Management).”
↩︎ Exam trap 1“the author of the external function must be granted USAGE privilege on the API integration.”
↩︎ Checkpoint“An API_KEY is in addition to, not a substitute for, IAM (Identity and Access Management).”
↩︎ Checkpoint - 2.
“Explicitly limits external functions that use the integration to reference one or more HTTPS proxy service endpoints”
↩︎ The API integration: trust policy, allowed endpoints and API keys - 3.
“If the values do not match, the SQL query fails.”
↩︎ SECURE functions, encrypted transport and the remote service
Also cited
“Future grants of privileges on external functions are not supported.”
↩︎ Exam trap 2“that party could keep copies of the data passed to the function.”
↩︎ Exam trap 3“the URL, the HTTP headers, and the context headers are hidden from all users who are not owners of the function”
↩︎ Checkpoint