Versão 3.0

Segurança - Trino

ChartVersion3.0.1TypeapplicationAppVersion478

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

Visão geral

O chart tdp-trino concentra a segurança em três frentes principais.
A primeira é a autenticação LDAP, que muda o acesso do Trino de HTTP sem autenticação para HTTPS com PASSWORD authentication.
A segunda é o bloco trinoCerts, usado para organizar keystores, certificados e materiais TLS em Secret, PVC e Job de cópia.
A terceira é o controle de acesso com Apache Ranger, configurado por tdp-trino.accessControl e arquivos XML adicionais no coordinator.

A ideia prática é simples: LDAP autentica quem entra, HTTPS protege o transporte e Ranger decide o que cada usuário pode acessar.
Quando LDAP ou Ranger estiverem ativos, trate certificados, senhas e shared secrets como dependências obrigatórias do deploy.

Modos de operação

O chart foi desenhado para alternar entre um modo simples de desenvolvimento e um modo autenticado.
Essa diferença é controlada principalmente por ldap.enabled e pelos valores de HTTPS/autenticação em tdp-trino.server.config.

Modo	`ldap.enabled`	Porta	Autenticação	Certificados
HTTP sem LDAP	`false`	`8080`	Não exige login	Não monta certificados por padrão
HTTPS com LDAP	`true`	`8443`	`PASSWORD` com LDAP	Monta keystore e configura shared secret

Com ldap.enabled: false, o chart usa HTTP na porta 8080 e não exige autenticação.
Esse modo é útil para teste controlado, mas não deve ser exposto fora de ambientes restritos.

Com ldap.enabled: true, o acesso passa para HTTPS na porta 8443.
Nesse modo, o Trino precisa de keystore, senha do keystore, internal-communication.shared-secret e um arquivo password-authenticator.properties apontando para o LDAP.

Pré-requisitos

Servidor LDAP acessível a partir do namespace do Trino, quando LDAP for usado.
Keystore JKS válido para HTTPS e senha correspondente.
Secret Kubernetes com os arquivos de certificado antes do deploy.
StorageClass disponível se trinoCerts.pvc.enabled: true.
Ranger implantado e acessível quando access-control.name=ranger for usado.
Conectividade do coordinator com LDAP, Ranger e fontes de dados protegidas.

Certificados TLS do Trino (`trinoCerts`)

O bloco trinoCerts prepara os materiais de certificado usados pelo Trino quando o ambiente exige HTTPS, LDAP ou integrações como Ranger.
Ele não gera certificados automaticamente; ele organiza como arquivos já existentes serão disponibilizados aos pods.

O Secret guarda arquivos sensíveis, como keystores JKS.
O PVC fornece um volume persistente para reutilizar esses arquivos entre etapas do Helm.
O copyJob roda como hook de pre-install e pre-upgrade para copiar arquivos do Secret para o PVC antes da instalação ou atualização.

Parâmetro	Uso	Padrão
`trinoCerts.pvc.enabled`	Cria PVC para certificados	`false`
`trinoCerts.pvc.name`	Nome do PVC	`trino-certs-pvc`
`trinoCerts.pvc.size`	Tamanho do PVC	`1Gi`
`trinoCerts.secret.enabled`	Monta Secret com certificados no Job	`false`
`trinoCerts.secret.name`	Nome do Secret de certificados	`tdp-trino-certs-secret`
`trinoCerts.copyJob.enabled`	Executa Job para preparar o PVC	`false`

Modelo de Secret para LDAP com keystore:

kubectl -n <NAMESPACE> create secret generic tdp-trino-certs-secret \
  --from-file=keystore.jks=<LOCAL_PATH>/keystore.jks

Exemplo de Secret para fluxo com PVC e Ranger:

kubectl -n <NAMESPACE> create secret generic tdp-trino-certs-secret \
  --from-file=trino_cert.jks=<LOCAL_PATH>/trino_cert.jks

Exemplo de preparação do PVC por copyJob:

trinoCerts:
  pvc:
    enabled: true
    size: "1Gi"
  secret:
    enabled: true
    name: "tdp-trino-certs-secret"
  copyJob:
    enabled: true

LDAP habilitado

LDAP é usado pelo Trino como autenticador de senha.
No chart, habilitar LDAP implica também habilitar HTTPS, porque credenciais de usuário não devem trafegar por HTTP simples.

O arquivo password-authenticator.properties define como o Trino consulta o diretório LDAP.
O userBindPattern é o molde do DN usado no bind; ${USER} é substituído pelo usuário informado no cliente Trino.

