Egress

Snowpark Container Services (SPCS) blocks all outbound network traffic from a service unless an external access integration allows it. Each integration references one or more network rules, and each network rule lists the hosts and ports the service can reach.

The Posit Team Native App cannot create these objects itself. It declares three external access integration references, one each for Posit Workbench, Posit Connect, and Posit Package Manager. When you accept the references during installation, Snowsight creates one network rule and one external access integration per product in your account.

The suggested values allow open egress to 0.0.0.0:443 and 0.0.0.0:80 so that the first install succeeds. You own these objects and can tighten them at any time. If you cannot allow open egress even during installation, see Install without open egress.

Warning

Restricting egress is easy to get wrong. A missing endpoint rarely produces a clear error: packages fail to install, extensions do not load, or sign-in hangs. Change one rule at a time, and test each product after every change.

Editing network rules and external access integrations requires the ACCOUNTADMIN role, or a role that owns the objects.

Endpoints

Each product page lists the endpoints it needs. Some endpoints depend on whether Restricted Caller’s Rights (RCR) is enabled and whether Package Manager runs in your Posit Team Native App:

Posit product licensing, telemetry, and the Posit Team controller need no egress.

Find your network rules and external access integrations

The architecture page lists the generated object names and shows how each service reaches its integration and rule through a reference. Examples on this page use an application installed as POSIT_TEAM. Substitute your application name in every example.

Using SQL

Each application reference records the integration bound to it. List the references to find the exact integration names. Then describe each integration to find its network rules, and describe each network rule to see its endpoints:

Snowsight UI
-- The object_name column names the external access integration bound to each reference
SHOW REFERENCES IN APPLICATION POSIT_TEAM;

-- Or search by name
SHOW EXTERNAL ACCESS INTEGRATIONS LIKE '%POSIT_TEAM%';

-- The ALLOWED_NETWORK_RULES property lists the fully qualified network rules
DESCRIBE EXTERNAL ACCESS INTEGRATION POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS;

-- List the network rules in the application schema. The entries_in_valuelist column counts endpoints but does not show them
SHOW NETWORK RULES IN SCHEMA POSIT_TEAM_APP_DATA.CONFIGURATION;

-- The value_list property lists the allowed endpoints
DESCRIBE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_WORKBENCH_EGRESS_NETWORK_RULE;

SHOW REFERENCES requires ownership of the application. The other statements require ownership of the integration or network rule.

Using Snowsight

Visit Governance & security > Network policies > Network Rules and search for your application name. Open a rule to view and edit its endpoints in place. The Snowflake guide to network rules covers the same steps.

The Snowsight Governance & security Network Rules page showing the Posit Team egress network rules available for editing.

Network rule edit

Allow a new endpoint

To let a product reach a new host:port, first decide where the host is:

Where the host is What to do Rule type
On the public internet Add the host:port to the product’s network rule. See Change a network rule. HOST_PORT
In your VPC or VNet, in the same cloud provider and region as your Snowflake account Provision a private endpoint and create a private rule for the hostname. See Private connectivity. PRIVATE_HOST_PORT
Only on your corporate network Make the resource available in your cloud account, then follow the VPC or VNet row. See Reach a resource on your corporate network. PRIVATE_HOST_PORT
Your Snowflake account Enable Restricted Caller’s Rights instead of adding a rule. None

Both rule types end with the same steps: change the rule or add a rule to the external access integration of each product that needs the endpoint. Posit Team cannot mount shared file systems. See Can Posit Team mount a shared file system?.

Change a network rule

Use ALTER NETWORK RULE to replace the endpoints of an existing rule, or edit the rule in Snowsight as described in Modifying a network rule. Each value is a host:port pair. A host without a port allows every port. A * matches one label of a hostname, so *.vscode-resource.vscode-cdn.net:443 allows any direct subdomain.

Snowsight UI
-- View the current endpoints first
DESCRIBE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_CONNECT_EGRESS_NETWORK_RULE;

