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
PKCEenhances 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.
The interaction between your DevReady workspace and Snowflake occurs through a secure redirect mechanism. Here's an overview of the process:
- 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.
- To ensure secure connections without direct access, DevReady employs an internal redirect proxy that facilitates Snowflake OAuth for Custom Clients security integrations. 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 flow is represented by the following sequence of events:
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 other kind of user-specific information to your workspaces.
While the variable values are stored encrypted, they are available as plain text inside a workspace. Be careful when sharing your live workspace or when using
*/** as a repository pattern.
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 either 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.
At the root of your repository, create a
Define custom tasks by editing the
.gitpod.ymlfile to include the tasks that run the required security monitoring commands.
Here's an example:.gitpod.yml
- name: Download Prerequisites
command: wget https://example-package
- name: Run Custom Security Screening Step
command: python3 $REPO_ROOT/scripts/script.py
.gitpod.ymlfile, commit the changes, and push them to your repository.
.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 the management of background processes, 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
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, effectively terminating the connection from DevReady to the data warehouse and ensuring a swift response to any perceived risks. This provides an added layer of control and responsiveness in the face of security concerns.
Moreover, if the chosen toolset allows, security teams can go further by shutting down the associated containers. This not only cuts off connections but also suspends the entire environment, immediately stopping any 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.