Secure user access to Snowflake in DevReady

Single Sign-On (SSO)

Our browser-based development environment DevReady incorporates Single Sign-On capabilities to streamline and secure user access across Snowflake accounts. By using OAuth and PKCE (Proof Key of Code Exchange), our data product platform ensures:

• Secure Authorization Process: The use of PKCE enhances security to prevent Cross-Site Request Forgery (CSRF) attacks during the authorization process. This ensures that the authorization code is exchanged only with the intended parties, enhancing the overall security of our SSO implementation.
• Client Authentication: The use of OAuth client credentials guarantees client authentication. This ensures a secure connection between your Snowflake account and DevReady, verifying the authenticity of client applications without exposing sensitive information.
• Secure access — blocking unauthorized sources: You can configure network policies within Snowflake to define a list of allowed IP addresses or ranges while blocking all other incoming connections. This involves specifying the permitted IP addresses for Snowflake connections, ensuring that access is denied from unauthorized sources and validating that the connection originates from DevReady. For more information on the IP addresses used by DevReady, refer to DevReady - Workspaces and network access.

Authorization flow

Your DevReady workspace and Snowflake interact through a secure redirect mechanism. Here's an overview of the process:

• The customer provides Snowflake account details, including the OAuth Client ID.
• A generated redirect URL initiates the authorization process, allowing users to sign in securely to Snowflake within the workspace. Universally Unique Identifiers (UUIDs) are generated for each authentication session to ensure uniqueness and prevent replay attacks.
• DevReady employs an internal redirect proxy that facilitates Snowflake OAuth for custom client security integrations to ensure secure connections without direct access. This Redirect Proxy is a separate application that handles authorization code redirection, ensuring the static redirect URL serves as a bridge between your workspace and Snowflake accounts.
• Authorization code is received by the redirect proxy. Redirect proxy validates and forwards the authorization code to the designated endpoint (the same workspace).
• Session tokens generated during authentication are stored in an ephemeral environment file in the workspace. The file is temporary and gets discarded when the workspace is destroyed, ensuring the security of user sessions.

The following sequence of events represents the flow:

Environment variables

DevReady supports encrypted, user-specific environment variables. They are stored as part of your user settings and can be used to set access tokens or pass any user-specific information to your workspaces.

warning

While the variable values are stored encrypted, they are available as plain text inside a workspace. Be careful when sharing your live workspace or using */* or */** as a repository pattern.

Vulnerability assessments

At DataOps.live, we prioritize the security of our DevReady releases by conducting thorough vulnerability assessments. We utilize a combination of open-source and premium scanners to ensure that each DevReady release is free from vulnerabilities that could potentially impact our valued clients Our dedicated team meticulously assesses each identified vulnerability, taking immediate action to mitigate the risk or confirm it as a false positive. Rest assured, our commitment is to actively address and eliminate any reported vulnerabilities that could affect the security of our application, providing you with a safe and reliable experience.

Security reporting protocol

Dataops.live appreciates and welcomes feedback from our users. If you identify a potential vulnerability, privacy concern, exposed data, or any security issues within our assets, we encourage you to report them to us. Your insights are valuable, and we are eager to address and resolve any security-related issues you may discover.

Kindly reach out to our Support team with the details of your findings.

Custom security monitoring tasks

DevReady allows customers to seamlessly integrate custom security monitoring tasks, providing flexibility for diverse security requirements. This section outlines the process of incorporating additional security monitoring tools.

1. Create a .gitpod.yml file at the root of your repository.

2. Define custom tasks by editing the .gitpod.yml file to include the tasks that run the required security monitoring commands.

   Here's an example:

   .gitpod.yml

   tasks:
     - name: Download Prerequisites
       command: wget https://example-package
     - name: Run Custom Security Screening Step
       command: python3 $REPO_ROOT/scripts/script.py

3. Save the .gitpod.yml file, commit the changes, and push them to your repository.

4. Launch DevReady.