-- Replace the list. Include every endpoint you want to keep
ALTER NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_CONNECT_EGRESS_NETWORK_RULE
  SET VALUE_LIST = (
    '<org>-<account>.snowflakecomputing.com:443',
    'github.com:443',
    'smtp.example.com:587');
Important

SET VALUE_LIST is not additive. Snowflake removes every endpoint that is not in the new list. Always describe the rule first and copy the endpoints you want to keep.

Change one rule at a time and wait two to three minutes for each change to take effect. Make changes only after a successful installation, and test the affected product after each change. To test from inside the application, open a terminal in a Workbench session and request the endpoint:

Terminal
curl --head https://github.com

SPCS enforces network rules at DNS resolution. A blocked host fails with a name resolution error rather than a timeout.

You cannot change the TYPE or MODE of a network rule. To route traffic through private endpoints, create a separate PRIVATE_HOST_PORT rule and add it to the integration.

Add a network rule to an external access integration

An external access integration can allow more than one network rule. For how the two objects fit together, see External network access overview and Creating and using an external access integration in the Snowflake docs. Add a rule instead of editing the generated one in the following cases:

  • You need a PRIVATE_HOST_PORT rule for a resource reached over private connectivity. A private rule allows one domain, and you cannot mix it with HOST_PORT values.
  • Your organization maintains its own network rules and wants the same rule attached to several products.
  • You want to keep the generated rule as a record of the install defaults.

Create the rule in a database and schema your organization controls. The application database POSIT_TEAM_APP_DATA is a common choice because Snowflake removes it with the application:

Snowsight UI
CREATE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_GIT_EGRESS
  TYPE = HOST_PORT
  MODE = EGRESS
  VALUE_LIST = ('github.com:443', 'gitlab.example.com:443');

Then set the full list of allowed rules on the integration with ALTER EXTERNAL ACCESS INTEGRATION:

Snowsight UI
-- Note the rules in ALLOWED_NETWORK_RULES
DESCRIBE EXTERNAL ACCESS INTEGRATION POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS;

ALTER EXTERNAL ACCESS INTEGRATION POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS
  SET ALLOWED_NETWORK_RULES = (
    POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_WORKBENCH_EGRESS_NETWORK_RULE,
    POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_GIT_EGRESS)
  ENABLED = TRUE;
Important

SET ALLOWED_NETWORK_RULES replaces the previous list. Include the generated network rule unless you intend to remove it. To detach a rule, run the same statement without it.

Repeat the ALTER EXTERNAL ACCESS INTEGRATION statement for each product that needs the rule. Changes to integrations and rules apply without restarting Posit Team.

Private connectivity

Outbound private connectivity routes egress through a private endpoint in your cloud account instead of the public internet. It requires the Business Critical edition or higher, and the endpoint must be in the same cloud provider and region as your Snowflake account. Use it when Workbench, Connect, or Package Manager must reach a resource that is only available inside your VPC or VNet, for example:

  • An internal API that only answers requests from inside your network
  • A database such as PostgreSQL or SQL Server on a private subnet
  • A self-hosted Package Manager, Git server, or artifact repository
  • A model endpoint for Posit Assistant that you host in your cloud account
  • An on-premises system reached from your cloud network over VPN or ExpressRoute

To keep Snowflake traffic private, enable Restricted Caller’s Rights instead of routing it through an endpoint.

The cloud side differs by provider. Snowflake documents the load balancer, endpoint service, and DNS requirements for AWS, Azure, and Google Cloud. This section covers only the Snowflake objects that every private endpoint needs: the endpoint itself, a PRIVATE_HOST_PORT network rule, and the external access integrations.

Reach a resource on your corporate network

