Service networking¶

Ingress connection timeout¶

Ingress endpoints have a timeout of 90 seconds. If there is no activity on a connection to an ingress endpoint for 90 seconds, Snowflake terminates the connection. If your application needs longer connectivity, use polling or WebSockets.

Ingress web browser authentication logout¶

If you’re building a web app that runs as a service, you have the option to allow users to log out from your app by directing them to /sfc-endpoint/logout.

After logging out, the user will be required to re-authenticate to Snowflake to access the public endpoint of the service.

Ingress and web app security¶

You can create a Snowpark Container Services service for web hosting using the public endpoint support (network ingress). For added security, Snowflake employs a proxy service to monitor incoming requests from clients to your service and outgoing responses from your service to the clients. This section explains what the proxy does and how it impacts a service deployed to Snowpark Container Services.

For example:

• The proxy does not forward an incoming HTTP request if the request uses a banned HTTP method.

• The proxy sends a 403 response to the client if the Content-Type header in the response indicates that the response contains an executable.

Additionally, the proxy can also inject new headers and alter existing headers in the request and the response, with your container and data security in mind.

For example, upon receiving a request, your service might send HTML, JavaScript, CSS, and other content for a web page to the client browser in the response. The web page in the browser is part of your service, acting as the user interface. For security reasons, if your service has restrictions (such as a restriction on making network connections to other sites), you might also want the web page for your service to have the same restrictions.

By default, services have limited permissions to access the internet. The browser should also restrict the client app from accessing the internet and potentially sharing data in most cases. If you set up an External Access Integration (EAI) to allow your service to access example.com (see Configuring network egress), the web page for your service should also be able to access example.com through your browser.

The Snowflake proxy applies the same network restrictions on the service and the web page by adding a Content-Security-Policy (CSP) header in the response. By default, the proxy adds a baseline CSP in the response to protect against common security threats. Browser security is a best effort to balance functionality with security, it is a shared responsibility to ensure this baseline is appropriate for your use case. In addition, if your service is configured to use an EAI, the proxy applies the same network rules from the EAI to the CSP for the web page. This CSP enables the web page in the browser to access the same sites that the service can access.

Snowflake provides CORS support which you configure in the service specification.

The Snowflake proxy returns the CORS settings defined in the service specification. Note that the proxy removes any CORS headers returned by the service.

The following CORS headers are set by default:

• Access-Control-Expose-Headers header always reports the following header names, in addition to headers configured in the service specification for the endpoint.

  • X-Frame-Options

  • Cross-Origin-Opener-Policy

  • Cross-Origin-Resource-Policy

  • X-Content-Type-Options

  • Cross-Origin-Embedder-Policy

  • Content-Security-Policy-Report-Only

  • Content-Security-Policy

• Access-Control-Max-Age is set to two hours.

• Access-Control-Allow-Credentials is set to true.

In addition, Snowflake sets the Vary header with the value Origin to indicate to the browser that based on the value of the Origin, the value to Access-Control-Allow-Origin might be different.

The Authorization header is required to make the CORS request. You can specify a programmatic access token (PAT) in this header (Authorization: "Snowflake Token=\"${patToken}\""). For information on generating a programmatic access token, see Using programmatic access tokens for authentication.

The following sections explain how the Snowflake proxy handles incoming requests for your service and modifies the outgoing responses from your service to the clients.

Ingress and CORS considerations¶

By default, browsers block web apps hosted on one server from sending requests to another server with a different hostname. For instance, if you host a web app outside Snowpark Container Services that needs to interact with a backend service deployed within Snowpark Container Services, this restriction applies.

CORS (Cross-Origin Resource Sharing) enables a Snowpark Container Services service to tell the browsers to allow requests from web apps hosted outside its environment. You can configure each public endpoint to specify how it responds to both CORS preflight requests and standard requests.

Snowflake proxy always overrides the following response headers:

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Expose-Headers

• Access-Control-Max-Age

• Access-Control-Allow-Credentials

The Snowflake proxy does not include any of these CORS headers in the response when either of the following is true:

• CORS is not configured for the service endpoint. That is, there no corsSettings in the service specification

• CORS is configured for the service endpoint, but the Origin header in the request doesn’t match the specified Access-Control-Allow-Origin field in the service specification

In the service specification, you can configure CORS settings for each public endpoint. When the origin header in the request matches the Access-Control-Allow-Origin field specified for the endpoint in the specification, the proxy includes in the response the CORS headers defined in the specification, with the following adjustments:

• Access-Control-Allow-Origin: Returns the Origin header from the request.

• Access-Control-Expose-Headers: Merges the list of allowed headers you configured with these always-exposed headers: X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, X-Content-Type-Options, Cross-Origin-Embedder-Policy, Content-Security-Policy-Report-Only, Content-Security-Policy.

• Access-Control-Max-Age: Is set to two hours.

• Access-Control-Allow-Credentials: Is set to true.

Ingress and SSO considerations¶

When accessing the public endpoint from the internet, you might find that username/password authentication works, but SSO results in a blank page or the error: “OAuth client integration with the given client ID is not found.”

This happens when you’re using the old style of federated authentication (SSO) with Snowflake instead of the newer security integration version as explained in Configuring Snowflake to use federated authentication. Do the following to verify:

1. Run the following query:

   SHOW PARAMETERS LIKE 'SAML_IDENTITY_PROVIDER' IN ACCOUNT;
   

   Copy

   If you have this parameter set, then at some point you were using the old-style federated authentication.

2. If the preceding parameter was set, run the following query to see if you have a SAML security integration:

   SHOW INTEGRATIONS
     ->> SELECT * FROM $1 WHERE "type" = 'SAML2';
   

   Copy

   If you don’t have any integrations of the SAML2 type, then you’re using the old style federated authentication.

In this case, the solution is to migrate from the old-style federated authentication to the new integration-style federated authentication. For more information, see Migrating to a SAML2 security integration.

Network egress using private connectivity¶

Instead of routing network egress via the public internet, you might opt to direct your service’s egress traffic through a private connectivity endpoint.

You first need to create the private connectivity endpoint in your Snowflake account. Then configure a network rule to permit outgoing traffic to use private connectivity. The process for setting up an External Access Integration (EAI) remains the same as described in the preceding section.

For example, if you want to enable your service’s outbound internet access to an Amazon S3 bucket via private connectivity, you do the following:

1. Enable the private link connectivity for the self-maintained endpoint service (Amazon S3). For step-by-step instructions, see AWS Private Link for Amazon S3.

2. Call the SYSTEM$PROVISION_PRIVATELINK_ENDPOINT system function to provision a private connectivity endpoint in your Snowflake VNet. This enables Snowflake to connect to the external service (in this example, Amazon S3) using private connectivity.

   USE ROLE ACCOUNTADMIN;
   
   SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
     'com.amazonaws.us-west-2.s3',
     '*.s3.us-west-2.amazonaws.com'
   );
   

   Copy

3. In the cloud provider account, approve the endpoint. In this example, for Amazon AWS, see Accept or reject connection requests in the AWS documentation. Also, to approve the endpoint in Azure, see the Azure documentation.

4. Use the CREATE NETWORK RULE command to create an egress network rule specifying the external destinations that you want to allow access to.

   CREATE OR REPLACE NETWORK RULE private_link_network_rule
     MODE = EGRESS
     TYPE = PRIVATE_HOST_PORT
     VALUE_LIST = ('<bucket-name>.s3.us-west-2.amazonaws.com');
   

   Copy

   The TYPE parameter value is set to PRIVATE_HOST_PORT. It indicates that the network rule allows outgoing network traffic to use private connectivity.

5. The rest of the steps to create an EAI and use it to create a service are the same as explained in the preceding section (see Configuring network egress).

For more information about working with private connectivity endpoints, see the following:

• Manage private connectivity endpoints: AWS

• Manage private connectivity endpoints: Azure

• Manage private connectivity endpoints: Google Cloud