Snowsight Cloud

Last modified on January 17, 2025

This guide explains what capabilities StrongDM can provide for managing access to Snowsight, Snowflake’s administrative user interface. It also provides setup and configuration instructions to add Snowsight as a resource in StrongDM and begin using StrongDM to control access for users who wish to access your Snowsight console. StrongDM users are authenticated with Snowsight and granted the level of access that you configure on the Snowsight side.

In addition to access control and auditing, Snowsight access through StrongDM can be a part of a variety of use cases and access control methodologies:

  • Least Privilege: For Snowsight (Snowflake Web Console) clouds, least privilege can be accomplished by setting up multiple instances of the console as StrongDM resources. Each resource would connect to Snowsight using a different service account with different permissions granted to it.
  • Just-in-Time Access: StrongDM users are able to use any access workflows you set up to request access to Snowsight, allowing you the choice between granting Just-in-Time (JIT) access with requests, or providing standing access to particular users or roles within your StrongDM organization. For more details, see the Access Workflows section.
  • Context-Based Policy: StrongDM policies that restrict or enable users’ ability to connect to Snowsight resources based on their context can be used to limit availability of your Snowsight console to users in particular geographic locations or with good device trust scores. Policies can also be used to provide an MFA challenge prior to connection, and help solve for many more use cases. For more details, see the Policies section.

Limitations

  • For the configuration to work, you must be able to connect to your Snowflake interface via SnowSQL. An admin or web interface does not work.
  • Due to the limitations of this resource type, StrongDM does not log user interactions after authentication occurs. StrongDM logs activities such as setup or modification of the resource within StrongDM, or authentication of a user to the resource, but StrongDM does not log the queries performed by the user on the resource itself. We recommend the use of the Snowsight Activity area for logging further interactions with the resource once a user is authenticated.
  • Similarly, some organization-level behaviors are also different for this resource type:
    • Inactivity timeouts are not enforced.
    • Current connections to resources are not severed instantly when access is revoked.
  • StrongDM must be the only identity provider (IdP) configured for authentication to this resource.

Prerequisites

  • In StrongDM, you must have the Admin permission level.
  • You must have administrator access to your Snowsight environment.
  • Before enabling this resource, ensure the Login Name for each Snowflake user (that is, not Username or Email) is set to match a StrongDM email. An email address serves as the ID StrongDM sends to Snowflake to log in a user. The following process disables identity provider (IdP) logins via any other method. Password logins still work.
  • We recommend that you reach out to Snowflake support and request that users are not allowed to change their own passwords. Otherwise, once a user logs in to Snowflake via StrongDM, they may change their password and retain access to Snowflake even after their access is revoked in StrongDM.

Configuration

Get StrongDM’s IdP metadata

StrongDM’s IdP metadata is required for creating an integration account with Snowsight.

  1. Go to app.strongdm.com/saml/idp_metadata. This is a public URL that returns a XML blob. Within this output, note the value of the X509Certificate. The value is present twice. Both instances should have the same value.
  2. Copy the certificate value. You will need it to create a StrongDM integration account.

Create a StrongDM integration account

