Audit logging in Apache Superset

Why audit logging in Apache Superset needs a plan before go-live

An auditor or security team will eventually ask a simple question: who accessed which dashboard, ran which query and changed which database connection, and when. Answering that question after go-live is much harder than designing for it before, because Superset records what it is configured to record, and the retention and shipping decisions have to be made early. Superset includes an Action Log, which writes user actions to the metadata database, and it lets you attach a custom event logger, a Python class that receives events and can forward them to your own destination. The exact event names, the fields each event carries and the configuration keys that enable or replace the logger differ between releases, so confirm them against the Superset version you run in the configuring Superset documentation before you write any logging code.

Teams usually need this work for three reasons: regulated data that must be traceable to individual users, onboarding to a SIEM that should receive Superset events alongside identity and database logs, and periodic access reviews that need evidence of who could see or change what. Each reason sets a different requirement. A SIEM feed needs a stable event format and a delivery path that survives restarts. An access review needs a clear mapping from events to users, roles and objects. A regulator may ask how long records are kept and who can alter them, which points at the metadata database, its backups and its access controls. Ask your security team to list the questions they must answer before you choose a design.

Superset has no paid edition, so the cost of this work is the configuration, shipping and retention design, along with the engineering time to write and test the logger and the SIEM parsing. Those costs are largely one-time, while log storage, SIEM ingestion and periodic review recur, and they grow with user count and query volume. When you request a quote, ask for the event inventory to be confirmed against your version, the destination and format agreed with your SIEM team, the retention period written down, and the verification steps that prove an action produces the expected record.

Which logging option fits which audit question

This table compares the ways to record Superset activity, including the sign-in and proxy layers around it, and shows which audit questions each one answers, what it misses and how much effort it takes to run. Read each row against the questions your auditors ask, then use the misses column to decide what to add. Items marked for verification should be confirmed in the Superset configuration documentation before you commit to a design.

Logging option	Audit questions it answers	What it misses	Effort to run
Built-in Action Log	Which user changed a dashboard, chart or database connection, and when	Full query text and result access. Confirm which views and actions it covers in the configuration documentation.	Low to start. Events are stored in the metadata database, so retention and backups become your responsibility.
Custom event logger	Specific events the built-in log skips, such as chosen queries, exports or permission checks	Anything your code does not hook. Coverage must be retested after each Superset upgrade.	Moderate to high. Python code to write, test, document and carry forward through upgrades.
Shipping events to a SIEM	Cross-system timelines linking an identity provider sign-in, a Superset action and a warehouse query	Events Superset never emits. Field names and formats must be confirmed per release and parsed.	Moderate. Log forwarding, parsing rules, retention and alert logic are owned by your security team.
Database-level query logs	Which database account ran which SQL and how much data it read	The Superset user behind the query when connections share one service account.	Depends on the database engine. Enabling, storage and retention are handled on the database side.
Proxy and web server access logs	Requests by time, source IP and endpoint, including failed sign-in attempts	What the application did with a request, such as which dataset returned rows to the user.	Low if the proxy already logs. Confirm that the authenticated user identity reaches the log.
Identity provider sign-in logs	Who authenticated, from which location and whether multifactor authentication was used	Any activity after sign-in, including dashboard views, queries and exports inside Superset.	Usually provided by the identity system. Confirm export to your SIEM and retention period.

Setting up event logging and SIEM shipping step by step

This sequence turns Superset's built-in action logging into a defined audit trail: you decide what must be recorded, capture it, prove it reaches the metadata database and the log view, forward it to your SIEM, and set how long it is kept.

