Versão 3.0

Segurança — Superset

ChartVersion3.0.1TypeapplicationAppVersion5.0.0

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

Visão geral

O chart tdp-superset concentra a segurança em três frentes principais.
A primeira é a SUPERSET_SECRET_KEY, usada pelo Superset para proteger sessões, cookies e dados sensíveis persistidos no banco de metadados.
A segunda é a proteção das credenciais do PostgreSQL de metadados, incluindo o Secret administrado pelo chart e o Secret administrativo usado no bootstrap externo.
A terceira é a autenticação LDAP, configurada pelo bloco tdp-superset.ldap e integrada ao mapeamento de roles do Superset.

A ideia prática é simples: a chave protege o estado interno da aplicação, o PostgreSQL guarda os metadados e o LDAP controla quem entra.
Quando LDAP ou PostgreSQL externo estiverem ativos, trate Secrets, senhas e dependências de rede como pré-requisitos do deploy.

Modos de operação

O chart pode operar com usuários internos do Superset ou com autenticação LDAP.
Essa diferença é controlada principalmente por tdp-superset.ldap.enabled e pelos valores de inicialização em tdp-superset.init.

Modo	`tdp-superset.ldap.enabled`	Autenticação	Usuários e roles
Usuários internos	`false`	Login gerenciado pelo Superset	Usuário inicial criado pelo bloco `tdp-superset.init`
LDAP	`true`	Login via diretório LDAP	Usuários registrados conforme `ldap.registration.*` e roles mapeadas por `ldap.roleMapping`

Com LDAP desabilitado, o usuário administrador inicial vem do bloco tdp-superset.init.
Esse modo é útil para instalação simples, testes controlados ou ambientes onde o acesso é restrito por outra camada.

Com LDAP habilitado, o Superset usa o diretório corporativo como provedor de autenticação.
Nesse modo, o Secret com a senha do usuário de bind precisa existir antes do deploy, e as roles devem ser planejadas para evitar concessão ampla de permissões.

Pré-requisitos

SUPERSET_SECRET_KEY forte definida antes do primeiro deploy.
Secret de bind LDAP criado no namespace quando tdp-superset.ldap.enabled: true.
Servidor LDAP acessível a partir do namespace do Superset quando LDAP for usado.
PostgreSQL de metadados acessível e Secret administrativo disponível quando usar banco externo.
Políticas de rede e exposição configuradas para limitar acesso à interface do Superset.

SUPERSET_SECRET_KEY

A chave tdp-superset.extraSecretEnv.SUPERSET_SECRET_KEY é obrigatória.
O Superset usa essa chave para criptografar sessões, cookies e dados sensíveis persistidos no banco de metadados.
Gere um valor com entropia adequada e injete via Secret do Kubernetes ou ferramenta de gestão de segredos.
Não versione essa chave em texto claro.

Modelo para gerar um valor:

openssl rand -base64 42

Rotacionar essa chave sem planejamento invalida sessões ativas e dados já cifrados com o valor anterior.
Trate-a com o mesmo rigor de uma senha de infraestrutura.

PostgreSQL de metadados

O chart gerencia um Secret para a senha do usuário de banco de metadados do Superset.
O nome e a chave do Secret são controlados por tdp-superset.postgresqlSecrets.name e tdp-superset.postgresqlSecrets.passwordKey.

Quando TDP-Settings.externalDatabase.enabled=true, o job de bootstrap gera a senha automaticamente e a armazena no Secret.
Modelo para consultar o Secret gerado:

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

Para PostgreSQL externo, o job db-create-job lê a senha do administrador em um Secret com o nome <RELEASE_NAME> e a chave postgres-password.
Esse Secret precisa existir no namespace antes do hook de instalação ou atualização.
O nome do Secret é definido por TDP-Settings.externalDatabase.externalSecret.releaseName (padrão tdp-postgresql).

LDAP habilitado

LDAP é usado pelo Superset como provedor de autenticação.
No chart, habilitar LDAP substitui o uso exclusivo do banco interno de usuários por login no diretório corporativo.

Antes de habilitar LDAP, crie o Secret com a senha do usuário de bind no namespace do Superset:

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

Modelo de configuração:

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"

Substitua os placeholders antes de instalar.
<LDAP_HOST> é o endereço do LDAP visto de dentro do cluster.
<LDAP_BIND_USER> é a conta usada pelo Superset para pesquisar usuários e grupos.
<LDAP_DOMAIN> representa os componentes do DN do diretório.
<LDAP_BIND_PASSWORD> deve ser armazenado apenas no Secret.

Para desabilitar LDAP e voltar ao modo de usuários internos, defina tdp-superset.ldap.enabled: false e remova a configuração LDAP específica.
Depois do upgrade, valide se o login interno esperado ainda existe e se as políticas de exposição continuam restritas.

