Cyral
Get Started Sign In

Integration Guide: Protecting Snowflake with Cyral + G Suite

Contents



Notes for new Snowflake sidecar deployments

Create a TLS certificate for the sidecar

Add CNAME records for sidecar subdomains

Deploy the Cyral sidecar

Add a CNAME record for the sidecar domain

Track your data repository and enable logging

Configure SSO authentication in G Suite for Snowflake repos

Cyral Sidecar Configuration for SSO

Configure Snowflake for SAML

Connect to a Snowflake data repository through the sidecar



Notes for new Snowflake sidecar deployments

Deploy your sidecar in the same AWS region as Snowflake

Cyral recommends deploying your sidecar for Snowflake in the same AWS region as your Snowflake repository. Deployment in a separate region may affect how long it takes a user to log into the Snowflake console the first time through Cyral. With the sidecar running in a different region than Snowflake, rendering the console incurs a cross-region network trip that makes the process seem slower.

Use a separate sidecar for Snowflake

If you have a production sidecar already protecting existing non-Snowflake repositories, then, to add protection for your Snowflake repositories, Cyral recommends deploying a separate sidecar dedicated to your Snowflake repositories.

Overview of deployment steps

A sidecar that will protect a Snowflake repository requires some additional deployment steps. At a high level, the deployment steps are shown below. For customers using popular deployment frameworks such as Cloudformation, your Cyral support rep might have a template (for example cft_snowflake_sidecar_resources.yaml) that can help automate Steps 1 through 4 below.

  1. Choose a name for your sidecar domain. This is the base URL where your database users will connect to Snowflake through the sidecar.

  2. Generate a TLS certificate for your sidecar domain.

  3. Wait for the TLS certificate to pass AWS validation.

  4. Create the sub-domain CNAME records using your sidecar domain.

  5. Deploy the sidecar, passing the certificate’s ARN as a param.

  6. Create one CNAME record mapping their chosen sidecar domain to the sidecar load balancer address.

Note! See the section below, "Cyral Sidecar Configuration for SSO" for important SSO-related settings.

Create a TLS certificate for the sidecar

Note! This step is only needed if your sidecar protects Snowflake repositories.

Because HTTPS is essential when accessing Snowflake, you’ll need to provide the sidecar with a TLS certificate that covers the sidecar domain and all relevant sub-domains.

You'll create the certificate in the same AWS account and region where you deploy the sidecar.

Prerequisite

Decide on a sidecar domain name. This is the domain your database users will use in the URL to connect to Snowflake. In the examples below, we'll use snowflake.example.com.

Procedure

  1. In your AWS console, navigate to AWS Certificate Manager.

  2. Click Request a Certificate and choose Request a public certificate.

  3. Add all needed domain names to the certificate request. These domains should cover all AWS regions (using subdomain prefixes like s3-us-east-1) where your Snowflake deployment runs. Assuming a sidecar domain of snowflake.example.com running on AWS in the US, the full set of domains that must be covered by the TLS certificate would be:
    snowflake.example.com
    *.snowflake.example.com
    *.s3-us-east-1.snowflake.example.com
    *.s3-us-west-1.snowflake.example.com
    *.s3-us-east-2.snowflake.example.com
    *.s3-us-west-2.snowflake.example.com
    *.s3.snowflake.example.com

  4. Have AWS validate the certificate. For fastest validation, Cyral recommends that you choose DNS validation as the validation type.

Note! DNS validation should only be required on an AWS account level, meaning that creating the same certificate in different regions on the same AWS account should not require additional CNAME DNS validation records to be created.

  1. Complete the request and wait for the TLS certificate to pass AWS validation. This may take a few hours, as explained in the AWS documentation.

  2. Once the certificate is validated, make a note of its ARN (Amazon Resource Name). When you deploy the sidecar, the deployment template will accept the certificate's ARN as the following deployment parameter: LoadBalancerCertificateArn.

Next steps

Add CNAME records for sidecar subdomains.


Add CNAME records for sidecar subdomains

Note! This step is only needed if your sidecar protects Snowflake repositories.

The Snowflake UI makes several requests directly to your Snowflake account’s underlying S3 bucket (for AWS deployments). In order for your data to be completely protected by the Cyral Sidecar, it’s critical that the sidecar proxies these requests to S3. Below, you'll define CNAME records to ensure that the sidecar captures all relevant requests made by the Snowflake UI running in users' browsers.

DNS Setup

The Cyral sidecar for Snowflake requires several CNAME records to be created that correspond to subdomains of your chosen sidecar domain. After you deploy the sidecar, these subdomains will all resolve to the sidecar’s load balancer’s public domain name.