Private endpoints connect only to services in your cloud account. To reach a resource that exists only on your corporate network, first make it available in your cloud account. There are many ways to do this, and the right one depends on your network design, security policies, and existing infrastructure. Work with your network team to choose an approach. The following is one common approach, not a recommendation for your environment:

  1. Connect your corporate network to your VPC or VNet. Many organizations already have this connection through a site-to-site VPN, AWS Direct Connect, Azure ExpressRoute, or Google Cloud Interconnect.
  2. Put a load balancer in your VPC or VNet that forwards to the resource across that connection, and expose the load balancer as a private service:
    • AWS: a Network Load Balancer with an IP target group of the corporate addresses, behind a VPC endpoint service
    • Azure: an Application Gateway with Private Link, with the corporate servers in its backend pool
    • Google Cloud: a Private Service Connect service attachment in front of an internal load balancer with a hybrid network endpoint group

Then provision a private endpoint to that service.

Provision a private endpoint

Each hostname you reach privately needs its own endpoint. Provision it with SYSTEM$PROVISION_PRIVATELINK_ENDPOINT as ACCOUNTADMIN, approve the connection in your cloud account, and confirm it reports Available or Approved:

Snowsight UI
-- AWS: the VPC endpoint service name and the hostname to route through it
SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
  'com.amazonaws.vpce.us-west-2.vpce-svc-aaaa',
  'api.internal.example.com');

-- Azure: the Private Link resource ID, the hostname, and the subresource
SELECT SYSTEM$PROVISION_PRIVATELINK_ENDPOINT(
  '/subscriptions/.../privateLinkServices/my-service',
  'api.internal.example.com',
  'Gateway');

-- Check status. This can take several minutes
SELECT SYSTEM$GET_PRIVATELINK_ENDPOINTS_INFO();

Snowflake limits the number of private endpoints per account, and a deprovisioned endpoint counts against the limit for seven days. For the arguments, approval steps, and how to deprovision or restore an endpoint, see the Snowflake guides for AWS, Azure, and Google Cloud.

Create a private host port rule

A PRIVATE_HOST_PORT rule tells Snowflake to send traffic for a hostname through the private endpoint provisioned for it. The rule accepts one hostname, with an optional port that defaults to 443, and MODE must be EGRESS. A network rule has one type, so keep private hosts out of the generated HOST_PORT rules.

Snowsight UI
-- An internal API
CREATE NETWORK RULE POSIT_TEAM_APP_DATA.DATA.POSIT_TEAM_PRIVATE_API
  MODE = EGRESS
  TYPE = PRIVATE_HOST_PORT
  VALUE_LIST = ('api.internal.example.com:443');

-- A database, with its port
CREATE NETWORK RULE POSIT_TEAM_APP_DATA.DATA.POSIT_TEAM_PRIVATE_DB
  MODE = EGRESS
  TYPE = PRIVATE_HOST_PORT
  VALUE_LIST = ('db.internal.example.com:5432');

Add the rule to the external access integrations

Add the private rule to the integration of each product that connects to the resource, keeping the generated rule in the list.

Snowsight UI
ALTER EXTERNAL ACCESS INTEGRATION POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS
  SET ALLOWED_NETWORK_RULES = (
    POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_WORKBENCH_EGRESS_NETWORK_RULE,
    POSIT_TEAM_APP_DATA.DATA.POSIT_TEAM_PRIVATE_API,
    POSIT_TEAM_APP_DATA.DATA.POSIT_TEAM_PRIVATE_DB)
  ENABLED = TRUE;

Test from a Workbench session terminal with curl --head https://api.internal.example.com.

Install without open egress

The Snowsight configuration page requires you to accept an external access integration for each product before you can activate the application. The suggested network rules allow open egress to 0.0.0.0:443 and 0.0.0.0:80. If your organization does not allow open egress even temporarily, skip the configuration page and bind the integrations with SQL instead. Use the ACCOUNTADMIN role, or the role that installed the application.

  1. Install the application from the Marketplace with Get, but do not continue through Configure.

  2. Create a network rule and an external access integration for each product with the endpoints you allow. This example gives Workbench the Snowflake account endpoint and the hosts for Positron and VS Code extensions, Connect the account endpoint, and Package Manager the sync endpoint:

    Snowsight UI
    CREATE DATABASE IF NOT EXISTS POSIT_TEAM_APP_DATA;
