Apache Superset + Trino: Security Model

Table of Contents

1. Why Superset + Trino Security Matters
2. Understanding the Superset Security Model
3. Trino Authentication and Authorisation
4. Connecting Superset to Trino Securely
5. Row-Level and Column-Level Security
6. Database and Dataset Permissions
7. Operational Security Habits
8. Audit Readiness and Compliance
9. Performance Benchmarks and Trade-Offs
10. Common Pitfalls and How to Avoid Them
11. Next Steps and Implementation

---

Why Superset + Trino Security Matters

Apache Superset and Trino are a potent combination for teams building analytics platforms. Superset provides the front-end, dashboard, and query interface; Trino handles federated query execution across data sources. Together, they let you scale self-service analytics without hiring a BI team per division. But the moment you plug them together, you inherit two security models that must talk to each other.

This matters because a misconfiguration in either layer can expose data to the wrong people, create audit failures, or slow queries to unacceptable speeds. We’ve seen teams ship Superset + Trino in weeks, only to spend months hardening it for SOC 2 or ISO 27001 audits. The goal of this guide is to show you how to build it right the first time.

When you’re running Superset on Trino, security isn’t a single lock—it’s a chain. You need to secure the Superset application layer (who can log in, who can see which dashboards), the Superset-to-Trino connection (how Superset authenticates to Trino), and the Trino query layer itself (what data Trino allows to be queried). If any link breaks, your data is exposed.

For teams modernising analytics infrastructure in Sydney, Melbourne, or across Australia, this pattern is increasingly common. Many organisations we work with at PADISO are replacing per-seat BI tools like Tableau or Looker with Superset + ClickHouse or Superset + Trino, cutting costs by 30–50% while improving query latency. But that cost saving only works if you don’t lose months to security rework later.

---

Understanding the Superset Security Model

Superset’s security model is role-based access control (RBAC) layered on top of feature flags and database-level permissions. It’s flexible but requires deliberate configuration. Here’s what you need to know:

Core Concepts: Roles, Permissions, and Resources

Superset defines security around three primitives:

Roles are collections of permissions. Out of the box, Superset ships with Admin, Alpha, Gamma, and SQL Lab roles. Admin can do everything. Alpha users can explore all data and create dashboards. Gamma users see only dashboards and charts they’re explicitly granted access to. SQL Lab is a role for users who write ad-hoc SQL queries.

Permissions are granular actions: create dashboard, edit dashboard, view dashboard, execute SQL, view dataset, etc. Permissions are bundled into roles, and you can create custom roles with custom permission sets.

Resources are the objects you’re protecting: dashboards, charts, datasets, databases, and SQL queries. When you grant a user access to a dashboard, you’re granting a permission on a specific resource.

The critical detail is that Superset’s permissions are declarative—you tell Superset explicitly which users can see which dashboards. This is different from Trino’s model, which is attribute-based—Trino checks whether a user’s identity attributes (group membership, role) grant them access to a table.

For a detailed breakdown of how Superset implements this, the Roles and Permissions - Apache Superset Documentation is authoritative. It covers permission inheritance, role assignment, and how to grant access to specific charts and dashboards.

Database-Level Access Control

In Superset, you can restrict which databases a user or role can access. This is your first line of defence. If a user isn’t granted access to a database in Superset, they can’t query it, even if Trino would allow it.

To set this up, you go to Settings > Databases, select a database, and under Allowed Roles, you pick which roles can use it. This is a whitelist model: if a role isn’t listed, it can’t access the database.

However—and this is crucial—Superset’s database-level access control is a Superset control. It doesn’t affect Trino directly. If someone gains direct access to your Trino cluster (e.g., via a Trino CLI or a rogue application), Superset’s database restrictions don’t apply. You need to enforce access control at the Trino layer as well.

Feature Flags and Advanced Security

Superset has a FEATURE_FLAGS configuration that controls whether certain security features are enabled. The most relevant flags for Trino deployments are:

