Apache Superset + ClickHouse: Security Model

Table of Contents

1. Why Security Matters for Superset + ClickHouse
2. Authentication and Access Control
3. Network and Transport Security
4. Data Encryption and Privacy
5. Configuration Patterns and Hardening
6. Audit Logging and Observability
7. Operational Security Habits
8. SOC 2 and ISO 27001 Readiness
9. Common Pitfalls and Fixes
10. Summary and Next Steps

---

Why Security Matters for Superset + ClickHouse {#why-security-matters}

Apache Superset and ClickHouse are a powerful pairing for analytics at scale. Superset provides the dashboarding and user-facing layer; ClickHouse delivers the sub-second query performance on massive datasets. But when you combine them, you’re exposing sensitive data through a web interface to potentially dozens or hundreds of users. Security isn’t optional—it’s foundational.

The security model for Superset + ClickHouse spans multiple layers: how users authenticate to Superset, how Superset connects to ClickHouse, how data moves between them, who can see what, and how you audit and log everything. Get any of these wrong, and you’ll fail a SOC 2 or ISO 27001 audit. Get them right, and you’ll ship faster, sleep better, and pass compliance on the first attempt.

This guide walks you through the practitioner decisions: which authentication method to use, how to configure role-based access control (RBAC), encryption patterns, network topology, and the operational habits that keep your stack secure in production. We’ve built this stack for financial services, insurance, and healthcare teams in Australia and across North America—teams that can’t afford security failures.

---

Authentication and Access Control {#authentication-access-control}

Superset Authentication Layer

Superset sits between your users and ClickHouse. Every user accessing a dashboard must first authenticate to Superset. You have several options:

LDAP / Active Directory. If your organisation runs on corporate identity (Windows AD, Okta, Azure AD), bind Superset to LDAP or use a vendor-specific connector. This is the fastest path to role-based access and audit trails. Users log in with their corporate credentials; Superset queries LDAP groups to determine which dashboards and datasets they can access. No password management overhead. Audit logs show which user accessed what, and when.

OAuth 2.0 / OpenID Connect. For teams using Okta, Auth0, or cloud-native identity, OAuth is cleaner than LDAP. Superset can delegate authentication to your identity provider. Users see a single sign-on (SSO) flow. Your identity provider becomes the source of truth for user management, MFA, and audit logs. This is especially valuable if you’re running Superset in a containerised environment (Kubernetes, Docker Swarm) and want to avoid managing user credentials directly.

Database-backed authentication. Superset ships with built-in user management. Don’t use this in production unless you have no other option. It requires you to manage passwords, enforce rotation, and audit access manually. If you go this route, enforce strong password policies, require MFA, and log every login attempt.

For a typical mid-market or enterprise deployment, use OAuth 2.0 with your existing identity provider. For teams on-premises or behind corporate firewalls, LDAP is the standard.

Role-Based Access Control (RBAC) in Superset

Once a user is authenticated, Superset’s RBAC determines what they can see. The model is straightforward:

• Roles map to user groups (e.g., finance-team, data-engineers, executives).
• Permissions are assigned to roles (e.g., view_dashboard, edit_dataset, execute_query).
• Row-level security (RLS) restricts which rows of data a user can see based on their identity or role.

In practice, you’ll create roles like:

• viewer: Can see published dashboards, cannot modify anything.
• editor: Can create and edit dashboards, create datasets from existing tables.
• admin: Can manage users, roles, and system settings.
• data-engineer: Can create and modify datasets, write SQL, manage connections.

When you connect Superset to ClickHouse, you configure a database connection with a specific user credential (e.g., a read-only ClickHouse user). Superset queries ClickHouse using that credential. Every query runs with the same permissions—the ClickHouse user that Superset is configured to use.

This is a critical security boundary: the ClickHouse user credential used by Superset must be read-only and scoped to the databases and tables that Superset needs to access. If your Superset instance is compromised, the attacker can only read the tables Superset is allowed to read, not drop tables, modify data, or access unrelated databases.

ClickHouse User and Quota Configuration

ClickHouse has its own authentication and authorisation layer. When Superset connects to ClickHouse, it authenticates using a username and password (or certificate-based auth, which we’ll cover later).

Create a dedicated ClickHouse user for Superset:

CREATE USER superset_readonly
IDENTIFIED BY 'strong-random-password-here'
DEFAULT ROLE NONE;

Then grant it permissions only on the databases and tables Superset needs:

GRANT SELECT ON analytics.* TO superset_readonly;
GRANT SELECT ON reporting.* TO superset_readonly;

Do not grant INSERT, UPDATE, DELETE, ALTER, or DROP permissions. Superset only needs to read data.

Also set query limits to prevent runaway queries from consuming all resources:

ALTER USER superset_readonly
QUOTA default
QUERIES PER HOUR 10000
RESULT BYTES 10000000000;

These quotas prevent a single Superset instance from overwhelming ClickHouse. If a user runs a query that would exceed the quota, ClickHouse rejects it. This is your circuit breaker.

---

Network and Transport Security {#network-transport-security}

TLS/SSL for Superset ↔ ClickHouse Communication

Superset and ClickHouse communicate over HTTP or HTTPS. Use HTTPS (TLS 1.2 or higher) in production. Period.

When you configure the ClickHouse connection in Superset, you specify a connection string like:

clickhouse://user:password@host:8443/database?ssl=true

The ssl=true parameter tells Superset’s ClickHouse driver to use TLS. ClickHouse must be configured to listen on port 8443 (or another HTTPS port) with a valid certificate.

If you’re running ClickHouse in a container or on a cloud provider (AWS, Azure, GCP), use managed certificates. If you’re running it on-premises, use a certificate from your internal CA or a public CA like Let’s Encrypt.

Verify the certificate chain: ensure Superset can validate ClickHouse’s certificate against a trusted root CA. If you’re using self-signed certificates (not recommended for production), you can disable certificate verification in Superset, but this opens you to man-in-the-middle (MITM) attacks. Only do this in development or if the connection is already isolated on a private network.

Network Isolation and Firewalling

Superset and ClickHouse should run on the same network or a tightly controlled network segment. If Superset is public-facing (users access it over the internet), it should not have direct network access to ClickHouse. Instead, use a firewall or security group to restrict traffic:

• Superset instances can initiate outbound connections to ClickHouse on port 8443 (or your configured port).
• ClickHouse does not initiate connections to Superset.
• No other systems can connect to ClickHouse from outside the Superset network segment.

If you’re deploying on AWS, use security groups:

ClickHouse Security Group:
  Inbound:
    - Protocol: TCP
      Port: 8443
      Source: Superset Security Group
  Outbound:
    - All traffic to 0.0.0.0/0 (or restrict as needed)

Superset Security Group:
  Inbound:
    - Protocol: TCP
      Port: 8088 (or your configured port)
      Source: 0.0.0.0/0 (or your corporate network)
  Outbound:
    - Protocol: TCP
      Port: 8443
      Destination: ClickHouse Security Group

On Kubernetes, use NetworkPolicy to enforce similar rules. On-premises, use iptables, UFW, or your firewall appliance.

Certificate-Based Authentication

For high-security environments (financial services, healthcare, government), use certificate-based authentication instead of username/password. ClickHouse supports mTLS (mutual TLS): both Superset and ClickHouse present certificates to each other.

Generate certificates for both Superset and ClickHouse. Configure ClickHouse to require client certificates:

<clickhouse>
  <https_port>8443</https_port>
  <openSSL>
    <server>
      <certificateFile>/etc/clickhouse-server/certs/server.crt</certificateFile>
      <privateKeyFile>/etc/clickhouse-server/certs/server.key</privateKeyFile>
      <caConfig>/etc/clickhouse-server/certs/ca.crt</caConfig>
      <verificationMode>strict</verificationMode>
      <loadDefaultCAFile>true</loadDefaultCAFile>
    </server>
    <client>
      <certificateFile>/etc/clickhouse-server/certs/client.crt</certificateFile>
      <privateKeyFile>/etc/clickhouse-server/certs/client.key</privateKeyFile>
      <caConfig>/etc/clickhouse-server/certs/ca.crt</caConfig>
      <verificationMode>strict</verificationMode>
      <loadDefaultCAFile>true</loadDefaultCAFile>
    </client>
  </openSSL>
</clickhouse>

In Superset, configure the ClickHouse connection to use client certificates. Superset’s Python ClickHouse driver supports this via connection parameters.

Certificate-based auth is more complex to set up and manage (you need a certificate authority, certificate rotation, etc.), but it’s stronger than passwords and is often required for SOC 2 and ISO 27001 audits.

---

Data Encryption and Privacy {#data-encryption-privacy}

Encryption in Transit

We’ve covered TLS for Superset ↔ ClickHouse. Also encrypt data in transit between users and Superset. Run Superset behind an HTTPS reverse proxy (nginx, HAProxy, AWS ALB). Use HTTP Strict Transport Security (HSTS) headers to force browsers to use HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Encryption at Rest

ClickHouse stores data on disk. Encrypt the disk using your cloud provider’s encryption (AWS EBS encryption, Azure Disk Encryption, GCP persistent disk encryption) or file-system level encryption (LUKS, dm-crypt on Linux).

For highly sensitive data, consider encrypting individual columns in ClickHouse using the encrypt function. ClickHouse supports AES encryption:

CREATE TABLE sensitive_data (
  id UInt64,
  encrypted_ssn String,
  encrypted_dob String
) ENGINE = MergeTree() ORDER BY id;

INSERT INTO sensitive_data
SELECT
  1,
  encrypt('aes-256-cbc', 'ssn-value', 'encryption-key-here'),
  encrypt('aes-256-cbc', 'dob-value', 'encryption-key-here');

When Superset queries this table, it gets encrypted data. You’ll need to decrypt it in the application layer (Superset or a middleware service). This adds latency but provides an extra layer of protection if someone gains access to the ClickHouse data files directly (e.g., via a backup).

Personally Identifiable Information (PII) and Data Minimisation

If your dashboards contain PII (names, email addresses, phone numbers, SSNs, etc.), minimise what’s exposed:

1. Aggregate and anonymise. Instead of showing individual customer records, show aggregated metrics: “100 customers in region X”, “average order value $Y”. This is often all you need for business intelligence.
2. Mask sensitive fields. Use ClickHouse functions to mask PII: substring(email, 1, 3) || '***@***' to show only the first few characters of an email.
3. Restrict access. Use Superset’s row-level security to ensure only authorised users see PII. For example, a support agent can only see customer records they’re assigned to.
4. Audit access. Log every query that touches PII. If a user accesses sensitive data, you should know why.

---

Configuration Patterns and Hardening {#configuration-patterns}

Superset Configuration Best Practices

Superset ships with a superset_config.py file. Here are critical security settings:

# Enable HTTPS only
PREFER_HTTPS = True
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = 'Lax'

# Set a strong secret key (generate with os.urandom(24))
SECRET_KEY = 'your-strong-random-key-here'

# Enable CSRF protection
WTF_CSRF_ENABLED = True
WTF_CSRF_CHECK_DEFAULT = True

# Set session timeout (in seconds)
PERMANENT_SESSION_LIFETIME = 3600  # 1 hour

# Disable debug mode in production
DEBUG = False
TESTING = False

# Configure OAuth or LDAP for authentication
AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = {
    'okta': {
        'name': 'Okta',
        'token_url': 'https://your-okta-domain.okta.com/oauth2/v1/token',
        'authorization_url': 'https://your-okta-domain.okta.com/oauth2/v1/authorize',
        'client_id': 'your-client-id',
        'client_secret': 'your-client-secret',
    }
}

# Enforce strong password policies (if using database auth)
PASSWORD_SECURITY_CONFIG = {
    'ENFORCE_SQLALCHEMY_URI_SECURITY': True,
    'SQLALCHEMY_DATABASE_URI': 'postgresql://...',
}

# Enable Content Security Policy (CSP)
TACKY_ENABLED = True
TACKY_CONFIG = {
    'CSP_HEADER': "default-src 'self'; script-src 'self' 'unsafe-inline'; ..."
}

# Log all SQL queries
LOGGING_CONFIG = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'standard': {
            'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s'
        },
    },
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/var/log/superset/superset.log',
            'formatter': 'standard',
        },
    },
    'loggers': {
        'superset': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

ClickHouse Configuration Best Practices

ClickHouse’s configuration lives in /etc/clickhouse-server/config.xml. Key security settings:

<clickhouse>
  <!-- Listen only on localhost and private network -->
  <listen_host>::1</listen_host>
  <listen_host>10.0.0.0/8</listen_host>
  <!-- Do not listen on 0.0.0.0 (all interfaces) -->

  <!-- HTTPS port -->
  <https_port>8443</https_port>

  <!-- Disable HTTP in production -->
  <!-- <http_port>8123</http_port> -->

  <!-- Require authentication -->
  <default_user_name>default</default_user_name>
  <default_password>strong-random-password</default_password>

  <!-- Enable SSL/TLS -->
  <openSSL>
    <server>
      <certificateFile>/etc/clickhouse-server/certs/server.crt</certificateFile>
      <privateKeyFile>/etc/clickhouse-server/certs/server.key</privateKeyFile>
      <verificationMode>strict</verificationMode>
    </server>
  </openSSL>

  <!-- Log all queries -->
  <query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>toYYYYMM(event_time)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
  </query_log>

  <!-- Disable remote execution -->
  <allow_execute_query>false</allow_execute_query>

  <!-- Set query timeout -->
  <max_query_size>262144</max_query_size>
  <default_max_execution_time>300</default_max_execution_time>

  <!-- Enable query result caching (reduces load) -->
  <query_result_cache>
    <max_size_in_bytes>1073741824</max_size_in_bytes>
    <max_entries>1024</max_entries>
  </query_result_cache>
</clickhouse>

Secrets Management

Never hardcode credentials in configuration files. Use a secrets manager:

• AWS Secrets Manager or Parameter Store if you’re on AWS.
• Azure Key Vault if you’re on Azure.
• HashiCorp Vault for on-premises or multi-cloud.
• Kubernetes Secrets if you’re running on Kubernetes.

For example, with AWS Secrets Manager:

import boto3

secrets_client = boto3.client('secretsmanager')
secret = secrets_client.get_secret_value(SecretId='superset/clickhouse')
clickhousePassword = json.loads(secret['SecretString'])['password']

Rotate secrets regularly (every 90 days is a common standard). Automated rotation is better than manual.

---

Audit Logging and Observability {#audit-logging}

Query Logging in ClickHouse

ClickHouse logs every query to the system.query_log table. This is your audit trail. Query logs include:

• The SQL query text.
• The user who executed it.
• The timestamp.
• Query duration.
• Bytes read and written.
• Exception messages (if the query failed).

Query logs are essential for compliance audits. You need to be able to prove who accessed what data and when.

Enable query logging in ClickHouse config (we showed this above). Then regularly export logs to a secure, immutable store:

SELECT
  event_time,
  user,
  query,
  query_duration_ms,
  bytes_read,
  bytes_written,
  exception
FROM system.query_log
WHERE event_date >= today() - 7
ORDER BY event_time DESC
FORMAT JSONEachRow
INTO OUTFILE '/var/log/clickhouse/query_audit.jsonl';

Then ship these logs to a centralised logging system (ELK Stack, Datadog, CloudWatch, Splunk). Don’t rely on ClickHouse’s local disk for audit logs—if the server is compromised, logs can be deleted.

Superset Audit Logging

Superset logs user actions to the ab_audit_log table (if using Flask-AppBuilder). Enable this:

LOG_ALL_DB_QUERIES = True
LOG_ALL_USER_ACTIVITY = True

Superset logs:

• User logins and logouts.
• Dashboard views.
• Query execution.
• Changes to dashboards, datasets, and alerts.

Export these logs regularly to a centralised system. Use the Security Audit service at PADISO to understand what audit logs you need for SOC 2 and ISO 27001 compliance.

Centralised Logging with ELK Stack

If you’re building a production analytics platform, set up a centralised logging system. The ELK Stack (Elasticsearch, Logstash, Kibana) is a popular choice.

Ship logs from both Superset and ClickHouse:

# Logstash configuration
input {
  file {
    path => "/var/log/superset/superset.log"
    type => "superset"
  }
  file {
    path => "/var/log/clickhouse/query_audit.jsonl"
    type => "clickhouse"
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "logs-%{+YYYY.MM.dd}"
  }
}

In Kibana, create dashboards to monitor:

• Queries by user.
• Failed authentication attempts.
• Slow queries (> 5 seconds).
• Queries that touch sensitive tables.
• Data access patterns (who’s accessing what).

Monitoring and Alerting

Set up alerts for security events:

• Failed login attempts. If a user fails to log in 5+ times in 10 minutes, lock the account and alert the security team.
• Unusual query patterns. If a user suddenly runs 100x more queries than usual, alert the team.
• Access to sensitive tables. If someone queries a PII table, log it and alert if it’s outside business hours.
• Certificate expiration. If a TLS certificate is expiring in 30 days, alert the ops team.
• Quota violations. If a user hits their query quota, log it and alert.

---

Operational Security Habits {#operational-habits}

Regular Security Patching

Superset and ClickHouse release security patches frequently. Stay on top of them:

• Subscribe to the Apache Superset security mailing list.
• Subscribe to ClickHouse release notes.
• Patch within 2 weeks of a security release.
• Test patches in a staging environment first.

For containerised deployments, automate patching with tools like Dependabot or Renovate. For on-premises, set up a patch management process.

Access Reviews

Quarterly, review who has access to what:

1. Export the list of Superset users and their roles.
2. Export the list of ClickHouse users and their permissions.
3. For each user, verify they still need access.
4. Remove users who’ve left the organisation or changed roles.
5. Document the review and keep records for compliance audits.

Incident Response

Plan for security incidents:

1. Compromised credentials. If a Superset or ClickHouse password is leaked, rotate it immediately. Audit logs to see if the attacker accessed anything.
2. Unauthorised data access. If you detect unusual query patterns, investigate. Check who ran the query, what data they accessed, and when.
3. Data breach. If sensitive data is exposed, notify affected users within 30 days (GDPR requirement). Notify your legal and compliance teams.
4. Service unavailability. If Superset or ClickHouse goes down, have a runbook to restore from backups and resume operations.

Document your incident response plan and test it annually.

Backup and Disaster Recovery

Back up ClickHouse regularly:

# Daily backup to S3
clickhouse-backup create --schema --data
clickhouse-backup upload

Test restores quarterly. A backup you can’t restore from is worthless.

For Superset, back up:

• The PostgreSQL database (which stores dashboards, datasets, users).
• Configuration files.
• Custom plugins or extensions.

Dependency Management

Both Superset and ClickHouse depend on third-party libraries. Vulnerabilities in dependencies can compromise your system.

Use tools like:

• Snyk to scan Python dependencies (Superset).
• Dependabot to scan Node.js dependencies (Superset frontend).
• Trivy to scan container images for vulnerabilities.

Run these tools in your CI/CD pipeline. Block deployments if high-severity vulnerabilities are detected.

---

SOC 2 and ISO 27001 Readiness {#compliance-readiness}

SOC 2 Type II and ISO 27001 are the gold standards for data security. Both require you to demonstrate that you have controls in place to protect data confidentiality, integrity, and availability.

For a Superset + ClickHouse stack, you’ll need to show:

Access Control (SOC 2 CC6, ISO 27001 A.9)

• Users authenticate with strong credentials (OAuth, LDAP, or MFA).
• Role-based access control is enforced (users can only see data they’re authorised to see).
• Access is reviewed quarterly and unused access is revoked.
• Privileged users (admins) are logged and monitored.

Evidence you’ll need:

• Screenshots of Superset RBAC configuration.
• Quarterly access review reports.
• Audit logs showing who accessed what and when.
• MFA configuration documentation.

Data Protection (SOC 2 CC7, ISO 27001 A.10)

• Data in transit is encrypted (TLS 1.2+).
• Data at rest is encrypted (EBS encryption, LUKS, or column-level encryption).
• Encryption keys are managed securely (AWS KMS, Azure Key Vault, or Vault).
• PII is minimised and masked.

Evidence you’ll need:

• TLS certificate configuration.
• Encryption key management policy.
• Data classification document (which tables contain PII).
• Screenshots of masking rules in Superset or ClickHouse.

Audit and Accountability (SOC 2 CC7, ISO 27001 A.12)

• All queries are logged (ClickHouse query_log).
• All user actions are logged (Superset audit_log).
• Logs are retained for at least 1 year.
• Logs are protected from tampering (immutable storage).
• Logs are reviewed regularly for anomalies.

Evidence you’ll need:

• Query log export (sample of 1 month).
• Audit log export (sample of 1 month).
• Log retention policy documentation.
• Screenshots of centralised logging (ELK, Datadog, etc.).
• Incident response logs (if any security incidents occurred).

Vulnerability Management (ISO 27001 A.12.6)

• Software is patched within 2 weeks of security releases.
• Dependencies are scanned for vulnerabilities (Snyk, Trivy).
• Vulnerability scan results are reviewed and remediated.

Evidence you’ll need:

• Patch management policy.
• Dependency scan reports (monthly).
• Vulnerability remediation tickets.
• Version history of Superset and ClickHouse deployments.

To accelerate SOC 2 and ISO 27001 readiness, use PADISO’s Security Audit service. We work with Vanta to automate evidence collection, so you spend less time gathering screenshots and more time shipping features.

---

Common Pitfalls and Fixes {#common-pitfalls}

Pitfall 1: Superset Connecting to ClickHouse with a Super-User Account

Problem: You configure Superset to connect to ClickHouse using the default user (which has all permissions). If Superset is compromised, the attacker can modify or delete data.

Fix: Create a read-only user for Superset and grant it permissions only on the databases and tables it needs to access.

CREATE USER superset_readonly IDENTIFIED BY 'password';
GRANT SELECT ON analytics.* TO superset_readonly;

Pitfall 2: Storing ClickHouse Credentials in Superset Configuration Files

Problem: The connection string is hardcoded in superset_config.py or in the database. If the server is compromised, the attacker has the credentials.

Fix: Use a secrets manager (AWS Secrets Manager, Vault, etc.). Load credentials at runtime.

Pitfall 3: No Encryption Between Superset and ClickHouse

Problem: Superset and ClickHouse communicate over HTTP (port 8123). An attacker on the network can sniff queries and see sensitive data.

Fix: Enable HTTPS (port 8443) and use TLS 1.2 or higher.

Pitfall 4: ClickHouse Listening on 0.0.0.0 (All Interfaces)

Problem: ClickHouse is accessible from anywhere on the internet. An attacker can brute-force credentials or exploit vulnerabilities.

Fix: Configure ClickHouse to listen only on localhost or a private network:

<listen_host>::1</listen_host>
<listen_host>10.0.0.0/8</listen_host>

Pitfall 5: No Audit Logging

Problem: You can’t prove who accessed what data. If a data breach occurs, you can’t investigate.

Fix: Enable query logging in ClickHouse and audit logging in Superset. Export logs to a centralised system.

Pitfall 6: Passwords in Logs

Problem: Superset or ClickHouse logs include the connection string with the password. An attacker who gains access to logs can extract credentials.

Fix: Configure logging to redact sensitive information. In Superset, use the SQLALCHEMY_ECHO_POOL setting to disable connection pool logging.

Pitfall 7: Expired TLS Certificates

Problem: Your TLS certificate expires. Superset can’t connect to ClickHouse. Users can’t access dashboards.

Fix: Use automated certificate management (Let’s Encrypt with certbot, AWS Certificate Manager). Set up alerts for certificate expiration 30 days before renewal.

Pitfall 8: No Rate Limiting

Problem: An attacker or a buggy application floods Superset with requests. The service becomes unavailable.

Fix: Implement rate limiting at the reverse proxy (nginx, HAProxy) and in Superset itself. Limit queries per user, per IP, per hour.

---

Summary and Next Steps {#summary-next-steps}

Securing Superset + ClickHouse requires attention to multiple layers: authentication, network, encryption, audit logging, and operational practices. Here’s a checklist:

Immediate Actions (Week 1)

• Enable HTTPS between Superset and ClickHouse.
• Create a read-only ClickHouse user for Superset.
• Enable query logging in ClickHouse.
• Configure OAuth or LDAP for Superset authentication.
• Set up a secrets manager (AWS Secrets Manager, Vault) and rotate all passwords.

Short-Term Actions (Month 1)

• Implement role-based access control (RBAC) in Superset.
• Enable audit logging in Superset.
• Set up centralised logging (ELK, Datadog, CloudWatch).
• Create a patch management process for Superset and ClickHouse.
• Perform an initial access review (who has access to what).

Medium-Term Actions (Quarter 1)

• Implement row-level security (RLS) for sensitive data.
• Set up monitoring and alerting for security events.
• Document your incident response plan.
• Test backup and disaster recovery procedures.
• Scan dependencies for vulnerabilities (Snyk, Trivy).

Long-Term Actions (Ongoing)

• Quarterly access reviews.
• Annual security assessment.
• SOC 2 Type II or ISO 27001 audit preparation.
• Dependency updates and patching.
• Security training for your team.

If you’re building a Superset + ClickHouse stack for a regulated industry (financial services, healthcare, insurance), or if you need to pass SOC 2 or ISO 27001, consider engaging PADISO’s Platform Development team. We’ve built secure analytics platforms for dozens of teams across North America and Australia. We can help you design the architecture, implement security controls, and prepare for compliance audits.

For financial services teams in Australia, we also offer AI and financial services expertise aligned with APRA, ASIC, and AUSTRAC requirements. For insurance teams, we provide specialised guidance on claims automation and conduct risk.

If you need help with platform engineering in your region—whether it’s San Francisco, New York, Toronto, or elsewhere—we have dedicated teams. We can also support fractional CTO and technical leadership as you scale.

Start with the immediate actions. Get the basics right (HTTPS, read-only users, audit logging). Then layer in the more sophisticated controls (RLS, centralised logging, monitoring). Security is a journey, not a destination. Build incrementally, test regularly, and audit continuously.