Confirm the Superset release and logging options
The platform team records the exact Superset version in use and reads the configuration reference for that release to find the logging settings it supports, including the action logger and any event logger hook. Do this before editing anything, because logging keys and class paths have changed between releases and the documentation for your version is the only reliable source. Confirm also which metadata database you run, since the audit trail is stored there by default and must be backed up with it. Done when the version, the logging keys and the metadata database engine are written in the change record and checked against the documentation for that release.
Define the audit questions and required fields
Security, compliance and the data owners agree on the questions the log must answer, such as who viewed a dashboard, who ran which query against which database, and who changed a role, dataset or database connection. For each question, list the fields needed to answer it: user, timestamp, action, object identifier, source address, and where available the SQL text or query identifier. Mark which events must be retained and which can be sampled or excluded. Done when the field list is signed off and every field can be traced to a question that an auditor or investigator will ask.
Enable the Action Log or a custom event logger
An engineer enables the built-in Action Log in the Superset configuration file and, where the required fields are missing, adds a custom event logger class that writes the extra attributes. Keep custom code small, test it in a non-production instance, and store the configuration under version control. Restart the web and worker processes so the settings load. Done when the application starts cleanly and a single test action, such as opening a dashboard, produces a log entry without errors in the application logs.
Verify events in the metadata database and log view
The engineer performs a set of known actions with a test account, then queries the log table in the metadata database to confirm each action appears with the expected user, action name and object reference. Next, opens the built-in log view in the Superset interface as an administrator and checks that the same events are listed and filterable. Record any action that is missing or shows an unexpected user. Done when every test action in the plan appears in both the database table and the log view, and any gaps are documented with a planned fix.
Configure log shipping to the SIEM
Because Superset writes events to the metadata database, shipping them to a SIEM usually means exporting new rows on a schedule or using a logging hook that sends events to a collector. Choose the method your team can operate, confirm the SIEM ingestion format and time zone, and set the export cursor so each event is sent once and none are skipped after a failure. The service account used for export should have read access to the log table only. Done when a test event appears in the SIEM with the same fields and timestamp as in the metadata database.
Test shipping with known user actions
Run a scripted set of actions with named test users: sign in, open a dashboard, run a chart query, export data, change a dataset, and attempt an action without permission. Compare the events in the metadata database, the log view and the SIEM for each action. Check that failed attempts are recorded where your policy requires it, and that delayed or retried exports do not create duplicate events. Done when a written test record shows each scripted action matched across all three locations.
Set retention for logs and backups
Set a retention period for the log table in the metadata database and a separate period in the SIEM, both taken from your audit policy rather than from a default. Schedule a purge job that deletes only rows already confirmed as exported, and include the log table in the metadata database backup and restore tests. Ask your auditor which retention periods they expect and document the answer. Done when the retention settings are written in the audit standard, a purge test removes only exported rows, and a restore test confirms the log table is recovered.

When the Action Log is enough and when a custom event logger is needed

If the question is who opened a dashboard, who changed a chart or which teams are active, the built-in Action Log often answers it. It records user actions inside Superset and can be read by users with the right permissions, so it suits internal reporting where no external system depends on the records.

Field mapping: Confirm which fields each entry stores, such as user, timestamp, action name and the object touched, and whether those names are stable enough to build reports on.
Identity attribution: Check that the user field holds a meaningful identity. Shared accounts or local users created outside your single sign-on setup make entries harder to attribute to a person.
Failed attempts: Do not assume failed logins or denied access appear in the Action Log. Confirm this on your version before promising it to anyone.
Export and query events: Confirm whether CSV exports, downloads and SQL Lab queries appear as separate entries, and whether the query text is stored with them.

Before relying on the Action Log for reporting, sign in as each role, perform a fixed set of test actions and confirm that every one appears with the expected user and object.

When a security team needs to join Superset events with identity provider logins, network logs or warehouse query logs, the built-in log is a weak transport. The events must leave the application in a structured form, which usually means a custom event logger configured in superset_config.py that forwards each record to your log pipeline.

Structured field mapping: Define a schema before writing code. Include an event name, a UTC timestamp, a user identifier, the client address, the dashboard or chart identifier, the database connection and the result status.
Identity attribution through SSO: Use the identifier your identity provider issues so that SIEM rules can join Superset events to directory logins. Local usernames rarely match directory identifiers.
Failed attempts and denials: Correlation rules often depend on authentication failures and permission denials. Confirm whether your Superset version passes these to the logger, and add them yourself if it does not.
Delivery reliability: Decide what happens when the SIEM is unreachable. Buffering, retries and a count of dropped events should be part of the design.

Test the pipeline end to end with a known test user, and confirm that one action produces the same identifier in Superset, the identity provider and the SIEM.

Security risks in Superset audit trails

An audit trail is only as useful as its weakest link. The risks below cover what gets recorded, who can alter it, whether it survives outages and whether the people reading it can be trusted with what it contains. Each card names a mitigation you can verify in your own environment before auditors ask.

Identity missing under SSO and guest access

When users sign in through an identity provider or reach dashboards as embedded guests, the event record may show a shared service account or a generic guest identity instead of the person. This breaks the link between an action and an accountable user. Before go-live, sign in as several test users through each login path, run a view, a query and a dashboard edit, and confirm each event names the individual. Check that group-to-role mapping does not hide who acted.

Sensitive values inside query text

Logged SQL can contain customer identifiers, account numbers or filter values typed directly into a query. Once written to the metadata database or a SIEM, those values are copied into every downstream store and backup. Decide which fields a custom event logger may record, and review a sample of captured events against your data classification. Restrict who can read raw query text, and document any masking you apply before shipping.

Tampering by metadata database administrators

The Action Log lives in the same metadata database that administrators of Superset can change. Anyone with database write access can edit or delete rows without leaving a trace inside Superset. Mitigate this by shipping events off the host to a store that the Superset administrators cannot modify, limiting direct database write access to a small named group, and alerting on deletes or truncation of the log table. Confirm who holds those rights today.