Modelo de configuração:

ldap:
  enabled: true
  server:
    url: "ldap://<LDAP_HOST>:389"
    insecure: true
  auth:
    userBindPattern: "uid=${USER},cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com,dc=br"

tdp-trino:
  server:
    config:
      https:
        enabled: true
        port: 8443
        keystore:
          path: "/etc/trino/certs/keystore.jks"
      authenticationType: "PASSWORD"
  additionalConfigProperties:
    - "internal-communication.shared-secret=<SHARED_SECRET>"
    - "http-server.https.keystore.key=<KEYSTORE_PASSWORD>"
  coordinator:
    additionalVolumes:
      - name: trino-certs
        secret:
          secretName: tdp-trino-certs-secret
    additionalVolumeMounts:
      - name: trino-certs
        mountPath: /etc/trino/certs
        readOnly: true
    additionalConfigFiles:
      password-authenticator.properties: |
        password-authenticator.name=ldap
        ldap.url=ldap://<LDAP_HOST>:389
        ldap.allow-insecure=true
        ldap.user-bind-pattern=uid=${USER},cn=users,cn=accounts,dc=<LDAP_DOMAIN>,dc=com,dc=br
        ldap.cache-ttl=1h
        ldap.timeout.connect=1m
        ldap.timeout.read=1m

Substitua os placeholders antes de instalar.
<LDAP_HOST> é o endereço do LDAP visto de dentro do cluster.
<LDAP_DOMAIN> representa os componentes do DN do diretório.
<SHARED_SECRET> deve ser um valor forte para comunicação interna do Trino.
<KEYSTORE_PASSWORD> deve corresponder à senha do keystore usado por HTTPS.

Para desabilitar LDAP e voltar ao modo HTTP, remova a configuração LDAP específica e deixe ldap.enabled: false.
Depois do upgrade, valide se os pods reiniciaram e se o cliente usa a porta 8080.

Para habilitar LDAP, crie primeiro o Secret de certificados, aplique os valores de LDAP/HTTPS e use a porta 8443 no cliente.
Depois do upgrade, confira o ConfigMap gerado, os mounts do coordinator e os logs de autenticação.

Ranger

Apache Ranger adiciona controle de acesso centralizado ao Trino via plugin de autorização.

A integração usa tdp-trino.accessControl para ativar o plugin Ranger.
Os arquivos extras em tdp-trino.coordinator.additionalConfigFiles entregam a configuração de política, auditoria e SSL que o plugin lê no startup.

Use o exemplo abaixo como modelo de estrutura.
Ele mostra onde ficam os pontos principais sem trazer XML completo para a página.

trinoCerts:
  pvc:
    enabled: true
    size: "1Gi"
  secret:
    enabled: true
    name: "tdp-trino-certs-secret"
  copyJob:
    enabled: true

tdp-trino:
  server:
    config:
      https:
        enabled: true
        port: 8443
        keystore:
          path: "/etc/trino/ssl/trino_cert.jks"
          key: "<KEYSTORE_PASSWORD>"
      authenticationType: "PASSWORD"

  accessControl:
    type: properties
    properties: |
      access-control.name=ranger
      ranger.service.name=dev_trino
      ranger.plugin.config.resource=/etc/trino/ranger-trino-security.xml,/etc/trino/ranger-trino-audit.xml,/etc/trino/ranger-policymgr-ssl.xml

  coordinator:
    additionalVolumes:
      - name: trino-certs
        persistentVolumeClaim:
          claimName: trino-certs-pvc
    additionalVolumeMounts:
      - name: trino-certs
        mountPath: /etc/trino/ssl
    additionalConfigFiles:
      ranger-trino-security.xml: |
        <?xml version="1.0" encoding="UTF-8"?>
        <configuration>
          <property>
            <name>ranger.plugin.trino.policy.rest.url</name>
            <value>http://ranger-<NAMESPACE>.svc.cluster.local:6180</value>
          </property>
          <property>
            <name>ranger.plugin.trino.super.users</name>
            <value>admin</value>
          </property>
        </configuration>
      ranger-trino-audit.xml: |
        <configuration>
          <!-- Configuração de auditoria do plugin -->
        </configuration>
      ranger-policymgr-ssl.xml: |
        <configuration>
          <!-- Truststore/keystore para comunicação com Ranger -->
        </configuration>

O valor ranger.service.name deve ser o mesmo serviço cadastrado na interface do Ranger.
Se os nomes não baterem, o plugin pode iniciar, mas as políticas não serão aplicadas ao serviço esperado.