For ease of management, Cyral recommends that these subdomain CNAME records map to the sidecar domain. With this setup, you’ll only need to change one CNAME record to move your sidecar domain to a different sidecar.

Below is a list of the CNAME records for subdomains that need to be created for a given sidecar domain, assuming a deployment on AWS in the US with a sidecar domain of snowflake.example.com.

*.snowflake.example.com -> snowflake.example.com
*.s3-us-east-1.snowflake.example.com -> snowflake.example.com
*.s3-us-west-1.snowflake.example.com -> snowflake.example.com
*.s3-us-east-2.snowflake.example.com -> snowflake.example.com
*.s3-us-west-2.snowflake.example.com -> snowflake.example.com
*.s3.snowflake.example.com -> snowflake.example.com

Note: After you deploy the sidecar, you will create one more CNAME record that maps to your chosen sidecar domain (for example, snowflake.example.com -> sidecar load balancer domain name.)

Next steps

Deploy the sidecar as explained in the next section.

Deploy the Cyral sidecar


To add a sidecar using the Cyral management console, navigate to the Sidecar tab and select Create New Sidecar and follow the instructions titled Deploying sidecar to AWS EC2 using Terraform.

Note: In the Generate a file screen, when generating the sidecar Terraform template, please choose from the integrations you previously configured for log location and metrics location.

Click Generate template.

After you generate the template, you can edit it to make the customizations you need. These customizations may include:

  • In all Snowflake deployments the sidecar must have a TLS certificate that's validated for the domains where your Snowflake and sidecar instances run. (See the earlier section, "Create a TLS certificate for the sidecar" for the steps to create the certificate.) Edit your deployment template, specifying the ARN (Amazon Resource Name) of the certificate in the following deployment parameter: LoadBalancerCertificateArn.

  • Network access control for the sidecar instance: There are two ways to customize network access to a sidecar: (1) through the security group you deploy along with the sidecar or (2) by attaching other security groups directly to a sidecar instance in EC2.

    • To use option (1), you have a choice: limit network access based on CIDR addresses or limit network access based on security groups. To limit based on CIDR, use the parameters db_inbound_cidr and ssh_inbound_cidr. To limit based on security groups, use the parameters db_inbound_security_group and ssh_inbound_security_group to attach existing security groups to the security group that will be created and associated to the sidecar. Note that you must choose either CIDRs or security groups to limit access; you can’t combine them.

    • To use option (2), you can associate existing security groups directly with an EC2 instance through the parameter additional_security_groups.

      Option (1) allows the user to define access controls on the sidecar that will be restricted to those database or SSH ports allowed to connect to the sidecar. Option (2) is less restrictive and allows you to control all ports that offer access to the sidecar, as these will be defined by the existing security groups attached directly to the sidecar instance.

Use the completed template to deploy the sidecar.

Once your sidecar has been deployed, the Cyral management console lists it in the Sidecar tab. Here, we've created a sidecar named sidecar01.

Note: In the template, the access key and registry key variables are assigned automatically by the Cyral template generator. Cyral uses these key values to access the Cyral control plane and Cyral container registry, respectively. These values are private keys, so you should not upload them to any source control or non-private storage.

Add a CNAME record for the sidecar domain

Note! This step is only needed if your sidecar protects Snowflake repositories.

Now that you have deployed the sidecar, you must create one more CNAME record that maps to your chosen sidecar domain.

To connect to Snowflake repositories through the Cyral sidecar, database users will navigate to the sidecar domain (in this example, snowflake.example.com). To support this, your sidecar's domain must have a corresponding CNAME record that maps it to the public domain name of the sidecar’s load balancer.

DNS Setup

  1. Wait for the sidecar to deploy in order to get the sidecar load balancer's domain name for the CNAME record.

  2. In your DNS service, add a CNAME record mapping your chosen sidecar domain to the sidecar load balancer domain name. For example:

snowflake.example.com -> sidecar load balancer domain name

Track your data repository and enable logging

Follow the instructions in the Cyral documentation to:

  1. Track your data repository by telling Cyral how to connect to it.

  2. Assign your data repository to the sidecar so that it can listen for incoming connections to the repository.

  3. Set up and enable logging.


Configure SSO authentication in G Suite for Snowflake repos


Follow the steps below to enable Cyral to authenticate Snowflake database users using G Suite SSO.

About Cyral SSO for Snowflake repos

Cyral can provide SSO for your users connecting to Snowflake. When configured to protect a Snowflake endpoint, the sidecar will have its own domain, like, for example, snowflake.example.com, that users and applications can use to access their Snowflake data through the sidecar.

