Apache Superset security hardening starts with the trust boundary
The first decision is where the trust boundary sits. Superset stands between your people and your analytics databases, so its security depends on several layers working together: the application SECRET_KEY, the metadata database that holds Superset's own state, the identity provider and role model that decide who gets in and what they can see, the credentials Superset stores for each data source, and whether users can run arbitrary SQL through SQL Lab. A weakness in one layer can expose the others. Treat these layers as one chain and review them together, starting with the question of which of them an attacker or an overprivileged user could reach first.
Hardening is harder than it looks because default installs are built for quick starts, not production. The Superset architecture documentation says the SQLite default used by Quickstart and PyPI installs is not recommended for production, and the same applies to the Docker Compose PostgreSQL container. Superset also requires a user-specified SECRET_KEY before it will start, a requirement added in version 2.1.0. Starting successfully only proves the key exists. It does not prove the key is strong, unique to each environment, or kept out of source control. Most exposure comes from configuration and access decisions: an admin role granted too widely, a public or guest role left with data access, a shared database account used for every dashboard, or SQL Lab open to users who should only read charts. A vulnerability scanner will not find most of these.
Ownership matters as much as the settings. Apache Superset is released under the Apache License 2.0 (Apache-2.0), and the project has no paid edition. No vendor ships a hardened configuration to you, patches your instance on your behalf, or takes responsibility for your role model. The hardening work, the decisions behind it, and the ongoing watch on published CVEs belong to the organization that adopts Superset or to the partner it hires. Before go-live, ask every party involved to name in writing who owns each of the five layers, who approves changes to them, and who receives vulnerability notices for the components you run.
A practical starting sequence is short. Confirm that your metadata database engine and version appear on the supported list in the configuration documentation, which covers PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Generate the SECRET_KEY outside the application, store it in a secrets manager, and confirm that no copy exists in a repository or image. Decide which database account each data source will use and make it read-only where the analysis allows. Inventory who can reach SQL Lab. Finally, agree with the identity team which group claims map to which Superset roles, using AUTH_ROLES_MAPPING, before the first user signs in. The sections that follow take each layer in turn.
Which Superset components carry the security settings
Apache Superset spreads its security-relevant material across four architecture components: the Flask and React application, the metadata database, the optional caching layer, and the optional Celery worker and beat processes. Each one holds different secrets or access, so each needs its own hardening decisions before go-live.
Flask and React application and SECRET_KEY
The web application is the component that signs session data and holds the SECRET_KEY, which Superset requires you to set explicitly before it starts. Anyone who learns that key can forge session material, so the hardening question is who can read the configuration and how the key is generated, stored and rotated. Check that the key is long and random, kept out of source control, and that you have a tested path for rotation using PREVIOUS_SECRET_KEY.
Metadata database holding users and connections
The metadata database stores users, roles, permissions and the connection records that tell Superset how to reach your data sources. Its contents describe your access model, and some connection records may hold credentials. The hardening question is who can query or dump this database, and whether it is restricted to the Superset application and its administrators. Confirm the supported PostgreSQL or MySQL versions with the configuration documentation and avoid the SQLite default for production.
Caching layer for async work
The optional caching layer, most often Redis in Superset deployments, supports async queries, dashboard thumbnails and the queues behind alerts and reports. Cached query results and task messages can contain business data, and the cache usually has its own authentication settings. The hardening question is whether the cache is reachable only from the application and worker hosts, whether it requires authentication, and whether it is encrypted in transit where your policy requires it.
Celery worker and beat processes
Celery workers run alerts, scheduled reports, async queries and thumbnail generation, and beat schedules the recurring jobs. Workers connect to the cache, the metadata database and every data source they query, so they often hold the broadest network reach in the platform. The hardening question is which service account and network path each worker uses, and whether a worker compromise would expose more data sources than the users who triggered the job should see.
Data source connections reached by SQL Lab and workers
SQL Lab and the workers open connections to your analytics databases using credentials saved in Superset. Those credentials define what the platform can read, regardless of which Superset role a user holds. The hardening question is whether each connection uses a dedicated, read-only database account scoped to the datasets it serves, and whether SQL Lab exposure and row-level security are enforced at the database layer as well as in Superset.
Apache Superset security hardening choices and what each costs you
This table compares the main hardening decisions for Superset, from how users sign in to how HTTPS terminates, and what each choice asks of your team after go-live. Read each row for the case where it fits and the ongoing work it creates, then confirm the vendor and driver details in your own environment before you commit.
| Decision | When it fits | Operational cost |
|---|---|---|
| Authentication: local accounts | Small pilots or break-glass administrator access where no identity provider is available | Manual account creation, password policy enforcement and offboarding that depends on someone remembering to disable users |
| Authentication: OAuth2 (for example Google or Azure, or a custom OAuth2 server) | Organizations that already centralize sign-in and want MFA and disablement enforced by the identity provider | Client registration, redirect URI and secret management, and testing of provider changes in staging before cutover |
| Authentication: LDAP | Estates with directory-based access control that cannot use OAuth2 for Superset | Bind account credential rotation, directory connectivity from the Superset network, and group structure that must stay stable |
| Role assignment: manual | Small user counts or highly controlled access where administrators approve each role change | Ongoing effort for every joiner, mover and leaver, and a higher risk of role drift over time |
| Role assignment: AUTH_ROLES_MAPPING | Larger user bases where directory or OAuth groups already reflect job function | Upfront mapping design, a maintained list of group-to-role rules, and review whenever group names change in the source system |
| SQL Lab: open to analysts | Teams that rely on ad hoc SQL and have data owners who accept broader query rights | Greater need for query monitoring, result-size controls and database-side read-only permissions to limit exposure |
| SQL Lab: restricted to a small group | Regulated datasets where direct SQL access must be limited to named engineers or analysts | Reduced self-service, more requests routed to a few people and a need to keep the restricted role list current |
| Data source credentials: shared service account | Simple setups with one read-only account per database and uniform data access for all users | Credential rotation touches every connection at once, and per-user row visibility must be enforced elsewhere |
| Data source credentials: per-user where supported | Environments that need database-side audit and access that follows each person's own grants | Confirm each database driver's support for per-user credentials before choosing this model, plus token or secret handling and more connection management |
| Row-level security | Restricting which rows a role sees within shared datasets | Rules must be written, tested and reviewed whenever tables or role definitions change, and gaps are easy to miss without test accounts |
| HTTPS termination at a load balancer or reverse proxy | Shared platforms where certificates, TLS policy and WAF rules are managed centrally | Certificate renewal, proxy header trust settings and checks that the application is not reachable without the proxy |
| HTTPS terminated inside the Superset host or container | Single-node deployments with no central TLS service | Certificate renewal on the host, manual TLS configuration updates and a separate patch path for the web server |
Order of Apache Superset security hardening steps
The sequence below moves a Superset install from a default development setup to a production configuration with a supported metadata database, a unique secret key, encrypted transport, federated sign-in, scoped access and locked-down SQL Lab. Each step ends with a check you can run before moving on.
Deploy with a supported metadata database
Replace the SQLite default with a production metadata database. Superset's configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported versions, and the architecture documentation advises against SQLite and the Docker Compose PostgreSQL container for production. Confirm which version your platform team can back up and patch, and confirm the database is reachable only from the Superset web and worker nodes. Done means Superset starts, completes its schema migrations against the new database, and the SQLite file is no longer referenced in the configuration.
Generate and set a unique secret key
Generate a long random value for SECRET_KEY in your secret store, not in the repository, and inject it into the Superset configuration at deploy time. Superset requires a user-specified key to start (a requirement added in version 2.1.0), so the default placeholder cannot be used. Record the key's owner and where it is stored, and plan rotation with PREVIOUS_SECRET_KEY so existing sessions and encrypted values can be re-encrypted. Done means a test start with the key removed fails with a clear error, and the running instance starts only with the stored value.
Terminate HTTPS at the proxy and set cookie behavior
Place a reverse proxy or load balancer in front of Superset and terminate TLS there with certificates from your certificate authority. Configure Superset to trust the forwarded protocol headers from that proxy only, and set session and CSRF cookies to secure and HTTP-only where your configuration allows. Block plain HTTP access at the proxy. Done means a request over HTTP is redirected or refused, the login page loads only over HTTPS, and the session cookie carries the secure attribute in the browser developer tools.
Connect the identity provider and map groups
Connect Superset to your identity provider using OAuth2 (for example Google or Azure), a custom OAuth2 server using the code flow, or LDAP, as your identity team supports. Map provider groups to Superset roles with AUTH_ROLES_MAPPING and disable local password login for users who should only come through SSO. Confirm with your identity team that group membership is the authorization source of truth. Done means a user from each test group signs in and holds exactly the roles mapped to that group, and a user outside all groups is refused or has no role.
Define roles and row-level security
Design the role model before granting data access: start from the built-in roles, create custom roles for each analyst population, and grant dataset access by role rather than per user. Add row-level security rules on datasets that hold multi-tenant or regional data, and review each rule with the data owner. Keep administrator roles few and named. Done means a test user in a restricted role sees only the permitted datasets and the filtered rows, and the role matrix has been signed off by the data owners.
Scope data source credentials and connection users
Store each data source password or token in your secret store and reference it from Superset rather than typing it into the database connection form. Create a dedicated read-only database user per connection with grants limited to the schemas Superset needs. Confirm the connection user cannot write, alter or read unrelated schemas. Done means a test query that attempts a write or reads an out-of-scope table fails at the database, and no plaintext credential appears in the Superset configuration or the metadata database.
Restrict or gate SQL Lab
Decide which roles may use SQL Lab, since free-form SQL is the widest data exposure in Superset. Remove SQL Lab access from roles that only need dashboards, limit the database connections each SQL-capable role can query, and review any feature flags that broaden SQL execution. Where possible, gate SQL Lab to a small group and log its use. Done means a dashboard-only user cannot open SQL Lab, and a SQL-capable user's attempt to query a connection outside their role is blocked.
Turn off or lock down development features
Disable debug mode, remove example data and sample dashboards, turn off any development-only feature flags, and restrict access to administrative and diagnostic endpoints at the proxy. Keep the Superset image and dependencies at a version you have tested, and check the release notes and published CVEs for that version before each upgrade, following UPDATING.md for breaking changes. Done means a production-profile configuration review shows debug disabled and no example content, and a request to a development endpoint returns an error from the proxy.
How to set and rotate the SECRET_KEY without breaking sessions
Set a unique SECRET_KEY before the first start of Apache Superset and treat it as a long-lived credential. Superset requires a user-specified SECRET_KEY to start, a requirement added in version 2.1.0, so the platform will not run on a built-in default. The practical risk is not the startup check but what teams do to satisfy it: copying a placeholder from an example file, reusing one value across environments, or committing the value to the same repository as the configuration. Generate the value with a cryptographically secure random source, make it long, and give each environment (development, staging, production) its own key so a leak in one does not expose the others. Store the key outside source control. A secrets manager your organization already operates, or a Kubernetes Secret with restricted read access, is the usual choice. Inject it into the application at runtime through an environment variable or a mounted file that your configuration reads, so the value never appears in a container image, a Helm values file in Git, or a ticket. Confirm in the configuration documentation which loading pattern your installation method supports, and check that logs and debug output do not print the configuration object. The same rule applies to the worker processes, which read the same configuration and must receive the same key. Rotate the key with PREVIOUS_SECRET_KEY, which is the documented path. The general approach is to set the new key as the active SECRET_KEY, keep the old value available as PREVIOUS_SECRET_KEY during the transition, and remove the old value once the change has settled. Order matters across nodes. Deploy the configuration that carries both values to every web node and every Celery worker before any node starts using the new key as the only key, so that no node rejects sessions or encrypted data written by another node. Roll the change in a fixed sequence, verify each node after it restarts, and keep a record of which version of the configuration is live on each one. Test the rotation in staging first, using a copy of production configuration and a metadata database restored from a recent backup. Log in with an existing user before the change, perform the rotation, and confirm that the session stays valid, that scheduled reports and async queries still run, and that saved database connections still work. Before any production change, confirm with the Superset configuration documentation how rotation interacts with existing encrypted values, including data source credentials stored in the metadata database. Do not assume that a session-only rotation also re-encrypts stored secrets. If the documentation is unclear for your version, ask your vendor contact or test a full rotation in staging and inspect the result. Before go-live, write down who holds the current and previous keys, which roles can read them in the secrets manager, and where the offline backups of the key are kept. Record the rotation procedure, the owner who approves it, and the date of the last rotation. A backup of the metadata database is not enough on its own: if the key is lost, encrypted values in that database may become unreadable. Store the key backup with the same access controls as the key itself, and test a restore path in staging so the team knows how to recover if the production secret is lost or compromised.
Which roles and data controls keep analysts inside their scope
Superset's access model decides what each analyst can see, build and change. The cards below cover the internal role model built on Flask-AppBuilder, the controls over database connections and datasets, and row-level security, including where each control stops. Group mapping from your identity provider and per-customer embedded filtering are covered on their own pages.
Separate viewer, author, owner and admin roles
Superset is built on Flask-AppBuilder, so access is granted through roles that bundle permissions. Keep dashboard viewers, chart authors, dataset owners and administrators as distinct roles rather than giving analysts the Admin role for convenience. Review each built-in role's permission list against your policy, because custom roles can add or remove permissions that the defaults grant. Confirm the exact permission names in your release's documentation before you write a role matrix.
Restrict who can create database connections
Database connections hold the credentials Superset uses to query your warehouse, so creating or editing them is a privileged action. Limit connection management to a small platform group and keep analysts on existing connections only. Check whether your build lets non-admin roles see connection details or test connections, and remove those permissions if they are granted. Pair this with the data source credentials work so the account behind each connection has only the reads it needs.
Control access to datasets and schemas
Dataset permissions determine which tables and schemas a role can query through Superset's interface, and they are the main boundary analysts meet day to day. Grant access per dataset or per schema to matching roles, and audit datasets that were created from SQL Lab, since those can point at tables that no one reviewed. Ask your team to confirm how schema-level access behaves for a given database engine before relying on it.
Filter rows per role or user with row-level security
Row-level security adds a filter, written as a SQL predicate, that Superset applies to every query against a dataset for matching roles or users. It limits what a regional analyst sees in a shared sales dataset, for example, without duplicating the table. It protects against accidental overexposure inside Superset's own queries. It does not stop a user or worker with direct database access from reading every row, so pair it with database-level permissions on the same tables. Test each rule with accounts from every role before go-live.
Limit SQL Lab and ad hoc query exposure
SQL Lab lets a user run arbitrary SQL against any connection they can reach, which can bypass dataset-level design choices made for chart builders. Decide which roles may use SQL Lab, on which connections, and whether results can be exported. Row-level filters apply to datasets, so review whether they also reach the queries analysts write by hand. Confirm this behavior in your release's documentation and in your own test environment.
Review roles and permissions on a schedule
Role assignments drift as people move teams, and permissions added for a project often outlive it. Set a recurring review of role membership, custom role permissions and row-level filter rules, and record who approved each change. Export the current role and permission list from Superset as evidence for that review. Ask your team how group changes in your identity provider flow into Superset roles, since that mapping is covered on the SSO page.
What drives the effort of Apache Superset security hardening
This table lists the factors that change how much work Superset hardening takes and whether each one is paid once or recurs. Use it to see which choices in your environment widen the scope, and to decide which ones to narrow before asking for a fixed-scope quote. Every driver below has a way to keep it contained, so the main takeaway is that exposure decisions made early cost less than securing them later.
| Driver | Why it changes effort | One-time or recurring | How to keep it down |
|---|---|---|---|
| Roles and user groups | Each group mapped through AUTH_ROLES_MAPPING or created by hand needs its own permission review, and every custom role multiplies the matrix to test. | One-time design, then recurring access reviews as people join and leave | Use a smaller role matrix built from a few business personas, and let the identity provider own group membership |
| Number of data sources and credential models | Each database connection needs a credential decision, secret storage, network path and rotation plan, and some engines support more auth methods than others. | One-time per connection, recurring for credential rotation | Connect only the reporting schemas needed, and use a shared read-only database account for the reporting schema |
| SQL Lab access for analysts | Opening SQL Lab means users can run arbitrary queries, so you must review database grants, query limits and which schemas are visible. | One-time configuration, recurring review of who holds the permission | Limit SQL Lab to a small group, restrict it to read-only accounts, and keep ad hoc access off sensitive datasets |
| Row-level security rules | Each rule must be written, tested against every role that touches the dataset, and re-checked when the schema changes. | One-time build, recurring testing after schema changes | Apply row-level rules to a small number of shared datasets rather than to every chart |
| Environments needing separate keys and secrets | Development, staging and production each need their own SECRET_KEY, database credentials and OAuth client settings, plus a documented way to keep them apart. | One-time setup per environment, recurring rotation for each | Automate secret injection from one secrets store and keep a single documented rotation procedure |
| Alerts, reports and async queries | Enabling them adds the caching layer and Celery worker and beat processes, which need their own hardening, network limits and access to the metadata database. | One-time hardening of workers and cache, recurring patching of those services | Enable only the features the business uses, and deploy workers in the same locked-down network zone as the application |
| HTTPS and certificate management | Every public or internal hostname needs a valid certificate, secure cookie settings and a renewal process that does not depend on one person. | One-time setup, recurring renewal and certificate monitoring | Use an existing certificate authority and automated renewal at the load balancer or ingress |
| Identity integration complexity | OAuth2, LDAP or remote user headers each have different failure modes, and group-to-role mapping must be tested for every identity provider group. | One-time integration and testing, recurring changes when the identity provider changes | Choose one identity method for all users and keep the group mapping list short |
| Compliance evidence needs | Assessors may ask for configuration baselines, access reviews, patch records and change history. Producing them takes effort that is separate from the technical hardening itself. | One-time evidence design, recurring evidence collection for each assessment cycle | Agree the evidence list before work starts, and collect it from configuration and logs as part of normal operations |
Exposing SQL Lab, HTTPS and keeping up with published CVEs
SQL Lab is the feature to review first in any Superset hardening exercise. It lets authorized users write and run arbitrary SQL against every database connection the instance can reach, so the blast radius of a compromised or careless account is set less by Superset's dashboards and more by what the database account behind SQL Lab is allowed to do. Before go-live, list which roles can open SQL Lab, which database connections each role can query through it, and what the underlying database users can read, write or drop. Treat that list as the core artifact of the review, because it answers the question an auditor or incident responder will ask first: what could a single login reach?
Restrict SQL Lab to named roles rather than leaving it open to every analyst by default. Review the permissions attached to each role, and confirm that the roles granted SQL Lab access are the ones your data governance process has approved. Pair that with read-only database accounts for every connection that SQL Lab uses. A read-only account stops a query from altering data even when the user's intent is harmless, and it should be created separately from the account the ingestion or dataset jobs use. Decide, schema by schema, which schemas are exposed to each connection. Exposing a whole database because it is convenient usually widens the blast radius more than the team expects, so start with the minimum set of schemas that the approved analysts need and add others through a documented request.
Terminate HTTPS at a reverse proxy or load balancer in front of Superset, and do not serve the application over plain HTTP on any network that users or other systems cross. Configure the proxy so that it redirects HTTP requests to HTTPS and sends the forwarding headers Superset needs to build correct URLs. On the Superset side, review the cookie and session settings described in the configuration documentation, including secure cookie behavior, and confirm them against the version you deploy because option names can change between releases. Also decide whether traffic between Superset and the metadata database, and between Superset and each analytics database, uses TLS. Where the database supports it, enable encrypted connections and verify the server certificate rather than trusting any certificate presented. Confirm each of these choices with your database and network teams, since the supported options differ by engine and deployment.
For patching, track the Apache Superset releases page on GitHub and the project's published security channels, and subscribe your platform team to them before go-live rather than after the first incident. Stay on a supported stable release line, and confirm the support window for that line in the project documentation or release notes. Avoid pre-release builds in production. Pre-release tags, including release candidates, are published for testing and can change before a stable release, so use them only in a non-production environment. When a security advisory is published, check whether it affects your version, your enabled features and your configuration, then schedule the upgrade through the staging process described in the upgrade documentation. Do not name specific CVE identifiers in your runbook unless you have confirmed them against the project's own advisories.
What to monitor, rotate and document after hardening
Hardening is only as durable as the routines that follow it. The controls below cover what to watch, what to rotate, what to review when teams change, how upgrades are staged, and which records the client keeps so the hardened state can be verified by someone other than the original builders.
Monitor logins, role changes and failures
Watch sign-in events in your identity provider and failed authentication and role assignment events in Superset's logs. Route both to the team that owns security alerts. Check that the identity provider records group membership changes, because Superset roles derived from AUTH_ROLES_MAPPING follow those groups. Confirm the retention period for these logs matches your internal policy before go-live, not after the first incident.
Rotate data source credentials on schedule
Database connections in Superset hold credentials for your analytics sources. Set the rotation interval with the client's security owner, then rotate each credential in the source system and update the connection in Superset in the same change window. Use read-only service accounts where the source allows it, so a leaked credential exposes less data. Record the next rotation date against each connection.
Rotate SECRET_KEY with a planned window
Superset requires a user-specified SECRET_KEY and supports rotation by setting PREVIOUS_SECRET_KEY alongside the new value, per the configuration documentation. Plan the rotation with the client's schedule, confirm the key is supplied from the secret store rather than a config file in source control, and verify that sessions and encrypted fields still work after the change. Keep the previous key only as long as the rotation procedure requires.
Review the role matrix when teams change
Reassignments, new teams and departures change who can see which datasets, dashboards and SQL Lab. Review the role matrix at each organizational change and remove access that no longer matches the owner's duties. Compare the live role assignments with the documented matrix, because drift between the two is the usual way least-privilege erodes. Include row-level security rules in the same review.
Back up metadata before every upgrade
The metadata database holds dashboards, datasets, users and roles, so it is the first thing to protect. Take a verified backup of PostgreSQL or MySQL before any version change, and confirm you can restore it into a separate environment. Do this before running database migrations, since a failed migration is harder to reverse without a clean copy.
Stage upgrades and check UPDATING.md
Test each Superset release in staging first, and read UPDATING.md for breaking changes between your current and target versions. After deployment, run superset db upgrade and superset init as the upgrade documentation describes, then re-check roles and authentication. The full upgrade process, including support scope, is covered in the upgrades and support topic.
Track published security patches
Record the Superset version in production, subscribe to the project's release announcements, and review each published security advisory against your deployed version. Set a target window for applying security fixes with the client's risk owner. Keep the record of which advisories applied and when, since auditors and incident responders will ask for it.
How to test that Apache Superset security hardening holds
Hardening only counts if you can show it works after deployment, after every upgrade and after every change to roles or credentials. The verification for a Superset rollout should be a written test script that a second person can run, with each test tied to one control and one expected result. Start with the cases where a mistake is most costly: whether Superset refuses to start without a user-specified SECRET_KEY, whether a restricted account can reach only what its role allows, and whether a user can see data they should not. Record the command, the account used, the observed result and the date for every run, so the evidence survives staff changes.
Startup tests come first. Deploy a non-production instance with the SECRET_KEY removed or left at a placeholder value and confirm that Superset does not start. The configuration documentation describes the requirement, which was added in version 2.1.0, so your test should confirm it on the exact version you run, not assume it. Next, log in with restricted test users, one per role you have defined, and attempt actions outside that role: opening dashboards owned by another team, editing datasets, exporting data and reaching admin screens. Each denied action should produce a clear refusal in the interface and an entry in the application log. A role that can do one unexpected thing is a finding, even if the rest of the model holds.
Row-level security tests need two users and one shared dataset. Define a rule that restricts rows by region or business unit, then run the same chart or SQL query as each user and compare the returned row counts and sample values against the database directly. Include a user who belongs to two groups, because overlapping role mappings are a common source of unexpected access. For SQL Lab, submit statements that your policy blocks, such as data modification or access to schemas outside the allowed list, and confirm each is refused. Then confirm that the database credentials are not visible in the browser, the dashboard source, the database connection screen for non-admin users, or application logs. Search the logs for the password string itself, not only for the word password.
HTTPS checks should be scripted too. Verify the certificate chain from outside your network, confirm that plain HTTP requests redirect to HTTPS, and inspect the session and CSRF cookies for the secure and HTTP-only flags and an appropriate same-site setting. Confirm which of these your reverse proxy and Superset configuration each set, because the proxy may be where the setting lives. The failure drill is the test that proves the rest matters. Revoke a role or disable a user in the identity provider, then confirm that the user's existing session and new logins stop working within the time your policy allows. Rotate a database credential and confirm that dashboards fail visibly rather than falling back to a cached or shared account. Record how long each step took.
Before go-live, have an independent penetration test or security review examine the deployed instance, because a self-written script cannot find what its author did not think to check. DeployOpen runs application, API and infrastructure security testing as part of its services, and the results give your team a documented list of findings and fixes. DeployOpen does not issue audit reports, attestations or certifications, so if a compliance assessor needs formal evidence, confirm with that assessor which artifacts they accept. Ask any testing provider for a written scope, the test accounts and environment used, and a retest of the fixes. Repeat the script after each Superset upgrade and after each change to roles, credentials or certificates.
How DeployOpen scopes, builds and hands over Superset hardening
DeployOpen approaches Apache Superset security hardening as a written, fixed-scope engagement inside your own infrastructure. We review the deployment against your access model, data source connections and exposure, then build and test the controls before handing over documentation and runbooks your team can operate.
How we scope
- We confirm the Superset version, metadata database (PostgreSQL or MySQL), and whether caching and Celery workers are in use.
- We inventory SECRET_KEY handling, role and row-level security design, data source credentials, SQL Lab exposure and HTTPS termination.
- The written scope names the hardening items, environments covered, deliverables and timelines before any work starts, and engagements are fixed-scope.
How we build
- We configure the SECRET_KEY with a rotation plan using PREVIOUS_SECRET_KEY, and document how each rotation is rehearsed in staging.
- We design least-privilege roles, map identity groups with AUTH_ROLES_MAPPING where used, and test row-level security against sample accounts.
- We review database connection credentials, SQL Lab permissions and HTTPS settings, then test each control and record the results.
How we hand over
- You receive a hardening record covering configuration changes, role model, credential locations and the rotation procedure.
- We provide upgrade and CVE-response runbooks that follow the documented backup, upgrade and UPDATING.md review steps.
- Knowledge transfer sessions walk your administrators through the controls, tests and the evidence needed for internal or external assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing after go-live.
- A retainer can cover monitoring published Superset releases and CVEs, and applying patches through your staging process.
- Compliance readiness work prepares controls and evidence for your assessors, while independent auditors issue any formal reports or certifications.