• ROW_LEVEL_SECURITY: Enables row-level security (RLS) filters on datasets.
• VERSIONED_EXPORT: Enables versioned exports of dashboards (useful for audit trails).
• ALLOW_ADHOC_SUBQUERY: Controls whether users can write arbitrary subqueries in SQL Lab (security risk if enabled for untrusted users).

For a Superset + Trino deployment in a regulated environment (financial services, healthcare, government), you should set ALLOW_ADHOC_SUBQUERY to False for all but the most trusted roles. This prevents users from writing queries that might expose data you didn’t intend to expose.

---

Trino Authentication and Authorisation

Trino is a distributed SQL query engine, and it has its own authentication and authorisation layer separate from Superset. Understanding this layer is essential because it’s where the actual query execution happens.

Trino Authentication Mechanisms

Trino supports multiple authentication types. The ones most relevant to Superset deployments are:

LDAP/Active Directory: Trino can authenticate users against an LDAP or Active Directory server. This is common in enterprise environments where you have a central identity provider.

OAuth 2.0: Trino can delegate authentication to an OAuth provider (e.g., Google, GitHub, Okta). This is useful if your organisation uses a modern identity platform.

Certificate-based (mTLS): Trino can require client certificates for authentication. This is strong but operationally complex.

Kerberos: Trino can authenticate against Kerberos, common in Hadoop environments.

For detailed information on how to configure these, the Authentication Types - Trino Documentation is the canonical reference.

When you run Superset on Trino, Superset itself must authenticate to Trino. This is typically done via a service account—a dedicated Trino user that Superset uses to connect and execute queries on behalf of your dashboard users.

Trino Authorisation: Access Control Systems

Once a user is authenticated to Trino, Trino checks whether they’re authorised to run the query. Trino supports multiple access control systems:

Default: No access control. Anyone who can authenticate can query anything. Don’t use this in production.

File-based: Trino reads access control rules from a file on disk. This is simple but doesn’t scale well if you have many users or frequently changing rules.

Ranger: Trino can integrate with Apache Ranger, which is an enterprise access control system. Ranger lets you define fine-grained policies (“User X can query Table Y but not Column Z”).

SQL-based: Some Trino distributions (e.g., Starburst) support SQL-based access control, where you define policies in SQL.

For most Superset + Trino deployments, you’ll use either file-based access control (for simplicity) or Ranger (for scale and flexibility).

Principal Propagation vs. Service Account Model

Here’s a critical architectural decision: when Superset queries Trino, should Superset authenticate to Trino as a service account, or should it propagate the end user’s identity to Trino?

Service Account Model: Superset connects to Trino as a single service account (e.g., superset_app). Superset enforces access control (you can’t see this dashboard) and then executes the query as the service account. Trino doesn’t know who the end user is; it only sees the service account.

Principal Propagation Model: Superset passes the end user’s identity to Trino (via a user header or Kerberos delegation). Trino then checks whether that user is authorised to run the query.

The service account model is simpler to operate but requires you to enforce all access control in Superset. If someone bypasses Superset and talks to Trino directly, they might be able to query data they shouldn’t.

The principal propagation model is more secure but requires your identity system and Trino’s access control to be tightly integrated. It’s also more complex to debug when queries fail.

For a regulated environment (SOC 2, ISO 27001), we recommend principal propagation if you have the operational capacity. For a startup moving fast, service account + Superset-level access control is acceptable if you can guarantee that users won’t have direct Trino access.

---

Connecting Superset to Trino Securely

Once you’ve decided on your authentication model, you need to configure the connection from Superset to Trino. This is where many teams make mistakes.

Connection Configuration

In Superset, you add a Trino database by going to Settings > Databases > + Database and selecting Trino. You’ll see a form with fields like:

• Host: The Trino coordinator’s hostname or IP.
• Port: Typically 8080 (HTTP) or 8443 (HTTPS).
• Username: The service account username (if using service account model).
• Password: The service account password (if using service account model).
• Catalog: The Trino catalog (e.g., hive, iceberg).
• Schema: The default schema.

