Apache Superset for SOC 2 logical access controls: what the platform covers
Superset can give an auditor evidence for CC6.1 and CC6.3 when it is configured with SSO-only login, mapped roles and exportable logs, but it cannot make a SOC 2 scope pass on its own. CC6.1 covers the logical access software and architecture that protects your information assets, and CC6.3 covers granting, changing and removing access by role, least privilege and segregation of duties. Superset also contributes to CC6.2 (user registration and authorization) and, through its logs, to CC7.2 (monitoring for anomalies). It does not perform the identity proofing, access approvals, network boundary protection under CC6.6 or the monitoring program itself, and those remain your controls and your evidence.
SOC 2 examinations use the AICPA 2017 Trust Services Criteria, and the security common criteria CC1 to CC9 apply to every SOC 2 report. A Type 1 report describes the system and tests whether controls are suitably designed as of a single date. A Type 2 report adds an opinion on operating effectiveness over a period, which means an auditor will want to see the access controls working consistently across months, not only configured once. Confirm with your auditor which report type and which period applies to your scope, and whether the analytics layer is inside the system description.
DeployOpen plans, configures and documents the Superset environment in your infrastructure and prepares the evidence your team will hand to the auditor. DeployOpen does not issue SOC 2 reports, attestations or certifications, and the service auditor makes the judgments about your controls. Before scoping the work, ask your auditor which evidence they expect for each criterion and whether your Superset deployment, its metadata database and its identity provider belong in the boundary.
Mapping CC6.1, CC6.2 and CC6.3 to Superset capabilities and configuration
This table maps each logical access requirement to the Superset capability that supports it and the configuration an assessor would expect to see. Read it as the platform side of the control: it shows what Superset can enforce and record, while the organization's identity, joiner and leaver processes and review evidence complete the control.
| Requirement | Superset capability | Configuration to set | Evidence to keep |
|---|---|---|---|
| CC6.1 protecting access security software and architecture | Flask-AppBuilder authentication layer in front of the Flask and React application and metadata database | Use PostgreSQL or MySQL for the metadata database, set a user-specified SECRET_KEY, and keep local database login for break-glass accounts only | Configuration file under change control, metadata database version record, and documented SECRET_KEY rotation using PREVIOUS_SECRET_KEY |
| CC6.1 restricting authentication to approved identities | OAuth2 and LDAP login backed by Flask-AppBuilder | Point login at your identity provider with OAuth2 (for example Google or Azure) or LDAP, and disable self-registration for local users | Identity provider application configuration and a list of Superset login methods enabled in production |
| CC6.2 registering and authorizing users | Automatic user creation at first SSO login with roles assigned from identity provider groups | Map identity provider groups to Superset roles with AUTH_ROLES_MAPPING, and confirm which groups grant the Admin role | Mapping configuration, the approved group list, and the request or ticket that created each group |
| CC6.3 role-based access and least privilege | Superset role and permission model covering datasets, dashboards, charts and data access | Define custom roles for analyst, viewer and data owner, and remove broad built-in permissions from roles that do not need them | Role export showing permissions per role, with the design decision for each role recorded |
| CC6.3 segregation of duties | Separate administrative roles from content and data access roles | Keep Admin and permission-management rights with a small group, and do not let dashboard authors grant themselves new data access | List of accounts holding administrative roles and the approver for each |
| CC6.3 removing access and reviewing roles | Role and user state held in the metadata database, and access changes made through the identity provider | Deprovision accounts in the identity provider so SSO login stops, and review role membership on a set schedule | Periodic review records comparing role exports with current identity provider groups, and removal tickets |
Evidence Superset produces for an auditor and how to keep it
An auditor testing CC6.1 and CC6.3 will ask who could reach which data, how that changed, and whether the controls worked across the whole period. The cards below cover the artifacts Superset can produce and the schedule that turns one-time exports into evidence for a Type 2 examination.
Role and permission exports
Export the roles, their permissions and the users assigned to each role from the metadata database or the Superset API, then store the output with a timestamp. This is the population an auditor samples when testing whether access matches job function under CC6.3. Check that the export includes custom roles and the Admin role, since those carry the broadest rights. Confirm the export format and field names against your Superset version before you write a procedure around them.
IdP group assignments
When login goes through an identity provider, the group membership that drives role assignment lives in the IdP, not in Superset. Keep a dated copy of the group-to-role mapping configured through AUTH_ROLES_MAPPING, along with the group membership list from the IdP for the same date. Together they show that a person's Superset role traces back to an approved directory group, which is the chain an auditor follows when reviewing CC6.2 and CC6.3 together.
Configuration showing SSO-only login
Keep the `superset_config.py` file, or the configuration source your deployment renders it from, under version control. Evidence for SSO-only login is the absence of local password login and the presence of the OAuth or LDAP settings that enforce it. Record the commit that set these values and any change history. Also retain the SECRET_KEY handling: confirm that it is supplied from a managed secret rather than a default, and that rotation through PREVIOUS_SECRET_KEY is documented.
Logs of permission changes
An auditor will ask for a record of who granted, changed or removed a role and when. Use Superset's event or audit logging where it captures role and user changes, and forward the application and web server logs to a central store if it does not. Confirm which actions are recorded in your version and whether the logs include the acting user, the target and the timestamp. Make sure the log store is outside the Superset host so that an administrator cannot edit the trail.
Scheduled snapshots for Type 2 testing
A Type 2 report tests operating effectiveness over a period, so one export at audit time is not enough. Schedule the role, group and configuration snapshots at a fixed cadence, store them in write-once or access-restricted storage, and name each file by date. Keep a snapshot log showing that each run completed. Set the cadence and retention period with your auditor before the period starts, since the report will test whether the schedule itself ran as designed.
Access review records
The snapshots only become CC6.3 evidence when someone reviews them. Record each periodic review: the reviewer, the date, the population reviewed, the accounts removed or changed, and the approval. Compare each snapshot with the previous one to catch roles that were added without a ticket. Reviewers should be independent of the people whose access they check, which supports the segregation of duties expected under CC6.3.
How SSO-only login and group-based roles fit together
The identity provider should be the only way people sign in to Superset. Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers using the code flow, and LDAP. With SSO in place, the IdP authenticates each user, enforces its own multi-factor and session rules, and passes group membership to Superset. For CC6.1 and CC6.3, the auditor will want to see that the login path is the IdP, and that the groups in the IdP are the source of the roles a user holds. Confirm in your configuration which authentication type is set and whether self-registration is disabled, so that a user cannot create an account outside the IdP flow.
Group membership reaches Superset through AUTH_ROLES_MAPPING, which maps IdP group names to Superset role names. Keep the mapping small and documented: each IdP group should correspond to a named role, and the mapping file should be version-controlled and reviewed like any other access rule. Confirm how your Superset version refreshes roles on each login, because a user removed from a group keeps that role until the next sign-in unless the configuration forces a refresh. Deprovisioning should begin at the IdP: disabling the account or removing the user from the mapped groups must stop new sessions. Test this with a disabled test account and record the result as evidence.
Local password accounts and the built-in admin account sit outside the IdP, so they need a documented exception path. Decide which local accounts must exist for break-glass recovery, who holds their credentials, where those credentials are stored, and what event triggers their use. Each use should be logged and reviewed. Confirm with your Superset version whether local users can still log in when SSO is configured, whether the admin account can be disabled, and how a removed IdP user with an existing local login is handled. Write the answers into the access review procedure before the auditor asks.
What Superset and this configuration do not cover
Superset can produce role exports and logs that feed a SOC 2 examination, but it cannot make the access decisions, run the joiner and leaver process, or prove that controls worked over a period. The cards below mark the boundaries your own team and your CPA firm need to own before the examination starts.
Access review decisions and sign-off
Superset can export roles and users, but it does not decide whether each person still needs their access. Someone accountable must review the export, record which entries were kept or removed, and sign off with a date. Confirm who owns that sign-off, how often it happens, and where the signed record is stored, because an auditor will ask for the review evidence, not the export alone.
Joiner and leaver process outside Superset
Access granted or removed through the identity provider, HR system or ticketing workflow sits outside Superset. A leaver who still has an active identity provider account or a cached session can keep access even after a Superset role is changed. Map the full path from HR event to Superset login, and confirm who removes access and how quickly that happens for each system involved.
Control performance over time
A SOC 2 Type 1 report covers control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. The configuration in this topic can be designed correctly on day one and still drift. Plan recurring role exports, review records and log checks for the whole examination period, and agree the sampling approach with your auditor early.
Monitoring tools beyond Superset logs
CC7.2 asks the organization to monitor system components for anomalies that indicate malicious acts or errors and to decide which are security events. Superset's own logs record activity inside the application, but they do not cover the identity provider, the database, the network or the host operating system. Identify which tools monitor those layers, who reviews their alerts, and how analysts handle events that touch analytics access.
Database privileges and network controls
Superset's roles govern what users can do inside the application, but the service account Superset uses to query each warehouse holds its own privileges. Those database grants, along with network paths under CC6.6 that protect the boundary around Superset, sit with your database and network teams. Confirm that the connection account has read-only scope where possible, and document the firewall and ingress rules that reach the Superset host.
Scope decisions and the CPA examination
A SOC 2 is an examination performed by a CPA firm, and it is not issued by DeployOpen or by any software project. Your organization decides the systems in scope, the Trust Services Categories included, and the description of the system. Apache Superset is released under the Apache License 2.0 with no paid edition, so the cost of the examination is separate from the software. Ask your auditor which evidence they accept before you build the process.
Configuring Superset for CC6.1 and CC6.3 evidence
This sequence sets up Superset so that login, role assignment, access reviews and permission changes each produce records an auditor can test against CC6.1 and CC6.3. It starts with the platform foundations and ends with a staged rehearsal before production.
Fix the secret key and metadata database
The platform engineer sets a deliberate SECRET_KEY in the Superset configuration, since Superset requires one to start (a requirement added in version 2.1.0), and stores it in your secrets manager rather than in the image. Move the metadata database off the SQLite default to PostgreSQL or MySQL, using a version within the range the configuration documentation lists, because the metadata database holds every user, role and permission record you will later export. Done means Superset starts with the production database, the key is recorded in your key inventory, and a test login writes a row to the metadata database.
Connect the identity provider and map groups
The identity engineer configures Superset's OAuth2 or LDAP login against your identity provider, using the Flask-AppBuilder settings in the configuration documentation. Directory groups are then mapped to Superset roles with AUTH_ROLES_MAPPING, so that role membership follows group membership rather than manual assignment. Confirm with your IdP administrator which group names and claims are available before you write the mapping. Done means a test user from each group signs in and receives exactly the role that the mapping defines, and no other.
Remove or restrict local accounts
The Superset administrator disables password logins for everyday users and removes or deactivates local accounts that the identity provider should own, keeping only a small number of documented break-glass administrators. Each retained local account is recorded with its owner, its reason for existing and its review date. Done means a list of all active accounts in the metadata database matches the approved list, and a login attempt with a removed local account fails.
Define role boundaries for least privilege
The security architect and the data owners define which roles may view dashboards, build charts, edit datasets, manage databases and administer users, then assign permissions to those roles only. Admin roles are kept to a named, short list so that the people who can change access are separate from the people who consume analytics, which supports the segregation of duties described in CC6.3. Document each role with its permitted actions and its owner. Done means every role has a written owner and purpose, and a test user in a consumer role cannot open database or user administration pages.
Schedule role and user exports for access reviews
The Superset administrator sets up a recurring export of users, roles, role-to-user assignments and role permissions from the metadata database, through a scheduled query or a script run by your operations team. The export is stored in a location with restricted write access and retained according to your evidence policy. Ask the auditor which review cadence and sample they expect before you fix the schedule. Done means at least one export has run successfully, its contents match the live metadata database, and a reviewer has signed off a sample against the approved role list.
Enable and route change logging
The platform engineer confirms that Superset's event and audit logging captures user and permission changes, then forwards those logs to your central log store with retention that matches your evidence policy. Test each change type you need to evidence, such as granting a role, removing a user and editing a role's permissions, and check that each produces a log record with the actor, the time and the change. Check the current logging options in the configuration documentation for your release, since the exact fields depend on version. Done means a test change for each type appears in the central store and can be searched by actor and date.
Back up the metadata database and rehearse in staging
Before any production change, the platform team takes a backup of the metadata database, following the upgrade guidance in the Superset documentation, and applies the configuration in a staging environment that mirrors production identity settings. The team runs the superset db upgrade and superset init steps where the release requires them and checks the release notes for breaking changes. Done means the staging run reproduces the login, role mapping, export and logging tests, the backup restores successfully into a scratch database, and the change record is approved before production cutover.
Promote to production and capture the baseline
The team repeats the validated configuration in production during an approved change window, then captures a baseline: the role export, the list of active accounts, the SECRET_KEY record and a sample of change log entries. The baseline is stored with the change ticket so that an auditor can compare it with later exports. Done means the production baseline matches the staging results and the first scheduled export has been reviewed and filed.
Questions buyers ask before SOC 2 access control work
What does SOC 2 access control work for Superset cost and what drives the price?
Cost follows the written scope, and DeployOpen does not publish a price list, so the quote is built from the scope agreed in writing before work starts. The main drivers are the number of identity sources to connect (one IdP or several directories), how many roles you need to design and map to CC6.3 least privilege and segregation of duties, how many databases and datasets sit behind Superset and need data access rules, and whether you want logging and access review exports built as part of the work. Ask the quote to separate one-time build work from any recurring support or testing retainer, and to list who performs each task, including what your IdP and audit teams must provide.
How long does a SOC 2 logical access project for Superset take?
Duration depends on what has to be built and how quickly decisions and access are provided, and no fixed timeline applies to every environment. The biggest variables are the state of your identity provider groups, how many roles and row level security rules must be agreed with data owners, the number of metadata database and deployment environments to validate, and how long your team takes to review the role export and access review process. Ask for a written milestone plan with dependencies on your side, including who approves role design and when staging tests happen before any production change.
What does the work need from our team?
Plan on three named contributions: an identity provider administrator who can create groups, configure the OAuth2 or LDAP connection and confirm group membership; an owner of access reviews who can approve role assignments and sign off periodic reviews; and a contact for your SOC 2 auditor who can confirm which evidence the auditor expects and in what format. Data owners also need to confirm which datasets and row level rules reflect their obligations. Ask the vendor to write down these responsibilities in the scope so that delays on your side are visible early.
Can an internal team set up SOC 2 access controls for Superset without a partner?
Yes, a capable internal team can do this if it has the skills and time, and the Superset documentation covers the configuration. The work needs knowledge of Flask-AppBuilder authentication, OAuth2 or LDAP group mapping with AUTH_ROLES_MAPPING, database administration for the metadata database, and enough SOC 2 background to design evidence. Most teams find the hardest part is not the configuration but producing consistent evidence: role exports, change logs and review records that an auditor can trace over a full period. Ask whether your team can run a dry review of the evidence before the audit window starts.
Will DeployOpen's work result in a SOC 2 report?
No. A SOC 2 report is issued by an independent CPA firm after an examination, and DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can prepare the Superset configuration, the role design, the access review procedure and the evidence exports that support the controls, so your organization and auditor have material to test. A Type 1 report describes control design as of a date, and a Type 2 report adds an opinion on operating effectiveness over a period, so the operating evidence must exist over that period. Confirm the report type and the auditor's evidence requirements with them before the build starts.
Does SOC 2 require SSO-only login for Superset?
SOC 2 does not prescribe a specific login method, but CC6.1 and CC6.2 expect access to be registered, authorized and controlled with software and architecture that protects information assets. Routing Superset login through a central identity provider, with local password accounts limited or disabled, is a common way to show that user identities are controlled centrally and that removal happens in one place. Confirm with your auditor how they want local administrator accounts handled, since break-glass accounts usually need their own documented controls.
What evidence should we expect an auditor to test for Superset access?
Expect requests for the list of roles and their permissions, the mapping from identity provider groups to Superset roles, records of who created, changed or removed access and when, and completed periodic access reviews with reviewer sign-off. Logs of permission changes and the monitoring of those logs under CC7.2 may also be requested. The Superset configuration and any audit or event logs must be retained and retrievable for the examination period. Ask your auditor to confirm the sample size, date range and format, because these determine how much evidence must be exported each period.
What the auditor will test and what to prepare
An auditor tests CC6.2 and CC6.3 by sampling people and changes, not by reading your policy alone. For CC6.2, expect the auditor to pick a sample of Superset users and trace each one back to an approved request, an identity record in your identity provider and a documented removal when the person left or changed role. For CC6.3, expect samples of role assignments, role changes and removals, and evidence that someone reviewed the roles and the rules attached to them. The sample period matters. A Type 2 examination covers operating effectiveness over a period, so the auditor will want a population of provisioning and role-change events from that window, not a snapshot taken the week before fieldwork. Confirm with your auditor how many items they will sample and over what period before you decide how long your exports and logs must be kept.
The description of the system is the document the auditor reads first, and it is management's document. Under the AICPA's 2018 description criteria (DC 200), management describes the components of the system, including the infrastructure, software, people, procedures and data, and the controls that address the criteria in scope. For Superset, that description should name the identity provider that authenticates users, how group membership maps to Superset roles, which metadata database holds user and role records, where role exports and audit logs are stored, and who administers each. Any claim you make here must match what the auditor samples. An auditor who finds a local admin account that the description does not mention will treat that as a gap in the description, not only in the control.
The representations you give the auditor are also management's responsibility. Under AT-C section 205, the service auditor obtains written representations from management, and the AICPA illustrative management representation letter for a SOC 2 Type 2 shows the kinds of statements management signs about the system and controls. Before you sign, confirm that each statement about SSO-only login, role design and access reviews is backed by a retrievable artifact. Keep the list of Superset admin accounts, the review records and the log retention settings in a folder the owner of each control can produce on request. Ask your auditor which artifacts they will request so that the representation letter and the evidence set are prepared together rather than reconciled at the end.
How a fixed-scope Superset access control engagement runs
The sequence moves from an agreed written scope to a configured SSO and role model, then to evidence that an auditor can test, and finally to documentation your team can run. Each phase closes with a named output so you can confirm progress before the next one starts.
Agree the written scope and control boundary
Before any configuration begins, DeployOpen and your team agree in writing which Superset instances, databases, datasets and dashboards are in scope, which SOC 2 criteria the work supports (CC6.1, CC6.3 and related series), and who owns each decision. Your compliance lead confirms the system boundary against the system description you already maintain. The step closes with a signed scope document that lists deliverables, assumptions and the items your organization must supply, such as identity provider access and a named approver for role design.
Confirm the current access model and gaps
DeployOpen reviews how users reach Superset today, including any local accounts, shared logins, existing groups in your identity provider and the metadata database that stores users and roles. The output is an inventory of accounts, a list of roles in use and a short gap list showing where logins bypass SSO or where permissions were granted directly to individuals. Your security team checks the inventory against its directory records so that the baseline reflects reality before anything is changed.
Configure SSO-only login and group mapping
DeployOpen configures Superset authentication through your identity provider using the Flask-AppBuilder options the Superset configuration documentation describes, then maps identity provider groups to Superset roles with the role mapping setting. Local password login is disabled for standard users, and the break-glass path for administrators is defined and documented. The step is done when a test user from each group signs in through SSO, receives only the expected role, and a user outside the groups is refused.
Design roles and data access rules
Your data owners and DeployOpen define roles around job function and least privilege, separate administrative roles from analyst and viewer roles, and decide where row level security applies to datasets that need it. The design records who may create, modify and publish content and who may only view it. Segregation of duties is written down for cases where one person should not both administer access and approve their own elevated role. The output is a role matrix that maps each role to its permissions, data scope and approver.
Build evidence for permission changes and logs
DeployOpen sets up the evidence your auditor will request: a repeatable export of users, roles and role assignments from the metadata database, a procedure for capturing identity provider group changes, and confirmation that Superset's logs record permission and login events in a place your team can retain and search. Your team tests that a sample change, such as adding a user to a group or altering a role, appears in the logs with a timestamp and actor. Retention periods are set by your policy, and you should confirm them with your auditor before the work closes.
Document the access review procedure
DeployOpen writes the procedure your team will follow to review access, including the source of each role export, the reviewer for each role, how exceptions are recorded and how removals are carried out and evidenced. The procedure also covers the deprovisioning path when someone leaves, so that removal of a SSO account is reflected in Superset. The step closes with a walkthrough in which your reviewer performs one review using the export and records the result, confirming the procedure works without DeployOpen present.
Hand over documentation and agree handover acceptance
DeployOpen delivers the configuration record, role matrix, evidence procedures, runbook for upgrades that touch authentication, and a list of open items with owners. Your team accepts the handover against the signed scope, and any deviation is recorded in writing. The output is the accepted deliverable set. Whether an auditor accepts the evidence is decided by the auditor, since DeployOpen prepares controls and evidence but does not issue audit reports.
Optionally retain for recurring access reviews
If your organization wants help beyond the fixed scope, DeployOpen can offer a retainer covering recurring role exports, periodic access review support, Superset upgrades and re-testing after identity provider changes. A retainer is a separate written agreement with its own scope and fees, and it is optional. Ask for the service levels and review cadence in writing before you commit, because those terms are set in the agreement rather than in this page.
How DeployOpen scopes, delivers and supports SOC 2 access control evidence
DeployOpen plans, implements, documents and supports self-hosted Superset inside your own infrastructure, so the access model and the evidence it produces stay under your control. We start from the CC6.1 and CC6.3 control descriptions your auditor will test, then build and document only what the written scope agrees to. DeployOpen prepares systems and evidence for the assessment but does not issue the SOC 2 report.
How we scope
- Written scope lists the Superset roles, identity provider connection, dashboards and datasets that fall under CC6.1 and CC6.3.
- Scope names the systems, environments and evidence sources, including the metadata database and log destinations, that the access review will cover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
How we build
- We configure SSO-only login through your identity provider and remove local password logins from the production instance.
- We map identity provider groups to Superset roles with AUTH_ROLES_MAPPING and test each role against documented least privilege.
- We test denied access, role changes and log entries for permission changes, then record the results against each control point of focus.
How we hand over
- You receive a control narrative for CC6.1 and CC6.3, the role matrix, and a runbook for producing role exports and access review packs.
- Documentation states which evidence is generated automatically, which needs a manual export, and who in your team owns each review step.
- Handover includes a walkthrough with your security and compliance leads so they can explain the design to the auditor themselves.
How we support
- Ongoing support and upgrades are available as a retainer, covering role changes, quarterly review support and Superset version upgrades.
- Retainer work can include re-running access tests after upgrades, since the upgrade guide asks teams to back up, test in staging and check UPDATING.md first.
- Confirm with your auditor which evidence format and review period they expect before the first Type 2 observation window begins.