Use superusuários com cuidado.
Uma conta listada como superusuário passa pelas políticas com privilégio amplo, então mantenha a lista curta e auditável.

Quando houver auditoria externa ou SSL mútuo, preencha os XMLs com os destinos, truststores e credenciais exigidos pelo ambiente.
Mantenha senhas e arquivos sensíveis fora do repositório.

Conectar com cliente Trino

Modelo para HTTP sem LDAP:

HTTP sem LDAP

kubectl -n <NAMESPACE> port-forward svc/<RELEASE_NAME> 8080:8080 &
trino --server http://localhost:8080

Modelo para HTTPS com LDAP:

HTTPS com LDAP
kubectl -n <NAMESPACE> port-forward svc/<RELEASE_NAME> 8443:8443 &
trino --server https://localhost:8443 \
      --user <LDAP_USER> \
      --password \
      --insecure

Exemplo:

HTTP sem LDAP

kubectl port-forward -n tdp-project svc/tdp-trino 8080:8080 &
trino --server http://localhost:8080

HTTPS com LDAP
kubectl port-forward -n tdp-project svc/tdp-trino 8443:8443 &
trino --server https://localhost:8443 \
      --user your-ldap-username \
      --password \
      --insecure

Em produção, prefira validar a cadeia de certificado em vez de usar --insecure.
Use --insecure apenas para depuração controlada ou certificados de laboratório.

Parâmetros principais

Parâmetro	Papel	Padrão	Quando alterar
`ldap.enabled`	Liga ou desliga o modo LDAP	`false`	Ambientes com autenticação corporativa
`tdp-trino.server.config.https.enabled`	Habilita HTTPS no Trino	`false`	LDAP, Ranger ou exposição segura
`tdp-trino.server.config.https.port`	Porta HTTPS do Trino	`8443`	Quando o ambiente padronizar outra porta
`tdp-trino.server.config.https.keystore.path`	Caminho do keystore dentro do pod	vazio	Sempre que HTTPS for usado
`tdp-trino.server.config.authenticationType`	Tipo de autenticação do Trino	vazio	Use `PASSWORD` para LDAP ou arquivo de senhas
`tdp-trino.additionalConfigProperties`	Propriedades extras do Trino	`[]`	Shared secret, HTTPS interno e ajustes avançados
`tdp-trino.coordinator.additionalVolumes`	Volumes extras no coordinator	`[]`	Montar Secret ou PVC com certificados
`tdp-trino.coordinator.additionalConfigFiles`	Arquivos extras no coordinator	`{}`	LDAP, password file e XMLs do Ranger
`tdp-trino.accessControl`	Configuração de autorização	`{}`	Apache Ranger ou outro controle suportado
`trinoCerts.*`	Preparação de certificados	desabilitado	HTTPS, LDAP, Ranger ou SSL mútuo

Solução de problemas

Situação	O que verificar
Pod não sobe com LDAP	Caminho do keystore, senha do keystore, Secret, mounts e `authenticationType`
Login LDAP falha	URL LDAP, `userBindPattern`, conectividade, certificado e permissões do usuário de bind
Cliente não conecta	Porta correta: 8080 para HTTP, 8443 para HTTPS
Erro de certificado	Nome do arquivo no Secret, mountPath e path configurado no Trino
Ranger não aplica políticas	`ranger.service.name`, URL do Ranger, XMLs no coordinator e usuário autenticado
PVC não é criado	`trinoCerts.pvc.enabled`, StorageClass e eventos do namespace

Ao trocar de LDAP para HTTP, remova os blocos específicos de LDAP/HTTPS para evitar configuração residual.
Depois valide se o Service e o cliente voltaram para a porta 8080.

Ao trocar de HTTP para LDAP, crie o Secret antes do helm upgrade.
Depois valide o ConfigMap, os volumes montados e o acesso pela porta 8443.

Boas práticas

Use LDAPS na porta 636 em produção sempre que o diretório suportar.
Não versionar keystores, senhas, hashes reais ou shared secrets.
Rotacione senhas de keystore e shared secrets periodicamente.
Restrinja permissões do usuário de bind LDAP.
Mantenha a lista de superusuários do Ranger mínima.
Monitore logs de autenticação do Trino e auditoria do Ranger.
Deixe ldap.enabled: false apenas em ambientes controlados de desenvolvimento ou teste.

Visão geral​

Modos de operação​

Pré-requisitos​

Certificados TLS do Trino (trinoCerts)​

LDAP habilitado​

Ranger​

Conectar com cliente Trino​

Parâmetros principais​

Solução de problemas​

Boas práticas​