Gaps during log shipper outages

If the log shipper, network path or SIEM collector stops, events may be dropped or held only in memory on the web or worker tier. Recovery then leaves a silent hole in the record that looks like no activity. Test an outage on purpose: stop the collector for a defined window, perform known actions, then confirm they appear after recovery. Ask whether your shipper buffers to disk and how it resumes after a restart.

Over-broad access to the log view

The built-in log view shows user activity across the whole instance, which can expose who looked at which dashboards and which data they queried. Granting the Admin role or a broad custom role to analysts gives them that visibility by default. Limit access to the log view to a named audit or security group, review that group on the same schedule as other administrative roles, and confirm that ordinary users cannot reach the view through direct URLs.

Inconsistent clocks across tiers

Web servers, Celery workers and the metadata database can each stamp events with their own clock. When those clocks drift, a single user session can appear out of order, and investigators may reconstruct the wrong sequence. Synchronize every tier and the database host to the same time source, record the timezone in the shipped event, and check drift during your outage test. Document which clock is authoritative for your audit timeline.

Keeping the built-in log view working after upgrades and changes

The built-in log view depends on the metadata database schema and on whatever logger the instance is configured to use, so every upgrade or schema change can break it or make it appear empty. Treat the log view as a regression test item in each upgrade cycle, not as something that will keep working by default. The Superset upgrade documentation tells operators to back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes between versions. For this topic, the staging test should open the Action Log view, filter by a known user and a known date range, and confirm that a deliberate test action (a dashboard view, a chart save and a SQL Lab query) appears with the expected user and timestamp.

Take the metadata database backup before any schema change, not after. The log entries live in the same metadata database as dashboards, users and connections, so a failed migration can damage the audit trail along with everything else. Keep the pre-upgrade backup until the post-upgrade staging test has passed and the production log view has been checked. Confirm with your DBA how the backup is retained and whether it is kept under the same access controls as the live audit data, since the backup is itself a copy of who did what in the instance.

If you ship events with a custom event logger, check after every version change that it still writes to the table you expect. The built-in view and your custom logger are separate paths: an upgrade can leave the view working while your logger stops writing, or the reverse. Confirm the logger class path in EVENT_LOGGER still resolves, that the target table name and columns match what your SIEM forwarder reads, and that new event types introduced in the release are either captured or deliberately excluded. Because the Superset documentation does not describe logger compatibility across releases in the material reviewed here, confirm this behavior against the UPDATING.md notes and your own test instance rather than assuming it carries over.

Limits to confirm in your environment

The Action Log and any custom event logger depend on the Superset version, the metadata database and how your users sign in. The items below are the points to verify on your own deployment before you promise auditors or a SIEM team a complete trail.

Events the chosen version records

Event coverage changes between releases, so the list of actions the Action Log writes for views, queries, chart saves and dashboard edits should be checked against the exact version you plan to run, not against older guides. Test each action your auditors care about on a staging instance and record what appears in the logs table. Treat any action you cannot see as a gap to close with a custom event logger, not as an assumption that it is covered.

Query text and parameters

Confirm whether the logged event for a query stores the SQL text, the bound parameters, the database connection used and the result size, or only the fact that a query ran. Queries built from filters, Jinja templates or row level security may store the rendered text rather than what the user typed, which changes what an investigator can reconstruct. Also confirm how long query text is kept, since it can contain sensitive values.

Logs table retention and growth

The Action Log lives in the metadata database, so every event adds rows to the same database that holds dashboards and users. Ask who owns pruning, how long events must be kept under your retention policy, and how the table grows under your real usage. Plan the backup size and restore test around that table, and confirm the database version you use is supported.

Attribution with shared or embedded access

An event is only as useful as the user it names. If several people share one login, if service accounts run scheduled reports, or if embedded dashboards use guest access, the log may show one identity for many people. Decide how to tie events to a person, through individual accounts, SSO identity or a correlation field in your application, and test each access path before relying on the trail.

SIEM parser and schema fit

Confirm that the fields your exporter or log shipper emits match what your SIEM parser expects, including timestamps, user identifiers, action names and object IDs. Event names and columns can change between Superset versions, which can break parsing rules without any error on the Superset side. Ask your SIEM team to validate a sample export from staging before you turn on production shipping.

Whether the approach needs project support

A custom event logger changes application code, so ask whether your approach depends on an extension point the project documents and supports, or on internal code that may move in a future release. Also ask whether any change needs a statement from the Superset project before you rely on it in an audit. Keep the custom code in version control and list it in your upgrade test plan.

How much does audit logging in Apache Superset cost and take to set up?