Here’s the security checklist:

1. Always use HTTPS. Set the port to 8443 and ensure Trino has a valid TLS certificate. If you use a self-signed certificate, configure Superset to trust it (via SQLALCHEMY_CUSTOM_PASSWORD_STORE or environment variables).

2. Use a dedicated service account. Don’t use an admin account. Create a Trino user (e.g., superset_app) with minimal permissions—just enough to query the catalogs and schemas you want Superset to access.

3. Store credentials securely. Don’t hardcode passwords in config files. Use environment variables or a secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault). Superset supports loading credentials from environment variables via the connection string.

4. Enable query logging. Configure Trino to log all queries (including the user, query text, and result size). This is essential for audit trails and debugging. You’ll need these logs for SOC 2 audits.

5. Restrict Trino coordinator access. Only Superset should be able to connect to the Trino coordinator. Use network policies (security groups, firewalls) to ensure that Superset’s IP is whitelisted.

For Starburst users, the Apache Superset - Starburst Documentation provides enterprise-grade guidance on connection configuration, including support for OAuth and mTLS.

Connection String Format

Superset uses SQLAlchemy to connect to databases. For Trino, the connection string looks like:

trino://username:password@host:port/catalog/schema

If you’re using environment variables for credentials, you can do:

trino://${TRINO_USER}:${TRINO_PASSWORD}@${TRINO_HOST}:${TRINO_PORT}/catalog/schema

Superset will substitute the environment variables at startup. This is safer than hardcoding credentials.

Testing the Connection

Once you’ve configured the connection, test it by clicking Test Connection in the Superset UI. Superset will attempt to connect to Trino and run a simple query. If it fails, check:

1. Network connectivity: Can Superset reach the Trino host on the specified port?
2. Credentials: Is the username and password correct?
3. Catalog and schema: Do they exist in Trino?
4. TLS certificate: If using HTTPS, is the certificate valid and trusted?

If you’re still stuck, enable debug logging in Superset and check the logs. The Querying Federated Data Using Trino and Apache Superset - Preset blog post has a detailed walkthrough of connection troubleshooting.

---

Row-Level and Column-Level Security

Once users are authenticated and can access a database, the next question is: which rows and columns can they see? This is where row-level security (RLS) and column-level security (CLS) come in.

Row-Level Security (RLS) in Superset

Superset’s RLS feature lets you define filters that are automatically applied to queries based on the user’s attributes. For example, you might have a dataset of sales transactions, and you want each regional manager to see only transactions from their region.

To set up RLS in Superset:

1. Enable the ROW_LEVEL_SECURITY feature flag in your superset_config.py:

   FEATURE_FLAGS = {
       'ROW_LEVEL_SECURITY': True,
   }

2. In the dataset configuration, go to the Row Level Security tab and define a rule. For example:

   • Clause: region = '{region}'
   • User/Role: Select the role or specific user.
   • Filter Value: The value to substitute (e.g., APAC, EMEA).

3. Superset will automatically append this filter to queries run by users in that role. So if a user in the APAC Manager role runs a query on the sales dataset, Superset adds WHERE region = 'APAC' to the query.

The strength of this approach is that it’s transparent to users—they don’t need to know about the filter. The weakness is that it’s Superset-specific. If someone accesses Trino directly, the RLS filter doesn’t apply.

Column-Level Security

Superset doesn’t have native column-level security in the same way some BI tools do. However, you can achieve similar results by:

1. Creating separate datasets: Instead of one customers dataset, create customers_internal (with all columns) and customers_external (with sensitive columns hidden). Grant different roles access to each.

2. Using Trino’s column masking: If you’re using Starburst or a Trino distribution with access control, you can define column masking rules in Trino. When a user without permission queries a column, Trino returns NULL or a masked value. This is more robust than Superset-level masking because it works regardless of how users access Trino.

3. Leveraging SQL views: Create views in Trino that expose only certain columns, then grant roles access to the views instead of the underlying tables.

