Restricting Unload Destinations with Account and User Parameters

1.Three places COPY INTO <location> can write

Every programmatic write out of Snowflake goes through COPY INTO <location>. It can target three kinds of destination. The first is a named internal stage, or a table or user stage. Files written there can then be downloaded with the GET command. The second is a named external stage that points at Amazon S3, Google Cloud Storage or Microsoft Azure. The third is an external location: a cloud storage URL written directly into the statement.

The third form is the ad hoc one. The documentation describes it as a good fit when you aren't planning regular unloads with the same table and bucket. The statement itself names the bucket and says how to authenticate. For S3, the syntax accepts either STORAGE_INTEGRATION = <integration_name> or a CREDENTIALS clause with AWS_KEY_ID and AWS_SECRET_KEY.

COPY INTO 's3://mybucket/unload/' FROM mytable STORAGE_INTEGRATION = s3_int;

From a security point of view, each destination is a separate exfiltration channel. An inline URL lets anyone who has credentials for a bucket write table data into that bucket, and no administrator-controlled object stands in the way. An internal stage keeps the files inside Snowflake, but GET can then move them to a local machine. An external stage is only as safe as the credentials and the URL stored in its definition. The rest of this page covers the parameter that controls each channel.

Sources12

2.Closing inline URLs and internal stages

Two Boolean parameters close the first two channels. Both default to FALSE, so both channels are open until you change them.

**PREVENT_UNLOAD_TO_INLINE_URL** blocks ad hoc unloads to external cloud storage, meaning statements that put the URL and access settings inline. When it is TRUE, COPY INTO <location> must reference a named internal or external stage, or a user or table stage. A named external stage must store the URL and access settings in its own definition. Unloading to cloud storage is still possible. It just has to go through a stage object that someone created and can audit.

**PREVENT_UNLOAD_TO_INTERNAL_STAGES** blocks unloads into user stages, table stages and named internal stages. It shuts the route where data is unloaded into a stage and then pulled down with GET:

COPY INTO @~/unload/ from mytable FILE_FORMAT = (FORMAT_NAME = 'my_csv_unload_format' COMPRESSION = NONE);

While it is FALSE, only the usual rules for each stage type apply. Users can unload only to their own user stage. They can unload to a table stage only when their active role owns the table, and to a named internal stage only when their role has WRITE on it.

The two parameters are set at the same levels. Both can be set at the account level and overridden for an individual user (Account » User). Both appear in the objectParams of ALTER USER. So you can set a strict account-wide default and exempt one service user, or leave the account open and lock down specific people.

Sources34

3.Forcing external stages through storage integrations

Turning off inline URLs moves external writes onto named stages. A named stage can still hold raw cloud keys, though. Two account parameters remove that option.

**REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION** applies when a stage is created. If it is TRUE, CREATE STAGE for a private cloud storage location must reference a storage integration object as its cloud credentials. If it is FALSE (the default), a stage can use explicit provider credentials such as secret keys or access tokens.

**REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_OPERATION** applies when a stage is used. If it is TRUE, loading from or unloading to a private cloud storage location must go through a named external stage that references a storage integration. A stage built on explicit credentials raises a user error. The creation parameter only stops new credential-based stages. The operation parameter also makes existing credential-based stages fail when they are used, so expect breakage when you turn it on in an established account.

Unlike the two PREVENT parameters, both REQUIRE parameters are account-only. You can't exempt an individual user.

Sources3

4.Storage integrations decide which buckets are reachable

Requiring storage integrations restricts *where* data can go, not only *how* it authenticates. A storage integration stores a generated IAM entity for your external cloud storage. It also stores an optional list of allowed or blocked locations. Cloud administrators grant that entity access to specific storage, and users no longer supply credentials when they create stages or unload data.

The destination limit comes from STORAGE_ALLOWED_LOCATIONS. It restricts the external stages that use the integration to the buckets, containers and optional paths you list. Each stage's URL must fall within one of those locations. STORAGE_BLOCKED_LOCATIONS can exclude locations explicitly. Watch for the * wildcard: STORAGE_ALLOWED_LOCATIONS accepts it and treats it as "allow access to all buckets and/or paths", which removes the restriction completely.

The integration also works as a kill switch. With ENABLED = FALSE, no new stages can reference it, and existing stages that use it lose access to their storage location.

One limitation affects planning. Storage integrations can reach cloud storage in a government region only from a Snowflake account in that same government region, and the same applies to regions in China. In those cases the documentation points you to the CREDENTIALS parameter in CREATE STAGE instead.

COPY INTO 's3://mybucket/unload/' FROM mytable  ?  = s3_int;

Sources5

Exam traps

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

1. 1.PREVENT_UNLOAD_TO_INTERNAL_STAGES still lets users unload to their own user stage.Why is that wrong?

   When TRUE, it blocks unloads to every internal stage type, including user stages and table stages.

   Covered in Closing inline URLs and internal stages

2. 2.PREVENT_UNLOAD_TO_INLINE_URL = TRUE stops all unloading to external cloud storage.Why is that wrong?

   It only removes the inline URL form. Unloads through a named external stage that stores its URL and access settings are still allowed.

   Covered in Closing inline URLs and internal stages

3. 3.Only newly created stages are affected by requiring storage integrations, so existing credential-based stages keep working.Why is that wrong?

   REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_OPERATION is checked when a stage is used. Loads or unloads through an existing stage with explicit credentials produce a user error.

   Covered in Forcing external stages through storage integrations