This integration account sets StrongDM information, including the IdP certificate.

  1. Note your Snowflake account identifier, which identifies your Snowflake account within your organization, Snowflake-supported cloud platforms, and cloud regions. The account identifier may consist of your Snowflake organization name and account name, in the format <ORGANIZATION_NAME>-<ACCOUNT_NAME> (for example, myorg-account123). Alternatively, the account identifier may consist of your account locator, region ID, and cloud, and be in the format <ACCOUNT_LOCATOR>.<CLOUD_REGION_ID>.<CLOUD> (for example, xy12345.us-east-2.aws). The account identifier makes up part of your Snowflake base URL (for example, https://myorg-account123.snowflakecomputing.com or https://xy12345.us-east-2.aws.snowflakecomputing.com).

  2. In SnowSQL, execute the following command, being sure to replace the placeholders with your own values.

    create security integration strongdm_idp
      type = saml2
      enabled = true
      saml2_issuer = 'https://app.strongdm.com/saml/idp_metadata'
      saml2_sso_url = '<ANY_STRING_IN_URL_FORMAT>'
      saml2_provider = 'Custom'
      saml2_x509_cert='<STRONGDM_IDP_X509_CERTIFICATE>'
      saml2_sp_initiated_login_page_label = '<ANY_STRING>'
      saml2_enable_sp_initiated = true
      saml2_force_authn = false
      saml2_requested_nameid_format = 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified'
      saml2_snowflake_issuer_url = 'https://<ACCOUNT_IDENTIFIER>.snowflakecomputing.com'
      saml2_snowflake_acs_url = 'https://<ACCOUNT_IDENTIFIER>.snowflakecomputing.com/fed/login';
    

3. Ensure that the metadata matches your base URL (for example, https://<ACCOUNT_IDENTIFIER>.snowflakecomputing.com). If you run into 403 errors when adding Snowsight as a cloud resource, it is likely because the wrong URLs were set. If the URLs are wrong, Snowflake could generate metadata with an incorrect URL.

Get the Snowsight metadata XML blob

The Snowsight metadata XML blob allows connection to StrongDM.

  1. Run desc security integration strongdm_idp; in SnowSQL.
  2. Copy the SAML2_SNOWFLAKE_METADATA value. You will need it to configure the Snowsight cloud resource.

Admin UI setup

If you prefer to set up your GCP resource in StrongDM using the CLI, skip this step and read CLI setup. If you want to set up Snowsight in the StrongDM Admin UI, go to Resources > Clouds in the Admin UI and click the Add cloud button.

Set the following properties, and then click Create to save the configuration settings.

PropertyRequirementDescription
Display NameRequiredMeaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)
Datasource TypeRequiredSelect Snowsight (Snowflake Web Console)
Secret StoreOptionalCredential store location; defaults to Strong Vault; learn more about Secret Store options
SAML MetadataRequiredMetadata XML blob from your Snowflake IdP integration
Healthcheck UsernameRequiredIn order for healthchecks to be successful, must be the email of a StrongDM user who has access to this resource, and must also match your Snowflake Login Name (that is, not Username or Email)
SubdomainRequiredValue to use for your local DNS address (for example, app-prod1 turns into http://app-prod1.<ORGANIZATION_NAME>.sdm.network/; note that this subdomain should be unique and not used by any other resource)
Resource TagsOptionalDatasource tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev)

CLI setup

If you would rather set up Snowsight using the CLI, open your terminal. While logged in to StrongDM, use the following command:

sdm admin clouds add snowsight

You can view all help text and options by appending --help or -h to the same command:

NAME:
   sdm admin clouds add snowsight - create Snowsight (Snowflake Web Console) cloud

USAGE:
   sdm admin clouds add snowsight [command options] <name>

OPTIONS:
   --bind-interface value        bind interface (default: "127.0.0.1")
   --egress-filter value         apply filter to select egress nodes e.g. 'field:name tag:key=value ...'
   --healthcheck_username value  The StrongDM user email to use for healthchecks (required)
   --port-override value         port profile override (default: -1)
   --saml-metadata value         The Metadata for your snowflake IDP integration (required, secret)
   --secret-store-id value       secret store id
   --subdomain value             (required)
   --tags value                  tags e.g. 'key=value,...'
   --template, -t                display a JSON template
   --timeout value               set time limit for command
   --tls-required                sdm must use TLS to connect

Logs

In the Cloud logs section of the Admin UI (Logs > Cloud), you can find all of the activities of the users who accessed the Snowsight resource. Note that StrongDM makes an attempt to drop the Authorization header of logs for display in the Admin UI. Note that any secrets displayed in the cloud logs are placeholder values. No actual keys or secrets are ever exposed in plaintext in the Admin UI.

CLI Usage

When the resource is created and configured, you are ready for users to connect to the resource. In order for your organization’s users to access the Snowsight cloud resource via StrongDM, users need to install the following:

  • The StrongDM Desktop application
  • The latest version of the StrongDM CLI. If the CLI is already installed, you can run sdm update in the CLI to update it. Alternatively, if any updates are available, you can open the desktop app and click the Upgrade button.
  • The snow command-line tool

After installation, users must exit and restart the desktop app, and then select the Snowsight cloud resource to connect to.

Click to connect to the resource in the desktop app, or run sdm connect <RESOURCE> in the CLI.

Top