CREATE SCHEMA IF NOT EXISTS POSIT_TEAM_APP_DATA.CONFIGURATION;

CREATE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_WORKBENCH_EGRESS_NETWORK_RULE
  TYPE = HOST_PORT
  MODE = EGRESS
  VALUE_LIST = ('<org>-<account>.snowflakecomputing.com:443', '*.vscode-resource.vscode-cdn.net:443');

CREATE EXTERNAL ACCESS INTEGRATION POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS
  ALLOWED_NETWORK_RULES = (POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_WORKBENCH_EGRESS_NETWORK_RULE)
  ENABLED = TRUE;

CREATE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_CONNECT_EGRESS_NETWORK_RULE
  TYPE = HOST_PORT
  MODE = EGRESS
  VALUE_LIST = ('<org>-<account>.snowflakecomputing.com:443');

CREATE EXTERNAL ACCESS INTEGRATION POSIT_TEAM_CONNECT_EGRESS_EXTERNAL_ACCESS
  ALLOWED_NETWORK_RULES = (POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_CONNECT_EGRESS_NETWORK_RULE)
  ENABLED = TRUE;

CREATE NETWORK RULE POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_PACKAGE_MANAGER_EGRESS_NETWORK_RULE
  TYPE = HOST_PORT
  MODE = EGRESS
  VALUE_LIST = ('rspm-sync.rstudio.com:443');

CREATE EXTERNAL ACCESS INTEGRATION POSIT_TEAM_PACKAGE_MANAGER_EGRESS_EXTERNAL_ACCESS
  ALLOWED_NETWORK_RULES = (POSIT_TEAM_APP_DATA.CONFIGURATION.POSIT_TEAM_PACKAGE_MANAGER_EGRESS_NETWORK_RULE)
  ENABLED = TRUE;

  3. Bind each integration to the matching application reference. SYSTEM$REFERENCE creates the reference, and the application exposes a register_reference procedure that records it:

    Snowsight UI
    CALL POSIT_TEAM.callback.register_reference('WORKBENCH_EGRESS', 'ADD',
  SYSTEM$REFERENCE('EXTERNAL ACCESS INTEGRATION', 'POSIT_TEAM_WORKBENCH_EGRESS_EXTERNAL_ACCESS', 'PERSISTENT', 'USAGE'));
CALL POSIT_TEAM.callback.register_reference('CONNECT_EGRESS', 'ADD',
  SYSTEM$REFERENCE('EXTERNAL ACCESS INTEGRATION', 'POSIT_TEAM_CONNECT_EGRESS_EXTERNAL_ACCESS', 'PERSISTENT', 'USAGE'));
CALL POSIT_TEAM.callback.register_reference('PACKAGE_MANAGER_EGRESS', 'ADD',
  SYSTEM$REFERENCE('EXTERNAL ACCESS INTEGRATION', 'POSIT_TEAM_PACKAGE_MANAGER_EGRESS_EXTERNAL_ACCESS', 'PERSISTENT', 'USAGE'));

  4. Grant the account privileges that the configuration page grants, then notify the application. The grant_privileges procedure creates the compute pool and warehouse and starts the application:

    Snowsight UI
    GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO APPLICATION POSIT_TEAM;
GRANT CREATE COMPUTE POOL ON ACCOUNT TO APPLICATION POSIT_TEAM;
GRANT CREATE WAREHOUSE ON ACCOUNT TO APPLICATION POSIT_TEAM;

CALL POSIT_TEAM.callback.grant_privileges(
  ARRAY_CONSTRUCT('BIND SERVICE ENDPOINT', 'CREATE COMPUTE POOL', 'CREATE WAREHOUSE'));

  5. Confirm that SHOW REFERENCES lists an integration for each reference, then open the application from Catalog > Apps and continue with the landing page:

    Snowsight UI
    SHOW REFERENCES IN APPLICATION POSIT_TEAM;

The example uses the same object names Snowsight generates, so the rest of this page applies without changes. To change the endpoints later, change the network rule. To replace an integration, run register_reference with 'REMOVE' and the old reference, then 'ADD' with the new one.

