What you will be able to do
- Explain what an external access integration aggregates and what it denies by default
- Write an EGRESS network rule that names an allowed external endpoint and port
- Put the setup steps for external network access in the order Snowflake documents
- Identify the privileges and switches an administrator uses to control and monitor external access
Key concept
External access integration — An account-level allowlist that ties egress network rules (where handler code may connect) to secrets (which credentials it may use). A UDF or procedure can only reach external locations, and only use credentials, that an integration it references allows.
1.What an external access integration controls
By default, code in a user-defined function (UDF) or stored procedure cannot open connections outside Snowflake. To let handler code call an outside API, you create an external access integration. It brings together two allowlists. Network rules say where the code may connect. Secrets say which stored credentials it may use to authenticate. A developer opts in by naming the integration in the EXTERNAL_ACCESS_INTEGRATIONS clause of CREATE FUNCTION or CREATE PROCEDURE.
With an integration you can write handlers that reach external locations, allow or block particular locations, and decide which secrets may be used with them. You can also choose whether traffic crosses the public internet or a private network. One design goal runs through all of this: credentials stay out of code. Handlers authenticate with secrets that represent stored credentials, not with values typed into the handler.
The integration is deny-by-default. If a handler tries to reach a location that no allowed network rule names, the request is denied. Being allowed to use external access in general does not unlock the whole internet.
Checkpoint 1 of 6· Check yourself
What two kinds of objects does an external access integration bring together?
An integration lists the network rules a handler may reach and the secrets it may use. Network policies govern inbound traffic, and API integrations belong to external functions.
“an external access integration that specifies a list of network rules that specify external locations and a list of secrets”Source: docs.snowflake.com
2.Network rules as the allowlist of external endpoints
A network rule is a schema-level object that groups network identifiers of one type, such as hostnames or IP ranges. The rule does not decide whether those identifiers are allowed or blocked. The feature that uses the rule makes that decision. The same kind of object serves two features. Network policies use rules to control inbound traffic to Snowflake. External network access uses rules to control outbound requests from UDFs and procedures.
The MODE parameter says which direction a rule is for. A rule meant for an external access integration must use MODE = EGRESS. TYPE gives the kind of network: HOST_PORT for an endpoint on the public internet, or PRIVATE_HOST_PORT when you use private connectivity. VALUE_LIST holds the endpoints. You can add a port to an endpoint name. If you leave the port out, Snowflake uses 443.
| Parameter | What to set |
|---|---|
| MODE | EGRESS |
| TYPE | HOST_PORT, or PRIVATE_HOST_PORT for private connectivity |
| VALUE_LIST | The external endpoint, optionally with a port, e.g. 'example.com:80' |
| Port (omitted) | Defaults to 443 |
CREATE OR REPLACE NETWORK RULE google_apis_network_rule
MODE = EGRESS
TYPE = HOST_PORT
VALUE_LIST = ('translation.googleapis.com');Creating a rule requires the CREATE NETWORK RULE privilege on the schema that will hold it. By default, only ACCOUNTADMIN, SECURITYADMIN and the schema owner have that privilege. This means that defining where data may go is a security-team decision by default, not something every developer can do.
Checkpoint 2 of 6· Check yourself
An egress rule has VALUE_LIST = ('api.vendor.example') with no port. Which port can handler code reach?
If you leave the port off, Snowflake uses 443, its default port for external access. To allow any other port, write it into the value, e.g. 'example.com:80'.
“If you omit a port number, Snowflake will use the default port number for external access, 443.”Source: docs.snowflake.com
3.Order of operations for enabling external access
The exam guide puts a third-party vendor risk assessment at the start of this process: deciding whether the outside service should receive data from Snowflake at all. The Snowflake documentation available for this lesson does not describe what that assessment contains. So this lesson treats it only as the gate that comes before the first Snowflake object exists, and does not offer a checklist for it.
After that gate, Snowflake documents a fixed sequence, and each step depends on the one before it:
1. Choose the connectivity path: public internet or private connectivity. This decides whether the rule uses HOST_PORT or PRIVATE_HOST_PORT.
2. Create a network rule for the external location.
3. Create a secret to hold the credentials.
4. Create the external access integration, which brings the rule and the secret together. It can only list objects that already exist.
5. Create the UDF or procedure with EXTERNAL_ACCESS_INTEGRATIONS set to the integration. Use SECRETS to name the secret the handler will read. That secret must also be listed in the integration.
Checkpoint 3 of 6· Put it in order
Put the documented setup steps for external network access in order
- 1.Choose public internet or private connectivity
- 2.Create the UDF or procedure with EXTERNAL_ACCESS_INTEGRATIONS set
- 3.Create a secret to hold credentials
- 4.Create the external access integration aggregating the rule and secret
- 5.Create a network rule for the external location
The integration refers to the rule and the secret, and the function refers to the integration. So each object has to exist before the next one can use it.
“Create an external access integration, aggregating the secret and network rule so that they may be used by the handler”Source: docs.snowflake.com
Sources1
4.Privileges, the ENABLED switch and monitoring
Creating an integration requires the CREATE INTEGRATION privilege on the account. The creator also needs USAGE on every secret the integration lists, and USAGE on each secret's schema. The integration's ENABLED property is a single switch. An administrator can disable an integration to cut off external access for every function and procedure that references it, without dropping or changing those objects.
Checkpoint 4 of 6· Fill the gap
Which clause names the credentials that handlers using this integration may use?
CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION google_apis_access_integration
ALLOWED_NETWORK_RULES = (google_apis_network_rule)
? = (oauth_token)
ENABLED = true;ALLOWED_AUTHENTICATION_SECRETS lists the secrets on the integration. SECRETS is the clause on CREATE FUNCTION/PROCEDURE, and API_AUTHENTICATION is a property of a secret.
Source: docs.snowflake.comSeparate privileges apply to the developer who creates the function. Their role needs USAGE on the integration and READ on every secret the function references, plus USAGE on that secret's schema. Snowflake says these requirements let an administrator control which users can turn on external access. Because only roles with READ on a secret can use an integration that contains it, the secret also becomes a point where credential use can be audited.
To monitor the outbound requests themselves, use the EXTERNAL_ACCESS_HISTORY view.
Checkpoint 5 of 6· Check yourself
A developer role has USAGE on the integration, the secret and the secret's schema. CREATE FUNCTION referencing the secret still fails. What is missing?
A role that creates a UDF or procedure needs READ on each secret it references. USAGE on the secret is what the integration creator needs.
“The READ privilege on any secret it references, as well as the USAGE privilege on the secret’s schema.”Source: docs.snowflake.com
Checkpoint 6 of 6· Exam question
A security team is approving a new Snowpark UDF that will send customer email addresses to a third-party enrichment API. Which order of operations should be followed to enable this external access?
Correct answer: A — Complete the vendor risk assessment, then create the egress network rule and secret, then the integration, then grant usage and create the function.
- A. Correct: the risk assessment decides whether the vendor may receive the data and which host and credential scope is acceptable, so it must precede creating any rule, secret or integration.
- B. Incorrect: testing against the live vendor already sends real or test data off-platform before the assessment has approved the endpoint, so the control comes too late.
- C. Incorrect: a broad egress rule opens outbound access before the vendor is vetted, and tightening afterwards leaves a window of unapproved data exposure.
- D. Incorrect: running the function in production before the assessment means customer data may already have reached an unapproved third party.
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A network rule allows or blocks traffic by itself, so creating one opens access to its hosts.Why is that wrong?
A rule only groups identifiers. The feature that uses it decides what they mean. For egress, an external access integration referencing the rule is what allows those locations.
Covered in Network rules as the allowlist of external endpoints
2.USAGE on a secret is all a developer needs to reference it from a UDF.Why is that wrong?
USAGE on the secret is what the integration creator needs. A role creating a UDF or procedure needs READ on each secret it references, plus USAGE on the secret's schema.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://docs.snowflake.com/en/developer-guide/external-network-access/creating-using-external-network-accessOfficial docs
“An attempt to access a network location that is not specified by an allowed network rule will be denied.”
↩︎ What an external access integration controls“EGRESS as the MODE parameter value.”
↩︎ Network rules as the allowlist of external endpoints“Choose whether to connect to the external network location using the public internet or private connectivity.”
↩︎ Order of operations for enabling external access“An administrator can also enable or disable the integration to manage access to external locations.”
↩︎ Privileges, the ENABLED switch and monitoring“Requiring these privileges enables an administrator to manage the set of users who can enable external access.”
↩︎ Privileges, the ENABLED switch and monitoring“An administrator can monitor requests made to external network locations by using the EXTERNAL_ACCESS_HISTORY view.”
↩︎ Privileges, the ENABLED switch and monitoring“the external access integration specifies those network rules and secrets that UDFs and procedures referencing the integration may use.”
↩︎ Key concept“only those granted the READ privilege on the secret may use an integration containing it in a UDF or procedure.”
↩︎ Exam trap 2“an external access integration that specifies a list of network rules that specify external locations and a list of secrets”
↩︎ Checkpoint“If you omit a port number, Snowflake will use the default port number for external access, 443.”
↩︎ Checkpoint“Create an external access integration, aggregating the secret and network rule so that they may be used by the handler”
↩︎ Checkpoint“The READ privilege on any secret it references, as well as the USAGE privilege on the secret’s schema.”
↩︎ Checkpoint - 2.https://docs.snowflake.com/en/developer-guide/external-network-access/external-network-access-overviewOfficial docs
“Use secrets that represent stored credentials, rather than using literal values, within handler code to authenticate with external network locations.”
↩︎ What an external access integration controls - 3.
“Network policies use network rules to control inbound network traffic to the Snowflake service and internal stages.”
↩︎ Network rules as the allowlist of external endpoints“By default, only the ACCOUNTADMIN and SECURITYADMIN roles, along with the schema owner, have this privilege.”
↩︎ Network rules as the allowlist of external endpoints“A network rule does not define whether its identifiers should be allowed or blocked.”
↩︎ Exam trap 1