For most teams, a combination of separate datasets and Trino-level column masking is the right balance of security and simplicity.

RLS Performance Considerations

When you use RLS, Superset injects the filter into the query. This can have performance implications. For example, if your RLS filter is region = 'APAC' and the region column isn’t indexed in Trino, Trino will scan the entire table and then filter. For large tables (billions of rows), this can be slow.

To mitigate:

1. Ensure that columns used in RLS filters are indexed or partitioned in Trino.
2. Use partition pruning: if your table is partitioned by region, Trino can skip entire partitions.
3. Monitor query performance. Set up alerts if queries take longer than expected.
4. Consider materialised views: instead of applying RLS at query time, pre-compute filtered datasets and refresh them periodically.

---

Database and Dataset Permissions

Beyond RLS, Superset has coarser-grained permissions at the database and dataset level. Understanding these is essential for a secure deployment.

Database Permissions

Database-level permissions control which roles can access a database. As mentioned earlier, you configure these in Settings > Databases by selecting a database and specifying Allowed Roles.

This is a whitelist model. If a role isn’t in the Allowed Roles list, users in that role can’t query the database, even if they have other permissions.

Best practice: Create a database entry in Superset for each logical data source. For example:

• analytics_prod (production data, restricted to analysts and managers)
• analytics_dev (development data, open to the analytics team)
• raw_events (raw event stream, restricted to data engineers)

Then assign roles to each database based on who needs access.

Dataset Permissions

Dataset-level permissions are more granular. A dataset is a table (or view) in Trino that you’ve registered in Superset. When you create a dataset, you can specify which roles can view it, edit it, and create charts from it.

To set dataset permissions:

1. Go to Datasets and select a dataset.
2. Click the Permissions tab.
3. Use the Owner field to assign an owner (usually a team or individual responsible for the dataset).
4. Under Roles, add roles that can view or edit the dataset.

Superset has three permission levels for datasets:

• View: Users can see the dataset and create charts from it.
• Edit: Users can modify the dataset definition (e.g., add columns, change the SQL).
• Admin: Users can delete the dataset and change permissions.

Best practice: Assign View permission broadly (to analysts and managers) and Edit permission narrowly (to data engineers and dataset owners). Only admins should have Admin permission.

Chart and Dashboard Permissions

Charts and dashboards inherit permissions from their datasets, but you can also set explicit permissions on individual charts and dashboards.

For dashboards, you can:

1. Set the dashboard owner (usually a team or individual).
2. Grant specific roles view or edit access.
3. Generate a public link (if ENABLE_SHARE_PUBLIC is enabled) for sharing with external stakeholders.

Best practice: Dashboards should have explicit owners. If a dashboard has no owner, it becomes orphaned and hard to maintain. Set up a process where teams designate a dashboard owner (or pair of owners) before publishing.

---

Operational Security Habits

Configuration is one thing; operational discipline is another. Here are the habits that separate secure Superset + Trino deployments from ones that fail audits.

Audit Logging and Monitoring

Superset logs user actions (login, view dashboard, edit chart) to its metadata database. Trino logs queries to its query log. You need to capture both.

For Superset, enable the SQLLAB_QUERY_COST_ESTIMATE_ENABLED and SQLLAB_QUERY_HISTORY_ENABLED flags to ensure that all SQL queries are logged. Configure Superset to send logs to a centralised logging system (e.g., ELK, Splunk, CloudWatch).

For Trino, configure the query log to write to a file or stream (e.g., Kafka, S3). Include the following in each log entry:

• Query text
• User
• Execution time
• Result size
• Success/failure status

Set up alerts for:

• Failed authentication attempts
• Queries that return unexpectedly large result sets
• Queries that take longer than a threshold (e.g., > 5 minutes)
• Access to sensitive datasets outside of business hours

Regular Access Reviews

Quarterly, review who has access to what. This is a requirement for SOC 2 and ISO 27001 audits. Create a spreadsheet with:

