Version 3.0

Security — Superset

ChartVersion3.0.1TypeapplicationAppVersion5.0.0

CompatibilityKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Overview

The tdp-superset chart concentrates security in three main areas.
The first is SUPERSET_SECRET_KEY, used by Superset to protect sessions, cookies, and sensitive data persisted in the metadata database.
The second is protection for metadata PostgreSQL credentials, including the Secret managed by the chart and the administrative Secret used by external bootstrap.
The third is LDAP authentication, configured through the tdp-superset.ldap block and integrated with Superset role mapping.

The practical idea is simple: the key protects the application's internal state, PostgreSQL stores metadata, and LDAP controls who can log in.
When LDAP or external PostgreSQL is active, treat Secrets, passwords, and network dependencies as deployment prerequisites.

Operating Modes

The chart can operate with internal Superset users or LDAP authentication.
This difference is mainly controlled by tdp-superset.ldap.enabled and the initialization values in tdp-superset.init.

Mode	`tdp-superset.ldap.enabled`	Authentication	Users and roles
Internal users	`false`	Login managed by Superset	Initial user created by the `tdp-superset.init` block
LDAP	`true`	Login through the LDAP directory	Users registered according to `ldap.registration.*` and roles mapped by `ldap.roleMapping`

With LDAP disabled, the initial administrator user comes from the tdp-superset.init block.
This mode is useful for simple installation, controlled tests, or environments where access is restricted by another layer.

With LDAP enabled, Superset uses the corporate directory as the authentication provider.
In this mode, the Secret containing the bind user password must exist before deployment, and roles must be planned to avoid broad permission grants.

Prerequisites

Strong SUPERSET_SECRET_KEY defined before the first deploy.
LDAP bind Secret created in the namespace when tdp-superset.ldap.enabled: true.
LDAP server reachable from the Superset namespace when LDAP is used.
Metadata PostgreSQL reachable and administrative Secret available when using an external database.
Network and exposure policies configured to limit access to the Superset interface.

SUPERSET_SECRET_KEY

The tdp-superset.extraSecretEnv.SUPERSET_SECRET_KEY key is required.
Superset uses this key to encrypt sessions, cookies, and sensitive data persisted in the metadata database.
Generate a value with adequate entropy and inject it through a Kubernetes Secret or a secrets management tool.
Do not store this key in plain text in version control.

Model command to generate a value:

openssl rand -base64 42

Rotating this key without a plan invalidates active sessions and data previously encrypted with the old value.
Treat it with the same care as an infrastructure password.

Metadata PostgreSQL

The chart manages a Secret for the Superset metadata database user password.
The Secret name and key are controlled by tdp-superset.postgresqlSecrets.name and tdp-superset.postgresqlSecrets.passwordKey.

When TDP-Settings.externalDatabase.enabled=true, the bootstrap job generates the password automatically and stores it in the Secret.
Model command to inspect the generated Secret:

kubectl -n <NAMESPACE> get secret <RELEASE_NAME>-postgresql-secrets -o jsonpath='{.data.superset-postgresql-password}' | base64 -d

For external PostgreSQL, the db-create-job job reads the administrator password from a Secret named according to TDP-Settings.externalDatabase.externalSecret.releaseName with the key postgres-password.
This Secret must exist in the namespace before the install or upgrade hook runs.
The default Secret name is tdp-postgresql.

LDAP Enabled

LDAP is used by Superset as an authentication provider.
In the chart, enabling LDAP replaces exclusive use of the internal user database with login through the corporate directory.

Before enabling LDAP, create the Secret containing the bind user password in the Superset namespace:

kubectl -n <NAMESPACE> create secret generic tdp-superset-ldap-secret --from-literal=bind-password=<LDAP_BIND_PASSWORD>

Configuration model:

tdp-superset:
  ldap:
    enabled: true
    server:
      url: "ldap://<LDAP_HOST>:389"
      useTls: "False"
    bind:
      user: "cn=<LDAP_BIND_USER>,cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com"
      passwordSecret:
        name: "tdp-superset-ldap-secret"
        key: "bind-password"
    search:
      base: "cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com"
      filter: "(objectClass=person)"
      uidField: "uid"
    userAttributes:
      firstname: "givenName"
      lastname: "sn"
      email: "mail"
    registration:
      enabled: "True"
      defaultRole: "Public"
    roleMapping:
      "cn=superset_admins,cn=groups,cn=accounts,dc=<LDAP_DOMAIN>,dc=com": ["Admin"]
      "cn=superset_users,cn=groups,cn=accounts,dc=<LDAP_DOMAIN>,dc=com": ["Gamma", "Alpha"]
    groupField: "memberOf"
    roleSyncAtLogin: "True"

