dpgaspar commented on code in PR #35190:
URL: https://github.com/apache/superset/pull/35190#discussion_r2367147480
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,203 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+The default Apache Superset configuration is optimized for ease of use and
development, not for security. For any production deployment, it is
**critical** that you review and apply the following security configurations to
harden your instance, protect user data, and prevent unauthorized access.
+
+This guide provides a comprehensive checklist of essential security
configurations and best practices.
+
+### **Critical Prerequisites: HTTPS/TLS Configuration**
+
+Running Superset without HTTPS (TLS) is not secure. Without it, all network
traffic—including user credentials, session tokens, and sensitive data—is sent
in cleartext and can be easily intercepted.
+
+* **Use a Reverse Proxy:** Your Superset instance should always be deployed
behind a reverse proxy (e.g., Nginx, Traefik) or a load balancer (e.g., AWS
ALB, Google Cloud Load Balancer) that is configured to handle HTTPS termination.
+* **Enforce Modern TLS:** Configure your proxy to enforce TLS 1.2 or higher
with strong, industry-standard cipher suites.
+* **Implement HSTS:** Use the HTTP Strict Transport Security (HSTS) header to
ensure browsers only connect to your Superset instance over HTTPS. This can be
configured in your reverse proxy or within Superset's Talisman settings.
+
+### **`SUPERSET_SECRET_KEY` Management (CRITICAL)**
+
+This is the most critical security setting for your Superset instance. It is
used to sign all session cookies and encrypt sensitive information in the
metadata database, such as database connection credentials.
+
+* **Generate a Unique, Strong Key:** A unique key must be generated for every
Superset instance. Use a cryptographically secure method to create it.
+ ```bash
+ # Example using openssl to generate a strong key
+ openssl rand -base64 42
+ ```
+* **Store the Key Securely:** The key must be kept confidential. The
recommended approach is to store it as an environment variable or in a secrets
management system (e.g., AWS Secrets Manager, HashiCorp Vault). **Do not
hardcode the key in `superset_config.py` or commit it to version control.**
+ ```python
+ # In superset_config.py
+ import os
+ SECRET_KEY = os.environ.get('SUPERSET_SECRET_KEY')
+ ```
+
+> #### ⚠️ Warning: Your `SUPERSET_SECRET_KEY` Must Be Unique
+>
+> **NEVER** reuse the same `SUPERSET_SECRET_KEY` across different environments
(e.g., development, staging, production) or different Superset instances.
Reusing a key allows cryptographically signed session cookies to be used across
those instances, which can lead to a full authentication bypass if a cookie is
compromised. Treat this key like a master password.
+
+### **Session Management Security (CRITICAL)**
+
+Properly configuring user sessions is essential to prevent session hijacking
and ensure that sessions are terminated correctly.
+
+#### **Use a Server-Side Session Backend (Strongly Recommended for
Production)**
+
+The default stateless cookie-based session handling presents challenges for
immediate session invalidation upon logout. For all production deployments, we
strongly recommend configuring a server-side session backend like Redis,
Memcached, or a database. This ensures that session data is stored securely on
the server and can be instantly destroyed upon logout, rendering any copied
session cookies immediately useless.
+
+**Example `superset_config.py` for Redis:**
+
+```python
+# superset_config.py
+from redis import Redis
+import os
+
+# 1. Enable server-side sessions
+SESSION_SERVER_SIDE = True
+
+# 2. Choose your backend (e.g., 'redis', 'memcached', 'filesystem',
'sqlalchemy')
+SESSION_TYPE = 'redis'
+
+# 3. Configure your Redis connection
+# Use environment variables for sensitive details
+SESSION_REDIS = Redis(
+ host=os.environ.get('REDIS_HOST', 'localhost'),
+ port=int(os.environ.get('REDIS_PORT', 6379)),
+ password=os.environ.get('REDIS_PASSWORD'),
+ db=int(os.environ.get('REDIS_DB', 0)),
+ ssl=os.environ.get('REDIS_SSL_ENABLED', 'True').lower() == 'true',
+ ssl_cert_reqs='required' # Or another appropriate SSL setting
+)
+
+# 4. Ensure the session cookie is signed for integrity
+SESSION_USE_SIGNER = True
+```
+
+#### **Configure Session Lifetime and Cookie Security Flags**
+
+This is mandatory for *all* deployments, whether stateless or server-side.
+
+```python
+# superset_config.py
+from datetime import timedelta
+
+# Set a short absolute session timeout
+# The default is 31 days, which is NOT recommended for production.
+PERMANENT_SESSION_LIFETIME = timedelta(hours=8)
+
+# Enforce secure cookie flags to prevent browser-based attacks
+SESSION_COOKIE_SECURE = True # Transmit cookie only over HTTPS
+SESSION_COOKIE_HTTPONLY = True # Prevent client-side JS from accessing the
cookie
+SESSION_COOKIE_SAMESITE = 'Lax' # Provide protection against CSRF attacks
+```
+
+> ##### Note on iFrame Embedding and `SESSION_COOKIE_SAMESITE`
+>The recommended default setting `'Lax'` provides good CSRF protection for
most use cases. However, if you need to embed Superset dashboards into other
applications using an iFrame, you will need to change this setting to `'None'`.
+
+SESSION_COOKIE_SAMESITE = 'None'
+
+Setting SameSite to 'None' requires that SESSION_COOKIE_SECURE is also set to
True. Be aware that this configuration disables some of the browser's built-in
CSRF protections to allow for cross-domain functionality, so it should only be
used when iFrame embedding is necessary.
+
+### **Authentication and Authorization**
+
+While Superset's built-in database authentication is convenient, for
production it's highly recommended to integrate with an enterprise-grade
identity provider (IdP).
+
+ * **Use an Enterprise IdP:** Configure authentication via OAuth, OIDC, SAML,
or LDAP to leverage your organization's existing identity management system.
This provides benefits like Single Sign-On (SSO), Multi-Factor Authentication
(MFA), and centralized user provisioning/deprovisioning.
Review Comment:
Don't think SAML or OIDC is possible
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,203 @@
+---
+title: Securing Your Superset Installation for Production
+sidebar_position: 3
+---
+
+> *This guide applies to Apache Superset version 4.0 and later.*
+
+The default Apache Superset configuration is optimized for ease of use and
development, not for security. For any production deployment, it is
**critical** that you review and apply the following security configurations to
harden your instance, protect user data, and prevent unauthorized access.
+
+This guide provides a comprehensive checklist of essential security
configurations and best practices.
+
+### **Critical Prerequisites: HTTPS/TLS Configuration**
+
+Running Superset without HTTPS (TLS) is not secure. Without it, all network
traffic—including user credentials, session tokens, and sensitive data—is sent
in cleartext and can be easily intercepted.
+
+* **Use a Reverse Proxy:** Your Superset instance should always be deployed
behind a reverse proxy (e.g., Nginx, Traefik) or a load balancer (e.g., AWS
ALB, Google Cloud Load Balancer) that is configured to handle HTTPS termination.
+* **Enforce Modern TLS:** Configure your proxy to enforce TLS 1.2 or higher
with strong, industry-standard cipher suites.
+* **Implement HSTS:** Use the HTTP Strict Transport Security (HSTS) header to
ensure browsers only connect to your Superset instance over HTTPS. This can be
configured in your reverse proxy or within Superset's Talisman settings.
+
+### **`SUPERSET_SECRET_KEY` Management (CRITICAL)**
+
+This is the most critical security setting for your Superset instance. It is
used to sign all session cookies and encrypt sensitive information in the
metadata database, such as database connection credentials.
+
+* **Generate a Unique, Strong Key:** A unique key must be generated for every
Superset instance. Use a cryptographically secure method to create it.
+ ```bash
+ # Example using openssl to generate a strong key
+ openssl rand -base64 42
+ ```
+* **Store the Key Securely:** The key must be kept confidential. The
recommended approach is to store it as an environment variable or in a secrets
management system (e.g., AWS Secrets Manager, HashiCorp Vault). **Do not
hardcode the key in `superset_config.py` or commit it to version control.**
+ ```python
+ # In superset_config.py
+ import os
+ SECRET_KEY = os.environ.get('SUPERSET_SECRET_KEY')
+ ```
Review Comment:
There's probably some overlap here also,
https://superset.apache.org/docs/configuration/configuring-superset/#specifying-a-secret_key
There's some overlap with the security chapter itself:
https://superset.apache.org/docs/security/#user-sessions
We can improve the origin (if needed) and add a link here?
Or the other way around?
##########
docs/docs/security/securing_superset.mdx:
##########
@@ -0,0 +1,205 @@
+---
+title: Securing Your Superset Installation for Production
Review Comment:
We can remove CORS, CSRF and talisman ref's from networking to security
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