• User
• Roles assigned
• Databases accessible
• Datasets accessible
• Dashboards accessible

Cross-check this against your org chart. If someone has left the company, remove their access. If someone’s role has changed, update their permissions.

Automate this if possible. If you use LDAP or Active Directory, configure Superset to sync group membership automatically. This way, when someone leaves, their access is revoked automatically.

Change Management

When you change Superset or Trino configuration (e.g., adding a new role, changing database permissions), document it:

• What changed
• Why it changed
• Who approved it
• When it was deployed

Keep a change log. This is essential for audits. When an auditor asks “Who has access to the customer data?”, you need to be able to answer not just today, but historically.

Secrets Rotation

Rotate credentials regularly. For the Superset service account in Trino, rotate the password every 90 days. For any API keys or tokens, rotate them every 60 days.

When you rotate a credential, do it gracefully:

1. Create a new credential.
2. Update Superset to use the new credential.
3. Test that Superset can connect.
4. Revoke the old credential.

Superset supports loading credentials from environment variables, which makes rotation easier. You can update the environment variable and restart Superset without touching config files.

Incident Response

If you suspect a security incident (e.g., unauthorised access, data exfiltration), you need to:

1. Immediately check Superset and Trino logs for suspicious activity.
2. Identify which data may have been exposed.
3. Notify affected users and stakeholders.
4. Revoke the compromised credential and force a password reset.
5. Document the incident and your response.

Set up a runbook for this. When an incident happens, you don’t want to be figuring out what to do. You want to follow a pre-planned process.

---

Audit Readiness and Compliance

If you’re pursuing SOC 2 or ISO 27001 compliance, Superset + Trino deployments require specific controls.

SOC 2 Considerations

SOC 2 has five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For Superset + Trino, the most relevant are:

Security: You need to demonstrate that access to data is controlled and logged. This means:

• Authentication is enforced (users must log in).
• Authorisation is enforced (users can only access data they’re entitled to).
• Access is logged (all queries are recorded).
• Logs are retained for audit purposes (typically 1–2 years).

Confidentiality: You need to demonstrate that sensitive data is protected. This means:

• Sensitive columns are masked or encrypted.
• Data in transit is encrypted (HTTPS, mTLS).
• Data at rest is encrypted (Trino/Superset database).

Processing Integrity: You need to demonstrate that queries are executed correctly and data isn’t corrupted. This means:

• Query results are validated.
• Data is not modified without authorisation.
• Errors are logged and investigated.

When you’re preparing for a SOC 2 audit, you’ll work with an auditor who will review your Superset and Trino configurations, access logs, and change management process. Having these in place from the start makes the audit much faster and cheaper.

For teams in Australia, the Security Audit | PADISO - SOC 2, ISO 27001 & GDPR Compliance service helps you get audit-ready in weeks. PADISO works with Vanta to automate evidence collection, so you spend less time on paperwork and more time on security.

ISO 27001 Considerations

ISO 27001 is a broader information security management standard. It covers not just access control, but also asset management, supplier management, incident response, and more.

For Superset + Trino, the relevant controls are:

• A.9.1: Access control policy (who can access what)
• A.9.2: User access management (provisioning and deprovisioning)
• A.9.4: Access rights review (quarterly reviews)
• A.12.4: Logging (all access is logged)
• A.14.2: Vulnerability management (Superset and Trino are kept up to date)

ISO 27001 audits are typically annual. You’ll need to demonstrate that you have documented policies and that you’re following them.

GDPR Considerations

If your data includes personal data of EU residents, GDPR applies. Key requirements:

• Data access logs: You must log who accessed personal data and when.
• Data retention: Personal data must not be kept longer than necessary.
• Data deletion: You must be able to delete personal data on request.
• Data protection: Personal data must be protected (encrypted, access-controlled).

Superset + Trino should support all of these, but you need to configure them:

• Enable query logging (to track access).
• Implement data retention policies (delete old data).
• Implement a data deletion workflow (when someone requests deletion, you can delete their data from Trino).