Reduce egress

Use this section to restrict egress after the initial installation, or whenever you want to tighten the rules. The suggested install rules allow open egress so that the first installation succeeds. Each product page lists the required and optional endpoints for your configuration: Workbench, Connect, and Package Manager.

Install with the suggested open egress and confirm that each product works before you reduce egress. If your security policy does not allow open egress even during installation, see Install without open egress. Then reduce egress in this order, testing after each step:

  1. Run Package Manager in the application: Set up Package Manager so Workbench and Connect install packages and extensions from it over the internal network. This removes p3m.dev, packagemanager.posit.co, and rspm-sync.rstudio.com from the Workbench and Connect rules. Package Manager still needs rspm-sync.rstudio.com:443.

  2. Enable Restricted Caller’s Rights: RCR keeps Snowflake traffic on the Snowflake network and removes the account endpoint. See Restricted Caller’s Rights below.

  3. Remove open egress: Replace 0.0.0.0:443 and 0.0.0.0:80 with the specific endpoints listed on the product pages. See Remove open egress below.

  4. Use private connectivity for your own resources: Reach databases and internal APIs in your VPC or VNet through private endpoints instead of exposing them to the public internet.

Restricted Caller’s Rights

With RCR enabled, Snowflake queries no longer leave the Snowflake network. Remove the following from the Workbench and Connect network rules:

  • <org>-<account>.snowflakecomputing.com:443 in HOST_PORT rules
  • <org>-<account>.privatelink.snowflakecomputing.com:443 in PRIVATE_HOST_PORT rules

RCR does not change Package Manager egress. Package Manager still needs rspm-sync.rstudio.com:443.

With RCR and Package Manager in the application, Connect needs no egress and Workbench needs only *.vscode-resource.vscode-cdn.net:443.

Note

Public traffic does not use *.vscode-resource.vscode-cdn.net. Restrictive Snowflake content security policy rules prevent VS Code service workers from running without it. You can omit it, but the Posit Publisher, Snowflake, and Posit Assistant extensions do not work.

Remove open egress

Large query results download from the internal stage of your account, a Snowflake-managed host that differs by account. Snowflake lists it for you:

Snowsight UI
-- Accounts using public connectivity
SELECT SYSTEM$ALLOWLIST();

-- Accounts using AWS PrivateLink or Azure Private Link
SELECT SYSTEM$ALLOWLIST_PRIVATELINK();

Add the entries with "type":"STAGE" to the Workbench and Connect network rules, and *.vscode-resource.vscode-cdn.net:443 to the Workbench rule. With Restricted Caller’s Rights enabled, Workbench and Connect do not need the stage hosts. For details on the output, see SYSTEM$ALLOWLIST() and SYSTEM$ALLOWLIST_PRIVATELINK().

Then change each network rule to drop 0.0.0.0:443 and 0.0.0.0:80.

Troubleshooting

Restrictive egress rules cause failures that are hard to attribute. The following symptoms are common:

  • Package or extension installs fail with a name resolution error, or pip, R, and Positron report that they cannot reach a host.
  • Snowflake authentication fails with HTTP 403, or managed credentials never finish the OAuth flow.
  • The Workbench or Connect UI shows Cross-Origin Resource Sharing (CORS) errors or hangs.
  • Connect fails to build Git-backed content or send email.

Follow these steps to find the cause:

  1. Check the network.egress.denied.packets metric in telemetry. A rising count means a network rule is blocking traffic.
  2. Describe the network rules and integrations as shown in Find your network rules, and compare the endpoints with the list on the product page for your configuration.
  3. Test the endpoint from a Workbench session terminal with curl --head. A DNS failure means the host is missing from the rule. A timeout usually means Snowflake blocks the port, as with SMTP ports.
  4. If you use an account-level network policy, follow Network policies in addition to the egress rules on this page.

If problems persist after you add the endpoint, restore the open egress defaults, confirm the product works, and reintroduce restrictions one at a time. For help, see Troubleshooting.

Back to top