Users accessing your Snowflake data warehouse through a browser will navigate to the sidecar’s domain instead of the usual *.snowflakecomputing.com domain. The sidecar proxies Snowflake’s web interface.

Snowflake uses the SAML 2.0 protocol to establish a relationship between identity providers and your Snowflake account. To learn more about federated authentication in Snowflake, see Snowflake's documentation

Below, we provide details on how to configure G Suite, Snowflake, and your Cyral Sidecar for using G Suite to authenticate with Snowflake through the sidecar. The Cyral Sidecar supports the IdP-initiated (identity provider-initiated) login flow as well as the SP-initiated (service provider-initiated) login flow. This means the user experience of using G Suite to authenticate with Snowflake through the *.snowflakecomputing.com domain is identical to the experience of using G Suite to authenticate with Snowflake through the sidecar’s domain.

Note that this solution cannot support using G Suite as an identity provider to access Snowflake directly because, at the account level, Snowflake only allows one identity provider to be enabled at a given time, and this solution requires partially configuring the account’s identity provider to be the Cyral sidecar.  If Snowflake adds support for multiple identity providers at the account level, then we can revise this solution so it supports using G Suite as an identity provider in the directaccess case as well as the sidecar access case.

At a high level, this solution involves daisy chaining SAML identity providers/service providers.  The sidecar will sit between G Suite and Snowflake in the SAML flows.  It will act as the SAML SP (SAML service provider) to G Suite and the SAML IdP (SAML identity provider) to Snowflake.

Create the SAML app to support access to Snowflake via sidecar

Tip: You can reference Snowflake’s documentation on configuring G Suite as an identity provider for more details on this configuration.


First, create the SAML app for accessing Snowflake through the Cyral sidecar:

  1. From the G Suite Admin Console, go to Apps then click on SAML apps.  Click the + button in the bottom right to create a new SAML app. In the popup window, click SETUP MY OWN CUSTOM APP.

  2. Download the certificate and the IDP Metadata so you can reference it later. The SSO URL and Entity ID are in the IDP metadata xml file.


  3. After downloading the metadata, click NEXT. You can choose whatever Application Name you want and add a Description, then click NEXT. We’ll name this Snowflake.

  4. Here you specify the ACS URL and Entity ID. Since we’re configuring this app for the sidecar access case, the ACS URL must be of the form https://<sidecar_domain>/fed/login and the Entity ID must be of the form https://<sidecar_domain>.

  5. There is no need to add any attribute mappings. Click NEXT, then Click FINISH. Note that the SAML app you just created will be Off for everyone. So, you can enable it for everyone, or for a subset of your G Suite users.


Cyral Sidecar Configuration for SSO

Parameters

When deploying the sidecar, you’ll need to provide the following deployment parameters.

Parameter Name

Description

Default

SidecarDNSName

The domain used to access Snowflake through the sidecar

N/A

IdPSSOLoginURL

The G Suite SSO URL

N/A

IdPCertificate

The G Suite public certificate used to verify signatures on G Suite SAML Assertions

N/A

SidecarPublicIdPCertificate

The public certificate used to signatures on Cyral SAML Assertions

N/A

SidecarPrivateIdPKey

The private key used to sign Cyral SAML Assertions

N/A


The process of deploying or re-deploying your sidecar with these parameters will look different depending on how you deploy your sidecars.

After the G Suite SAML app, Snowflake account identity provider, and sidecar are configured, you’ll be able to sign in to Snowflake using your G Suite identity when accessing your data through Cyral Sidecar.

Note that you’ll need to create users in your Snowflake account for each G Suite user who will use SSO to access the Snowflake account. See step 2 in Snowflake’s IdP Setup documentation.

Procedure

You must configure your Cyral Sidecar with some information from the SAML App that you created for sidecar-based access to Snowflake, above.

The relevant sidecar deployment parameters are:

  • IdPCertificate

  • IdPSSOLoginURL

  • SidecarPrivateIdPKey

  • SidecarPublicIdPCertificate

The values for IdPCertificate and IdPSSOLoginURL come from the SAML application configured on G Suite.  In your G Suite management screen, click DOWNLOAD METADATA on your SAML application. You’ll see the certificate and SSO URL that you need for these parameters. 


You can generate a private key and public certificate for your sidecar by using the following command 

openssl req -x509 -new -newkey rsa:2048 -nodes -subj '/C=US/ST=California/L=San Francisco/O=Cyral/CN=Cyral Identity Provider' -keyout cyral-idp-private-key.pem -out cyral-idp-public-cert.pem -days 7300