---

Performance Benchmarks and Trade-Offs

Security and performance are often at odds. Here are some benchmarks to help you navigate the trade-offs.

Connection Pooling

When Superset queries Trino, it opens a connection. If you have many concurrent users, opening a new connection for each query can be slow. Connection pooling maintains a pool of open connections that are reused.

Superset uses SQLAlchemy, which supports connection pooling via the SQLALCHEMY_ENGINE_OPTIONS configuration:

SQLALCHEMY_ENGINE_OPTIONS = {
    'pool_size': 10,
    'pool_recycle': 3600,
    'pool_pre_ping': True,
}

• pool_size: Number of connections to maintain in the pool. Typical values: 5–20.
• pool_recycle: Recycle connections after this many seconds (prevents stale connections).
• pool_pre_ping: Test the connection before using it (catches dropped connections).

Benchmark: With connection pooling, query latency decreases by 20–40% compared to opening a new connection for each query.

Query Caching

Superset can cache query results. If two users run the same query within a short time window, the second user gets the cached result instead of running the query again.

Caching is configured in CACHE_CONFIG:

CACHE_CONFIG = {
    'CACHE_TYPE': 'redis',
    'CACHE_REDIS_URL': 'redis://localhost:6379/0',
    'CACHE_DEFAULT_TIMEOUT': 300,
}

Benchmark: With caching, queries that would take 10 seconds to run on Trino return in < 100 ms from the cache.

Trade-off: Cached results are stale. If your data changes frequently, caching can show outdated information. For dashboards that refresh every hour, caching is fine. For real-time dashboards, disable caching or use a short TTL (time-to-live).

RLS Performance

As mentioned earlier, RLS filters can slow queries. Here are benchmarks:

• Indexed column: If the RLS filter is on an indexed column (e.g., user_id), query latency increases by 5–10%.
• Unindexed column: If the RLS filter is on an unindexed column, query latency can increase by 50–200%, depending on table size and selectivity.
• Partition pruning: If the table is partitioned by the RLS filter column, latency increases by < 5%.

Recommendation: Always index or partition columns used in RLS filters.

Concurrent Query Limits

Trino has a maximum number of concurrent queries it can run. If Superset sends too many queries at once, Trino queues them, and latency increases.

Trino’s default is 100 concurrent queries per node. For a 3-node cluster, that’s 300 total. If you have 500 Superset users, and they all run a query at the same time, queries will queue.

To prevent this:

1. Set SUPERSET_SQLLAB_EXECUTION_TIMEOUT to a reasonable value (e.g., 300 seconds). Queries that take longer are killed.
2. Educate users to write efficient queries. Avoid SELECT * and large JOINs.
3. Use query queuing and prioritisation in Trino (if available in your distribution).

---

Common Pitfalls and How to Avoid Them

Pitfall 1: Service Account with Admin Permissions

Problem: You create a Superset service account in Trino with admin permissions. This means if Superset is compromised, the attacker has full access to Trino.

Solution: Create a service account with minimal permissions. In Trino, use role-based access control to grant the service account only the permissions it needs (e.g., SELECT on specific catalogs and schemas).

Pitfall 2: No Audit Logging

Problem: You deploy Superset + Trino but don’t enable logging. Months later, you’re asked to provide an audit trail, and you can’t.

Solution: Enable logging from day one. Configure Superset and Trino to log all queries and access. Send logs to a centralised system where they’re retained for at least 1 year.

Pitfall 3: RLS Filters on Unindexed Columns

Problem: You implement RLS on a large table, but the filter column isn’t indexed. Queries become very slow.

Solution: Before implementing RLS, ensure that the filter column is indexed or the table is partitioned by that column.

Pitfall 4: Hardcoded Credentials

Problem: You hardcode the Superset service account password in the connection string. The password is checked into version control and exposed to everyone with repo access.

Solution: Use environment variables or a secrets manager. Never commit credentials to version control.