Replace placeholders before installing.
<LDAP_HOST> is the LDAP address as seen from inside the cluster.
<LDAP_BIND_USER> is the account used by Superset to search users and groups.
<LDAP_DOMAIN> represents the DN components of the directory.
<LDAP_BIND_PASSWORD> must be stored only in the Secret.

To disable LDAP and return to internal users, set tdp-superset.ldap.enabled: false and remove LDAP-specific configuration.
After the upgrade, validate that the expected internal login still exists and that exposure policies remain restricted.

Group and Role Mapping

The ldap.roleMapping parameter maps directory groups to Superset roles.
The key is the full DN of the group in LDAP; the value is a list of Superset roles.

Native Superset roles: Admin, Alpha, Gamma, Public.
Use Gamma as defaultRole for read-only access to dashboards.
Use Alpha for users who create charts and datasets.
Use Admin only for controlled administrative groups.

With ldap.roleSyncAtLogin: "True", the user's roles are recalculated on every login based on LDAP groups.
Directory changes, such as adding or removing groups, are reflected in Superset without manual intervention.

Main Parameters

Parameter	Role	Default	When to change
`tdp-superset.extraSecretEnv.SUPERSET_SECRET_KEY`	Application cryptographic key	placeholder	Always set before the first deploy
`tdp-superset.init`	Initial admin user creation	chart values	Installations without LDAP or initial bootstrap
`tdp-superset.postgresqlSecrets.name`	Metadata database password Secret name	`""`	When using a custom Secret
`tdp-superset.postgresqlSecrets.passwordKey`	Password key inside the Secret	`superset-postgresql-password`	When the Secret uses another key
`TDP-Settings.externalDatabase.enabled`	Enable external PostgreSQL bootstrap	`false`	Environments with a shared database
`TDP-Settings.externalDatabase.externalSecret.releaseName`	PostgreSQL admin Secret name	`tdp-postgresql`	When the admin Secret follows another pattern
`tdp-superset.ldap.enabled`	Enable LDAP authentication	`false`	Environments with corporate authentication
`tdp-superset.ldap.server.url`	LDAP server URL	`ldap://<LDAP_HOST>:389`	When using another host, port, or LDAPS
`tdp-superset.ldap.bind.passwordSecret.*`	Secret with bind user password	`tdp-superset-ldap-secret` / `bind-password`	When using another Secret or key
`tdp-superset.ldap.search.*`	Base, filter, and login attribute	environment LDAP values	Always adapt to the corporate directory
`tdp-superset.ldap.registration.*`	Auto-registration and default role	`True` / `Public`	To control the initial user profile
`tdp-superset.ldap.roleMapping`	Map LDAP groups to roles	`{}`	Environments with group-based RBAC
`tdp-superset.ldap.roleSyncAtLogin`	Sync roles on login	`True`	When roles must reflect LDAP changes

Troubleshooting

Situation	What to check
Pods do not start	`SUPERSET_SECRET_KEY` is set and has no extra spaces
Init job fails	DB host, password, and admin Secret `<RELEASE_NAME>` with key `postgres-password`
Internal user login fails	`tdp-superset.init` block with admin user in the values file
LDAP login fails	LDAP URL, bind DN, Secret `tdp-superset-ldap-secret`, and connectivity
LDAP user not found	`ldap.search.base`, `ldap.search.filter`, and `ldap.search.uidField`
Wrong role after login	`ldap.roleMapping`, group DNs, and `ldap.roleSyncAtLogin: "True"`
LDAP enabled but has no effect	Confirm `ldap.enabled: true` and bind Secret created before deploy

When switching from internal users to LDAP, create the bind Secret before helm upgrade.
Then validate login, user attributes, and role mapping.

When switching from LDAP back to internal users, confirm that a valid local admin user exists and review interface exposure.

Best Practices

Do not store the LDAP bind password or SUPERSET_SECRET_KEY in version control.
Rotate credentials after the first production deployment.
Use Public or Gamma as defaultRole to prevent inadvertent admin access for new LDAP users.
Prefer secretKeyRef in extraEnvRaw instead of literal values in extraEnv.
Restrict service exposure with NetworkPolicy and use Ingress only when required.
For LDAPS (port 636), set ldap.server.url to ldaps:// and ldap.server.useTls: "True".

Overview​

Operating Modes​

Prerequisites​

SUPERSET_SECRET_KEY​

Metadata PostgreSQL​

LDAP Enabled​

Group and Role Mapping​

Main Parameters​

Troubleshooting​

Best Practices​