The files created by that command will provide you with values for SidecarPrivateIdPKey and SidecarPublicIdPCertificate .

Note that when inputting the values for IdPCertificate, SidecarPrivateIdPKey and SidecarPublicIdPCertificate, you’ll need to reformat the values to one-liners, replacing each line break with an \n character.

For example, 

-----BEGIN CERTIFICATE-----

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAA

-----END CERTIFICATE-----



would be converted to a single line that like that shown below (ignore line wrapping shown here):



-----BEGIN CERTIFICATE-----\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\nAAAAAAAAAAAAAAAAAAAAA\n-----END CERTIFICATE-----\n

Configure Snowflake for SAML

Configure your Snowflake instance to use the G Suite SAML app you created:

  1. Get the SSO URL from the IdP metadata you downloaded from G Suite.  You’ll also need your sidecar's IdP public certificate and private key for verifying the signatures on SAML Assertions created by the IdP.  Note that the sidecar is acting as your IdP.  If this is the first time you’re setting this up, you’ll likely need to generate a private key and certificate for your sidecar so it can act as an IdP.  To do that, execute the following command: 

openssl req -x509 -new -newkey rsa:2048 -nodes -subj '/C=US/ST=California/L=San Francisco/O=Cyral/CN=Cyral Identity Provider' -keyout cyral-idp-private-key.pem -out cyral-idp-public-cert.pem -days 7300

Put cyral-idp-private-key.pem somewhere safe, you’ll need it later when configuring the sidecar.  You’ll use cyral-idp-public-cert.pem in the next step.

  1. Log in to Snowflake with a user that has the ACCOUNTADMIN or SECURITYADMIN role and run the following Snowflake query to configure the Snowflake repository's identity provider:

alter account set saml_identity_provider = '{

  "certificate": "<same value as SidecarPublicIdPCertificate, but remove header and footer>",

  "ssoUrl": "<same value as IdPSSOLoginURL parameter>",

  "type"  : "custom",

  "label" : "GSuite"

  }';


Note that you should not include -----BEGIN CERTIFICATE----- or -----END CERTIFICATE----- when configuring the cert for the SAML identity provider.

For example, 

alter account set saml_identity_provider = '{

  "certificate": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAA",

  "ssoUrl": "https://accounts.google.com/o/saml2/idp?idpid=A32109zj2d",

  "type"  : "custom",

  "label" : "GSuite"

  }';

The command shown above will configure your Snowflake account to accept SAML assertions generated by the sidecar, and it configures the sidecar to accept SAML assertions generated by G Suite, effectively daisy-chaining the SAML authentication flow.

  1. Once the SAML_IDENTITY_PROVIDER property is set on the account, you can enable the SSO login page with the following Snowflake query:

alter account set sso_login_page = true;

Now you have the option to log in using the "Log in using ..." button, and Snowflake is ready to process SAML Assertions sent by the sidecar.

Your setup in G Suite and Snowflake is complete. Your users can use their SSO credentials to log into Snowflake, both through the IdP-initiated login flow as well as through the SP-initiated login flow. In both cases, the Snowflake session is proxied through the Cyral sidecar, and the user's G Suite identity is associated with their actions.

A note on the identity provider setting in Cyral: For Snowflake repos, the Advanced: Identity Provider setting in Cyral can be left in its default setting, None. To connect to Snowflake, data users will open in their browser an address that resolves to the Cyral sidecar. There they can choose to authenticate with their SSO credentials or with a native user account.


Connect to a Snowflake data repository through the sidecar


Once Cyral is deployed, you can access your Snowflake repositories by pointing your browser to the Cyral sidecar URL. To log in to a Snowflake repository:

  1. In your browser, open the Snowflake login page at the Cyral sidecar URL. Make sure the URL begins with https.

  2. Provide your Snowflake username and password, and after authentication the page will redirect you to your Snowflake repository.

With Cyral, you also have the option of using your enterprise SSO to authenticate users when they connect to Snowflake. In that case, the required username and password will be different from what is described above. For details, see the section Configure SSO authentication, below, and cyral.com/docs.


Connect to Snowflake using a Cyral SSO authentication token


Once SSO has been set up for your Snowflake repository, you can connect to Snowflake using your enterprise SSO credentials:

  1. In your browser, open the Snowflake login page at the Cyral sidecar URL. Make sure the URL begins with https.

  2. Click on the Log in using G Suite button or "Log in using [Identity-Provider]" button (where [Identity-Provider] is the name of your SSO platform).

  3. Provide your enterprise SSO credentials, and after authentication the page will redirect you to your Snowflake repository.



Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.