Mapeamento de grupos e roles

O parâmetro ldap.roleMapping mapeia grupos do diretório para roles do Superset.
A chave é o DN completo do grupo no LDAP; o valor é uma lista de roles do Superset.

Roles nativas do Superset: Admin, Alpha, Gamma, Public.
Use Gamma como defaultRole para acesso somente leitura a dashboards.
Use Alpha para usuários que criam gráficos e datasets.
Use Admin apenas para grupos administrativos controlados.

Com ldap.roleSyncAtLogin: "True", as roles do usuário são recalculadas a cada login com base nos grupos do LDAP.
Mudanças no diretório, como adicionar ou remover grupos, se refletem no Superset sem intervenção manual.

Parâmetros principais

Parâmetro	Papel	Padrão	Quando alterar
`tdp-superset.extraSecretEnv.SUPERSET_SECRET_KEY`	Chave criptográfica da aplicação	placeholder	Sempre definir antes do primeiro deploy
`tdp-superset.init`	Criação do usuário admin inicial	valores do chart	Instalações sem LDAP ou bootstrap inicial
`tdp-superset.postgresqlSecrets.name`	Nome do Secret da senha do banco de metadados	`""`	Quando usar Secret próprio
`tdp-superset.postgresqlSecrets.passwordKey`	Chave da senha dentro do Secret	`superset-postgresql-password`	Quando o Secret usar outra chave
`TDP-Settings.externalDatabase.enabled`	Habilita bootstrap de PostgreSQL externo	`false`	Ambientes com banco compartilhado
`TDP-Settings.externalDatabase.externalSecret.releaseName`	Nome do Secret admin do PostgreSQL	`tdp-postgresql`	Quando o Secret admin tiver outro nome
`tdp-superset.ldap.enabled`	Habilita autenticação LDAP	`false`	Ambientes com autenticação corporativa
`tdp-superset.ldap.server.url`	URL do servidor LDAP	`ldap://<LDAP_HOST>:389`	Quando usar outro host, porta ou LDAPS
`tdp-superset.ldap.bind.passwordSecret.*`	Secret com senha do usuário de bind	`tdp-superset-ldap-secret` / `bind-password`	Quando usar outro Secret ou chave
`tdp-superset.ldap.search.*`	Base, filtro e atributo de login	valores LDAP do ambiente	Sempre ajustar ao diretório corporativo
`tdp-superset.ldap.registration.*`	Auto-registro e role padrão	`True` / `Public`	Ao controlar perfil inicial de usuários
`tdp-superset.ldap.roleMapping`	Mapeia grupos LDAP para roles	`{}`	Ambientes com RBAC por grupos
`tdp-superset.ldap.roleSyncAtLogin`	Sincroniza roles no login	`True`	Quando roles devem refletir alterações no LDAP

Solução de problemas

Situação	O que verificar
Pods não sobem	`SUPERSET_SECRET_KEY` definida e sem espaços extras
Init job falha	Host DB, senha e Secret admin `<RELEASE_NAME>` com a chave `postgres-password`
Login com usuários internos falha	Bloco `tdp-superset.init` com usuário admin no arquivo de valores
Login LDAP falha	URL LDAP, DN de bind, Secret `tdp-superset-ldap-secret` e conectividade
Usuário LDAP não encontrado	`ldap.search.base`, `ldap.search.filter` e `ldap.search.uidField`
Role errada após login	`ldap.roleMapping`, DN dos grupos e `ldap.roleSyncAtLogin: "True"`
LDAP habilitado mas sem efeito	Confirmar `ldap.enabled: true` e Secret de bind criado antes do deploy

Ao trocar de usuários internos para LDAP, crie o Secret de bind antes do helm upgrade.
Depois valide login, atributos de usuário e mapeamento de roles.

Ao trocar de LDAP para usuários internos, confirme que existe usuário admin local válido e revise a exposição da interface.

Boas práticas

Não versionar a senha de bind LDAP nem a SUPERSET_SECRET_KEY.
Rotacionar credenciais após o primeiro deploy em produção.
Use Public ou Gamma como defaultRole para evitar acesso administrativo inadvertido a novos usuários LDAP.
Prefira secretKeyRef em extraEnvRaw em vez de valores literais em extraEnv.
Restrinja a exposição do serviço por NetworkPolicy e use Ingress apenas quando necessário.
Para LDAPS (porta 636), ajuste ldap.server.url para ldaps:// e ldap.server.useTls: "True".

Visão geral​

Modos de operação​

Pré-requisitos​

SUPERSET_SECRET_KEY​

PostgreSQL de metadados​

LDAP habilitado​

Mapeamento de grupos e roles​

Parâmetros principais​

Solução de problemas​

Boas práticas​