Does Apache Superset audit logging cost anything in licensing?

No license fee applies to the software itself. Apache Superset is released under the Apache License 2.0 and the project has no paid edition, so the cost of audit logging comes from configuration, SIEM integration, testing, storage and ongoing review. Those costs fall on whoever does the work: your own staff, a partner you pay under a fixed-scope agreement, or a mix. Your SIEM vendor may charge for ingestion volume, and that charge is separate from Superset itself. Confirm your SIEM licensing terms for the event volume you expect before you commit to a design.

What makes audit logging take longer or cost more?

Effort rises with the number of audit questions you need answered, because each question may need its own event, field mapping and test. The main drivers are:

The number of distinct audit questions (who viewed, who queried, who changed which dashboard or connection).
SIEM onboarding, including parsing, field naming, dashboards and alert rules in the tool your security team already runs.
SSO attribution, since events are only useful if they name the real person behind a shared or federated login.
Retention rules and storage, which set how much history you keep and where.

Each driver grows with the size of your deployment and the number of teams whose activity must be traceable.

Can our internal team set up Superset audit logging without a partner?

Often yes, if your team already runs Superset and a SIEM and has someone who can write a small custom event logger in Python. The work is bounded: define the events, attach user identity, send them to your log pipeline and verify them in staging. The harder part is agreeing what must be recorded, how long it is kept and who reviews it, which usually needs compliance and security staff as well as engineers. Ask yourself whether you have capacity to test the logger across upgrades, since Superset releases change internal code paths.

What do we need to provide before a fixed-scope audit logging quote?

A quote depends on a written scope, so prepare these inputs first:

Access to your SIEM, including the ingestion endpoint, index or pipeline owner and the parsing rules already in use.
A data classification for the dashboards, datasets and databases Superset connects to, so events for sensitive data get the right handling.
The Superset version, deployment method (container, PyPI or Helm), metadata database (PostgreSQL or MySQL) and where logs currently go.
Your identity setup, including whether logins go through OAuth2, LDAP or another provider, since this affects user attribution.
Your retention and review requirements, agreed with compliance.

What should a fixed-scope audit logging quote include?

Ask for the scope in writing before work starts. A useful quote lists the events covered, the Superset version and deployment it applies to, the SIEM target and parsing work, the identity attribution approach, the test cases used in staging, and the handover documentation. Ask which items are one-time work and which recur, such as reviewing log volume after upgrades or updating the logger for a new Superset release. Also ask what is excluded, for example SIEM licensing, new SIEM content beyond the agreed alerts, or retention decisions that your compliance team must make.

What recurring costs follow audit logging after go-live?

Recurring cost is mostly operational. Storage and SIEM ingestion grow with event volume and retention length, so both should be reviewed as usage changes. Each Superset upgrade needs a check that events still fire and carry the right fields, because the upgrade guide tells operators to back up, test in staging and read UPDATING.md for breaking changes. Someone also needs to review the logs on the schedule your policy sets. Ask a partner whether post-go-live support is a separate retainer and whether upgrade checks are included.

Does audit logging need a compliance assessment to be complete?

Setting up audit logging prepares evidence and controls, but it does not certify your environment. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports or certifications. Independent auditors and certification bodies make that determination. Ask your auditor early which events and retention periods they expect to see, because late changes to logging scope add effort and cost to both the build and the review.

How DeployOpen scopes and delivers Superset audit logging

DeployOpen treats Superset audit logging as a defined piece of work: which events matter, where they go, and who can read them. We agree the scope in writing, build and test the logging path in your own infrastructure, and hand over documentation your security and operations teams can run without us.

How we scope

Inventory the Superset actions your auditors and security team need to see, such as views, queries and changes to dashboards, datasets and roles.
Confirm the Superset version and whether the Action Log or a custom event logger will carry each event type.
Agree in writing where events are stored, which SIEM receives them, retention expectations and the owner of each log source.

How we build

Configure the Action Log and any custom event logger in a staging Superset, then test each required event end to end.
Ship events to your SIEM over the transport your team approves, and verify field names, timestamps and user identities arrive intact.
Check that the built-in log view still works after changes and that the metadata database holding log rows is sized and backed up.

How we hand over

Provide a runbook listing each logged event, its source, its destination and the test that proves it is recorded.
Document configuration keys, file locations and the steps to change logging after a Superset upgrade.
Walk your operations and security staff through alert triage on the logs and the procedure for evidence requests.

How we support

Fixed-scope engagements close with written acceptance of the agreed deliverables and tests.
Ongoing support for upgrades, log pipeline changes and periodic checks is available as a retainer, scoped in writing.
Re-test logging after each Superset upgrade, reviewing the upgrade notes for changes that affect event recording.