Saltar para o conteúdo principal
Versão 3.0

Segurança — OpenMetadata

ChartVersion3.0.1TypeapplicationAppVersion1.12.4
CompatibilidadeKubernetes1.32+OpenShift4.19+Rancher2.10.x+
Padrões gerais de segurança

Para conceitos transversais a todos os componentes TDP — como gerenciamento de Secrets, rotação de credenciais, NetworkPolicy, rate limiting e auditoria — consulte Segurança — Padrões Gerais.

Configuração de Autenticação

Os parâmetros abaixo controlam o modo de autenticação, o auto-cadastro de usuários e a configuração do administrador inicial.

ParâmetroDescriçãoValor padrão
tdp-openmetadata.openmetadata.config.authentication.providerModo de autenticação: basic (usuário/senha local) ou ldapbasic
tdp-openmetadata.openmetadata.config.authentication.enableSelfSignupPermite que novos usuários se cadastrem pela UItrue
tdp-openmetadata.openmetadata.config.authorizer.initialAdminsLista de usuários administradores criados no bootstrap["admin"]
tdp-openmetadata.openmetadata.config.authorizer.principalDomainDomínio adicionado ao nome dos initialAdminsopen-metadata.org
datasourcesIntegration.openmetadata.auth.*Credenciais usadas pelo Job de datasources para autenticar na API; quando provider=basic, são também exibidas no NOTES do Helmadmin@open-metadata.org / admin

Para desabilitar o auto-cadastro em ambientes de produção:

tdp-openmetadata:
openmetadata:
config:
authentication:
enableSelfSignup: false

Autenticação via LDAP

O pacote tdp-openmetadata suporta autenticação via LDAP, permitindo o uso de diretórios corporativos para login no OpenMetadata.

Para habilitar esse modo, crie um Secret Kubernetes com a senha de bind e adicione a configuração LDAP ao seu arquivo de valores. e crie um Secret Kubernetes com a senha de bind.

A configuração permite customizar DNs de usuários e grupos, atributos de e-mail e login, mapeamento de grupos para roles e o comportamento do truststore.

Após a ativação, o login passa a ser feito com as credenciais LDAP do usuário.

Como habilitar

  1. Ative ldap.enabled: true no values.yaml.
  2. Inclua as definições de LDAP no seu arquivo de valores.

Exemplo de instalação/atualização com overlay:

Terminal input
helm upgrade --install <RELEASE_NAME> \
oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
-n <NAMESPACE> --create-namespace \
-f <VALUES_FILE>

Pré-requisitos

  • Servidor LDAP acessível a partir do cluster Kubernetes
  • Bind DN com permissões para procurar usuários e grupos
  • Secret Kubernetes com a senha de bind

Credenciais e Secrets

Terminal input
kubectl create secret generic tdp-openmetadata-ldap-secret \
--from-literal=bind-password=<PASSWORD> \
-n <NAMESPACE>

Configuração LDAP

Defina no overlay os parâmetros principais do LDAP: host, porta, DN administrativo, base DN de usuários e grupos, além dos atributos e do mapeamento de roles.

<VALUES_FILE>
ldap:
enabled: true

tdp-openmetadata:
openmetadata:
config:
authentication:
enabled: true
provider: ldap
enableSelfSignup: true
ldapConfiguration:
host: "ldap.example.local"
port: 389
dnAdminPrincipal: "cn=admin,dc=example,dc=local"
dnAdminPassword:
secretRef: tdp-openmetadata-ldap-secret # Secret criado no passo anterior
secretKey: bind-password
userBaseDN: "ou=users,dc=example,dc=local"
groupBaseDN: "ou=groups,dc=example,dc=local"
mailAttributeName: mail
usernameAttributeName: mail
groupAttributeName: memberOf
groupMemberAttributeName: member
maxPoolSize: 3
authRolesMapping: '{"cn=tdp-admins,ou=groups,dc=example,dc=local": ["Admin"]}'
authReassignRoles: []
sslEnabled: false
truststoreConfigType: TrustAll # Use CustomTrustStore ou JVMDefault para validar certificados
Senha de bind via Secret

O campo dnAdminPassword deve sempre referenciar um Kubernetes Secret — nunca coloque a senha em texto simples no arquivo de valores. Crie o Secret antes do deploy conforme descrito acima.

O que esta configuração cobre

  • Host, porta, DN administrativo e bases de usuários/grupos
  • Atributos customizáveis para e-mail, usuário e grupos
  • Mapeamento de grupos LDAP para roles do OpenMetadata via authRolesMapping
  • Truststore padrão TrustAll, que não exige LDAPS, mas pode ser ajustado para o modelo do seu ambiente

Login

Terminal input
kubectl port-forward svc/<RELEASE_NAME> 8585:8585 -n <NAMESPACE>

Depois, acesse http://localhost:8585 e faça login com as credenciais LDAP do usuário.

Para a lista completa de parâmetros, consulte helm show values na versão do chart instalada e a documentação oficial do OpenMetadata.

OpenShift: configuração de SCC

No OpenShift, os jobs de ingestão do OpenMetadata executam com runAsUser: 0 (root) para instalação de pacotes via pip. Isso exige o anyuid Security Context Constraint (SCC).

Para configurar o SCC automaticamente, ative openshift.enabled: true no arquivo de valores:

openshift:
enabled: true

Ou via linha de comando:

Terminal input
helm upgrade --install <RELEASE_NAME> \
oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
-n <NAMESPACE> --create-namespace \
--set openshift.enabled=true

Quando habilitado, o chart cria um RoleBinding que adiciona as seguintes ServiceAccounts ao SCC anyuid:

  • openmetadata-ingestion — usada pelos jobs de ingestão do OpenMetadata
  • <RELEASE_NAME>-openmetadata-sa — usada pelo job de registro de datasources
warning

Sem essa configuração no OpenShift, os jobs de ingestão falham ao tentar instalar dependências Python.

Segurança do job de registro de datasources

O job de integração autentica na API do OpenMetadata e acessa serviços externos. Observe as seguintes práticas:

  • Nunca armazene senhas em texto simples no arquivo de valores em produção. Use passwordSecret com referência a um Secret Kubernetes criado separadamente.
  • Restrinja o acesso aos Secrets via RBAC: o job usa uma ServiceAccount dedicada; não amplie suas permissões além do necessário.
  • Use HTTPS nos endpoints dos serviços quando estiverem fora do cluster: defina scheme: "https" para ClickHouse e Trino, e verifySSL: "validate" para Superset e Airflow.
  • Rotacione senhas regularmente: após trocar a senha de um serviço, atualize o Secret Kubernetes correspondente e re-execute o job de registro.

Exemplo de Secret para credencial do ClickHouse:

Terminal input
kubectl create secret generic tdp-clickhouse-tdp-user \
--from-literal=password=<PASSWORD> \
-n <NAMESPACE>

Referência no arquivo de valores:

datasourcesIntegration:
clickhouse:
connection:
passwordSecret:
name: "tdp-clickhouse-tdp-user"
key: "password"