Once the .gitpod.yml file is configured and pushed, DevReady automatically detects and executes the specified tasks before starting up the development environment.

By following these steps, you can effortlessly integrate and run custom security monitoring tasks tailored to your specific needs, extending the capabilities of DevReady to support a wide range of security measures.

Process management in DevReady

By utilizing process management tools, you can streamline background-process management, making it easier to develop and test your applications in a consistent and controlled environment. In the context of DevReady, you can use Supervisord (or similar tools) to manage and keep track of various background processes that your project may require.

To use it, define the processes you want to run and monitor in the Supervisord configuration file (typically named supervisord.conf). Afterward, configure DevReady to start Supervisord when the workspace is launched. You can do this by adding a script or command in the .gitpod.yml file to start Supervisord. Supervisord will automatically start, stop, and restart processes as needed, ensuring that your development environment has the required services running.

Suspicious activity safeguards

In case of suspicious activities within the DevReady workspace or the associated snowflake environment, it is important to acknowledge the available access controls for additional security. Security teams can proactively manage potential threats by blocking relevant IP addresses, terminating the connection from DevReady to the data warehouse, and swiftly responding to perceived risks. This provides an added layer of control and responsiveness in the face of security concerns.

There are 3 IP addresses that DevReady will use for connections outside the workspace, they are:

• 18.135.200.239
• 18.169.227.255
• 52.56.96.175

Moreover, if the toolset allows, security teams can go further by shutting down the associated containers. This cuts off connections and suspends the entire environment, immediately stopping ongoing processes or threats. By taking these measures, security teams can respond effectively to security concerns.

Blocking IP addresses and, when applicable, shutting down containers give security teams flexible tools to react quickly to security issues. This helps prevent unauthorized access and minimizes the impact of security incidents, ensuring the integrity and security of the DevReady environment against evolving threats.

Here is a network diagram to help give a visualization of the network connections between your computer, DevReady, and third-party services such as Snowflake:

Using a VPN for private network access

If you require private network access to a resource through a VPN, you can use tailscale in DevReady.

Tailscale is a VPN service built on top of the point-to-point open-source WireGuard that provides secure access to private networks. It is easy to set up and use, making it an ideal solution for connecting to private resources from your DevReady workspace.

There are two steps to set this up:

1. Create a .gitpod.Dockerfile at the root of your repository with the following content:

   RUN curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.gpg | sudo apt-key add - \
     && curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/focal.list | sudo tee /etc/apt/sources.list.d/tailscale.list \
     && sudo apt-get update -q \
     && sudo apt-get install -yq tailscale jq \
     && sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

2. Start the Tailscale processes on workspace start, you will need to create a .gitpod.yml file with the following content:

   tasks:
     - name: tailscaled
       command: |
         if [ -n "${TAILSCALE_STATE_MYPROJECT}" ]; then
           # restore the Tailscale state from DataOps Develop user's env vars
           sudo mkdir -p /var/lib/tailscale
           echo "${TAILSCALE_STATE_MYPROJECT}" | sudo tee /var/lib/tailscale/tailscaled.state > /dev/null
         fi
         sudo tailscaled
     - name: tailscale
       command: |
         if [ -n "${TAILSCALE_STATE_MYPROJECT}" ]; then
           sudo -E tailscale up
         else
           sudo -E tailscale up --hostname "gitpod-${GITPOD_GIT_USER_NAME// /-}-$(echo ${GITPOD_WORKSPACE_CONTEXT} | jq -r .repository.name)"
           # store the Tailscale state into DataOps Develop user
           gp env TAILSCALE_STATE_MYPROJECT="$(sudo cat /var/lib/tailscale/tailscaled.state)"
         fi

On the next workspace start, you will be prompted to log in to Tailscale, and when successful, a new node will be created using the naming convention gitpod-{user-name}-{repo-name}.

The machine state will be stored in DataOps Develop so that the subsequent workspace starts for the same project, and it should automatically connect to Tailscale.