Security

Workbench | Advanced

Ingress Traffic

The Snowflake Workbench Native App is accessible via a secured subdomain controlled by Snowflake (which should look like https://.....snowflakecomputing.com). Access is controlled via Snowflake SPCS Ingress. All normal Snowflake authentication procedures for your account are enforced on the Snowflake side to gain access to Workbench, including organizational SSO requirements. See the section Grant access to Posit Workbench for information on allowing specific roles ingress access.

Egress Traffic

Egress from the Posit Workbench Native App is controlled via network rules. Detailed documentation on network egress can be found at the Snowflake Network Rules docs. See changing the egress policy for more information on restricting egress traffic. The Workbench application does not reach out to any domains other than Snowflake in order to perform Authentication and Database driver calls. Users of Workbench, however, can arbitrarily call external URLs, so administrators are encouraged to restrict egress access.

Grant access to Posit Workbench

The Posit Workbench Native App has two application roles which are similar to account roles but scoped to the application. Refer to the Snowflake roles documentation for a detailed explanation.

Role Purpose
WORKBENCH_USER Can access Workbench and view the status of the service.
WORKBENCH_ADMIN Grants access to many stored procedures and the Administer Workbench dashboard. Also grants all permissions that the WORKBENCH_USER has.
We recommend granting this application role sparingly. A user with this role is able to stop, and disturb, the functionality of Workbench.

You can manage access through the Snowsight UI or by using SQL. Replace the placeholder role names in the example below with the names of the desired roles in your Snowflake account.

GRANT APPLICATION ROLE posit_workbench.workbench_user to ROLE my_user_role;
GRANT APPLICATION ROLE posit_workbench.workbench_admin to ROLE my_admin_role;

To grant access through the UI, click Manage Access in the top navigation bar.

Select a role and grant the desired application role(s).

Manage Access to the Native App

 

Grant Access to specific roles

Changing the egress policy

Modifying the default egress policy for Workbench involves writing your own SQL, which can be tricky to get correct. At a minimum you must allow access to Snowflake query and authentication endpoints.

The process to follow is the Snowflake guide on creating network rules and external access integrations.

You can change the name of the network rule and external access integration in the example below. This example also requires that the SNOWFLAKE_HOST environment variable be set within the running SPCS container. Workbench fails to start if this is not set to the appropriate URL.

-- Create a schema to store rules for Workbench access
CREATE SCHEMA IF NOT EXISTS posit_workbench_app_data.rules;

-- Create network rule
CREATE OR REPLACE NETWORK RULE posit_workbench_app_data.rules.MY_CUSTOM_RULE
    TYPE = 'HOST_PORT'
    MODE = 'EGRESS'
    COMMENT = 'Allow all outbound access and Snowflake OCSP caching'
    VALUE_LIST = (
        '0.0.0.0:443',
        'ocsp.snowflakecomputing.com:80'
    );
-- Apply the network rules to the external access integration
CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION posit_workbench_custom_egress
    COMMENT = 'Apply custom network rules to Workbench egress'
    ALLOWED_NETWORK_RULES = (
        posit_workbench_app_data.rules.MY_CUSTOM_RULE
    )
    ENABLED = true;

-- Clear existing reference
CALL POSIT_WORKBENCH.CALLBACK.REGISTER_REFERENCE('EGRESS', 'CLEAR', '');
-- Add the new egress policy
CALL POSIT_WORKBENCH.CALLBACK.REGISTER_REFERENCE('EGRESS', 'ADD',
    SYSTEM$REFERENCE(
        'EXTERNAL ACCESS INTEGRATION',
        'posit_workbench_custom_egress',
        'PERSISTENT',
        'USAGE'
    ));
Note

The Snowflake documentation on OCSP states that it requires port 80 for OCSP caching.

We have not had success narrowing down the 443 port access to specific Snowflake domains as detailed in their guides. This will be updated when we find a working solution.

Running these queries causes Workbench to restart. The restart should complete within two to three minutes.

Consult the Workbench logs if you encounter issues with egress. The most common signs of issues with your egress policy are request timeouts and 403 errors when connecting to, or using, Workbench. The Snowflake egress policy network rules drop packets, instead of rejecting them, which results in requests hanging from the perspective of the user.

It is strongly suggested administrators modify the egress rules after a successful installation, and we recommend adminstrators only change one rule at a time, allowing two to three minutes for each rule to take effect.

call posit_workbench.app.workbench_logs();
call posit_workbench.app.workbench_state();

Root access within the Workbench Native App

Root access within the Workbench is explicitly disabled. No users within the Native App have sudo access. This allows us to ensure the reliability of Workbench, protects users from seeing other user’s files, and prevents users from using other user’s managed OAuth credentials.

Back to top