Securely Deploying Streamlit Apps in Your Company: A Practical Guide
Conclusion
Use Cloudflare Tunnel and Cloudflare Access for secure deployment. Depending on requirements, Streamlit in Snowflake may also be a viable option.
Introduction
Streamlit is a convenient tool for quickly creating data applications. However, when deploying applications that handle internal company data, strict precautions must be taken to prevent unauthorized external access. Despite this, there are still no mature methods for securely deploying Streamlit.
In this article, we will review the issues by looking at an example of the simplest Streamlit deployment configuration, and then explain solutions to address them in order.
Please note that to use the configurations introduced in this article, your domain’s nameservers must be on Cloudflare.
Why is a simple configuration dangerous?
Let’s first review the problem by looking at an example deployment configuration for a Streamlit application:
In this diagram, Streamlit is deployed behind a firewall of an internal network or cloud service. The firewall allows port 8080, and the application can be accessed from a browser via http://203.0.113.0(a hypothetical public IP address).
Problems
However, this simple configuration has three problems:
It uses HTTP communication: When accessed from a public network, there is a risk of communication being intercepted and data leaking.
Firewall ports are opened: Notifying and justifying to internal security personnel is necessary. If a different application is deployed after this one is decommissioned, incidents may occur.
Directly accessing via IP address: There are various issues such as the URL being hard to remember and not scalable.
To solve these problems, the next section will explain an improved example using Cloudflare Tunnel.
Is it possible to access without opening inbound ports?
To address the issue of opening inbound firewall ports mentioned in the previous section, here is an improved configuration example using Cloudflare Tunnel:
In this configuration, no inbound ports are opened on the firewall at all. Instead, a service called cloudflared, running on the same network, accepts user requests using only outbound connections and forwards them to the Streamlit application.
How can traffic be accepted with only outbound connections?
When cloudflared is deployed on a private network, it sends an authentication request to Cloudflare servers. It uses an authentication key issued from the Cloudflare management screen, which is input as an environment variable.
Once authentication is complete, cloudflared and Cloudflare servers establish a robust, end-to-end encrypted tunnel. From this point on, traffic can be sent and received bidirectionally through any protocol such as http, ssh, or udp.
By using this architecture, bidirectional connections are possible with only outbound connections. Since inbound connections are not allowed at all by the firewall, third parties will be rejected no matter which port they access.
From here on, requests sent by users to Cloudflare as https://{mydomain}/streamlit are directly forwarded by Cloudflare to cloudflared. Based on the mapping between `/streamlit` and http://streamlit:8080 set in the Cloudflare Tunnel management screen, cloudflared forwards the request to http://streamlit:8080 within the private network. The response from the Streamlit server passes back through the tunnel and is returned to the user via Cloudflare.
Issues resolved by this configuration
The Streamlit application can be made accessible from the outside without opening any inbound firewall ports.
Since users only interact with Cloudflare servers, SSL can be automatically supported.
Redeployment is unnecessary when changing settings, as forwarding settings can be modified from the Cloudflare Tunnel management screen.
As explained above, by utilizing Cloudflare Tunnel, issues related to opening inbound ports can be resolved.
However, in this state there is no authentication or authorization functionality, so external users can also access the Streamlit application.
The next section will explain an example of implementing authentication using Cloudflare Access.
Is it possible to authenticate without implementing authentication functionality in the application?
In the previous section, we solved the inbound port issue using Cloudflare Tunnel. Next, we will explain how to solve the authentication problem using Cloudflare Access.
When a user accesses https://{mydomain}/streamlit/marketing, authentication is performed as follows:
- Cloudflare automatically validates the user’s cookies or headers and attempts authentication with the organization’s SSO provider.
- If authentication succeeds, the user can access the Streamlit application.
- If authentication fails, the authentication provider’s authentication flow is initiated.
- If authentication succeeds, the user can access the Streamlit application.
With this configuration, users who have not been authenticated cannot reach the Streamlit application at all.
Why is this possible?
These functions are possible because `Cloudflare Access` acts as a reverse proxy and handles authentication on behalf of the application. User requests first reach Cloudflare Access, where authentication is performed against the SSO provider. Only authenticated requests are forwarded to the backend application, so the application does not need to implement authentication processing.
Additionally, Cloudflare Access can integrate with many authentication providers and handles the authentication flow. This means developers do not need to implement complex authentication processing within the application.
Issues resolved by this configuration
- User authentication can be performed without implementing authentication functionality in the application. Developers do not need to write authentication code.
- Authentication settings can be made via GUI, greatly reducing implementation and maintenance costs related to authentication.
- Detailed access control using user attributes such as department affiliation is possible.
- Authentication functionality can be shared across multiple applications, allowing reuse of authentication-related implementations.
Other features of Cloudflare Access
Cloudflare Access enables not only authentication but also detailed authorization control. For example, by retrieving department information from the SSO provider, it is possible to control access so that marketing department users can access `streamlit/marketing` but not `streamlit/sales`.
Cloudflare Access supports a variety of authentication methods, including Google authentication, Microsoft Entra ID authentication, and OpenID Connect.
Furthermore, Streamlit can utilize the information of users authenticated by Cloudflare Access. By using the JWT contained in post-authentication request headers, the user’s name and ID can be obtained and utilized within the application.
As described above, by leveraging Cloudflare Access, authentication functionality can be quickly implemented and maintainability and reusability can be improved.
What is Streamlit in Snowflake?
When securely deploying Streamlit applications, in addition to combining Cloudflare Access and Cloudflare Tunnel, using Streamlit in Snowflake is another option.
Streamlit in Snowflake is a feature that allows Streamlit applications to be run directly on Snowflake. Using this method provides the following benefits:
1. Secure deployment can be easily achieved since Snowflake’s access control functions are provided in a managed way.
2. Streamlit application execution speed can be improved since the location of data and computing are close.
3. It is more secure since data does not leave Snowflake.
Limitations
However, as of now, there are the following limitations:
- A Snowflake account is required to use Streamlit in Snowflake.
- Streamlit in Snowflake cannot be used with GCP Snowflake accounts yet. (as of 2024/04/23)
- The use of some Python libraries is restricted.
Based on the above, Streamlit in Snowflake can be considered a promising option for use cases requiring secure deployment and improved performance, but caution is necessary as there are currently limitations.
Conclusion
To securely deploy Streamlit applications, it is effective to combine Cloudflare Access and Cloudflare Tunnel. Using this method provides the following benefits:
- The need to open inbound firewall ports is eliminated, reducing security risks.
- SSL can be easily introduced to applications, ensuring communication confidentiality.
- Authentication functionality can be quickly implemented.
- Detailed authorization control becomes possible, allowing access restrictions by department.
- Information of authenticated users can be utilized within the application.
Although omitted in this article, using Cloudflare Warp can make the configuration even more secure.
Let’s rapidly advance internal data utilization using secure Streamlit !