Pitfall 5: No Access Reviews

Problem: Over time, users accumulate permissions. Someone who left the company still has access. Someone who changed roles still has permissions from their old role.

Solution: Quarterly, review all user permissions and remove unnecessary access. Automate this if possible by syncing with your identity provider.

Pitfall 6: Superset-Only Access Control

Problem: You rely entirely on Superset for access control. Users can’t access Trino directly, so you think you’re secure. But if someone finds a way to talk to Trino directly (e.g., via a Trino CLI or a rogue application), they bypass all your controls.

Solution: Implement access control at both the Superset and Trino layers. Use principal propagation or ensure that Trino’s access control is enforced regardless of how queries arrive.

---

Next Steps and Implementation

If you’re building a Superset + Trino deployment, here’s a practical roadmap:

Phase 1: Foundation (Weeks 1–2)

1. Set up Superset and Trino in a development environment.
2. Configure authentication (LDAP, OAuth, or local accounts).
3. Create a service account for Superset in Trino.
4. Test the connection from Superset to Trino.
5. Enable audit logging in both systems.

Phase 2: Access Control (Weeks 3–4)

1. Define roles (Admin, Analyst, Manager, Viewer, etc.).
2. Assign permissions to roles in Superset.
3. Restrict database and dataset access by role.
4. Implement RLS for sensitive datasets.
5. Test access control (verify that each role can see only what they should).

Phase 3: Hardening (Weeks 5–6)

1. Enable HTTPS for Superset and Trino.
2. Configure TLS certificates.
3. Implement connection pooling and caching.
4. Set up alerts for suspicious activity.
5. Create a change management process.

Phase 4: Compliance (Weeks 7–8)

1. Document your security model.
2. Set up quarterly access reviews.
3. Create an incident response runbook.
4. If pursuing SOC 2 or ISO 27001, work with an auditor or use a service like PADISO’s Security Audit to get audit-ready.

Ongoing

1. Monitor logs for suspicious activity.
2. Keep Superset and Trino up to date.
3. Rotate credentials every 90 days.
4. Review access quarterly.
5. Test incident response annually.

Getting Help

If you’re in Australia or building a regulated analytics platform, teams at PADISO have shipped dozens of Superset + Trino deployments for financial services, government, and health. We specialise in platform development across Australia, including Sydney, Melbourne, and Canberra.

If you need help with configuration, hardening, or audit readiness, we offer fractional CTO and platform engineering support. We also work with teams in the United States, Canada, and New Zealand on similar deployments.

For a security-focused build, we recommend starting with Platform Development in Sydney if you’re in Australia, or a regional office if you’re elsewhere. Our team can review your architecture, implement access control, and help you pass audits.

For compliance-specific support, PADISO’s Security Audit service pairs you with Vanta to automate evidence collection and get you SOC 2 and ISO 27001 audit-ready in weeks.

---

Summary

Apache Superset + Trino is a powerful combination for self-service analytics, but security requires deliberate configuration across multiple layers:

1. Superset layer: RBAC, database and dataset permissions, RLS.
2. Connection layer: HTTPS, service accounts, credential management.
3. Trino layer: Authentication, authorisation, access control.
4. Operational layer: Logging, monitoring, access reviews, change management.

The teams that ship secure deployments quickly are those that plan for security from the start, not as an afterthought. They enable logging, document access control, and review permissions quarterly. When an audit comes, they’re ready.

This guide has given you the patterns, benchmarks, and habits to build a secure Superset + Trino deployment. Use it as a checklist as you build, and you’ll avoid the months of rework that many teams face when they try to retrofit security later.

For detailed reference information, the Roles and Permissions - Apache Superset Documentation and Authentication Types - Trino Documentation are authoritative. For practical guidance on Superset + Trino integration, the Querying Federated Data Using Trino and Apache Superset - Preset blog is excellent.

If you’re building in a regulated industry or pursuing compliance, reach out to a team that’s done it before. Security is too important to guess on.