Versão 3.0

Segurança — NiFi

ChartVersion3.0.1TypeapplicationAppVersion1.28.0

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

O chart tdp-nifi suporta três modos operacionais de segurança, controlados pelos blocos nifiCluster.security e nifiCluster.authorizersSecret. A escolha do modo determina se o NiFi opera em HTTP ou HTTPS, se exige login LDAP e quem gerencia as políticas de acesso.

Modos de segurança

Modo	Quando usar	Autenticação	Autorização
Modo 1	Laboratórios locais e testes funcionais temporários	Sem login	Sem controle por usuário
Modo 2	Ambientes com usuários LDAP e políticas locais no NiFi	LDAP	Arquivo local do NiFi (`file`)
Modo 3	Ambientes com LDAP e políticas centralizadas no Ranger	LDAP	Apache Ranger (`ranger`)

Modo 1: sem autenticação e sem controle de políticas

Use este modo em laboratórios locais ou testes funcionais temporários.

NiFi opera em HTTP
LDAP desabilitado
sem tela de login
acesso não segmentado por usuário/perfil

nifiCluster:
  security:
    enabled: false
    protocol: "http"
    port: 8080

    ldap:
      enabled: false

    authorization:
      mode: "file"

Se o Ingress estiver habilitado, use o protocolo HTTP no backend:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
  rules:
    - host: nifi.local
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: tdp-nifi-service
              port:
                number: 8080

Modo 2: LDAP com políticas gerenciadas pelo NiFi

Use este modo quando os usuários autenticam via LDAP e as políticas de acesso são geridas pelo próprio NiFi (autorizador local).

NiFi opera em HTTPS
login via LDAP
políticas controladas pelo NiFi usando o autorizador de arquivo local (file)

nifiCluster:
  security:
    enabled: true
    protocol: "https"
    port: 8443

    ldap:
      enabled: true
      url: "ldap://<LDAP_HOST>:389"
      searchBase: "<LDAP_USER_BASE_DN>"
      searchFilter: "(&(uid={0})(objectClass=inetOrgPerson))"
      managerDn: "<LDAP_BIND_DN>"
      managerPassword: "<LDAP_BIND_PASSWORD>"
      referralStrategy: "FOLLOW"
      identityStrategy: "USE_USERNAME"

    authorization:
      mode: "file"

Para o primeiro acesso, defina as identidades iniciais via nifiCluster.authorizersSecret:

nifiCluster:
  authorizersSecret:
    enabled: true
    initialUserIdentities:
      - fry
      - leela
    initialAdminIdentity: fry

Identidades no authorizersSecret

initialAdminIdentity é o primeiro administrador do NiFi.
A identidade deve corresponder ao que o LDAP retorna após a estratégia de mapeamento configurada.
Com identityStrategy: USE_USERNAME, use identidades como fry, leela, admin.

Se o Ingress estiver habilitado, use o protocolo HTTPS no backend:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  rules:
    - host: nifi.local
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: tdp-nifi-service
              port:
                number: 8443

Gerenciamento declarativo de usuários (opcional)

Após o bootstrap, é possível gerenciar usuários e grupos de forma declarativa via NiFiKop:

nifiCluster:
  authorization:
    enabled: true
    managedAdminUsers:
      - name: fry-admin
        identity: fry
    managedReaderUsers:
      - name: hermes-reader
        identity: hermes

Use quando quiser repeatibilidade via Helm. Se preferir, faça o bootstrap com authorizersSecret e gerencie as políticas depois na UI do NiFi.

Modo 3: LDAP com políticas gerenciadas pelo Ranger

Use este modo quando os usuários autenticam via LDAP e as políticas de acesso são controladas pelo Apache Ranger.

Requisitos:

imagem NiFi com o plugin Ranger já embutido
overlay tdp-ranger para o fluxo de autorização NiFi
Secret ranger-nifi-client-tls-password

nifiCluster:
  clusterImage: "registry.tecnisys.com.br/tdp/images/nifi:1.28.0-0"

  security:
    enabled: true
    protocol: "https"
    port: 8443
    additionalProxyHosts:
      - "nifi-headless.<NAMESPACE>.svc.cluster.local"
      - "nifi-headless.<NAMESPACE>.svc.cluster.local:8443"

    ldap:
      enabled: true
      url: "ldap://<LDAP_HOST>:389"
      searchBase: "<LDAP_USER_BASE_DN>"
      searchFilter: "(&(uid={0})(objectClass=inetOrgPerson))"
      managerDn: "<LDAP_BIND_DN>"
      managerPassword: "<LDAP_BIND_PASSWORD>"
      referralStrategy: "FOLLOW"
      identityStrategy: "USE_USERNAME"

    authorization:
      mode: "ranger"

Crie o Secret com a senha JKS do Ranger antes do deploy:

Terminal input
kubectl -n <NAMESPACE> create secret generic ranger-nifi-client-tls-password \
  --from-literal=password='<KEYSTORE_PASSWORD>' \
  --dry-run=client -o yaml | kubectl apply -f -

Aplique os overlays correspondentes:

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

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

Regras operacionais do Modo 3

Use a imagem NiFi customizada com o plugin Ranger já incluído.
nifiCluster.security.authorization.ranger.adminIdentity deve corresponder à identidade do certificado cliente Ranger (padrão no repositório TDP: CN=ranger-nifi-client).
O serviço Ranger deve apontar para https://<NIFI_SERVICE>/nifi-api/resources.
Para NiFi em cluster, o Ranger precisa de políticas técnicas para /resources, /controller, /system e /proxy.

Resumo: chaves por modo

Configuração	Modo 1	Modo 2	Modo 3
`nifiCluster.security.enabled`	`false`	`true`	`true`
`nifiCluster.security.protocol`	`http`	`https`	`https`
`nifiCluster.security.ldap.enabled`	`false`	`true`	`true`
`nifiCluster.security.authorization.mode`	`file`	`file`	`ranger`
`nifiCluster.authorizersSecret`	não relevante	bootstrap obrigatório	não é fonte de políticas
`nifiCluster.authorization`	opcional	opcional	não é a fonte principal
Configuração de autorização Ranger	não	não	sim
imagem NiFi com plugin Ranger	não	não	sim

Regras práticas

Para sem login: desabilite security.enabled e ldap.enabled.
Para login via LDAP com políticas locais no NiFi: mantenha authorization.mode: file.
Para login via LDAP com políticas no Ranger: use authorization.mode: ranger.

Configuração LDAP detalhada

O bloco nifiCluster.security.ldap controla todos os parâmetros de busca e autenticação LDAP:

Campo	Descrição
`url`	Endereço do servidor LDAP
`searchBase`	Base DN onde os usuários estão localizados
`searchFilter`	Filtro de busca — `{0}` é substituído pelo username informado
`authenticationStrategy`	Tipo de bind: `SIMPLE` para autenticação direta
`managerDn`	DN do usuário de bind (somente leitura no diretório)
`managerPassword`	Senha do usuário de bind — não versionar em repositório público
`referralStrategy`	Como seguir referências LDAP: `FOLLOW` ou `IGNORE`
`identityStrategy`	`USE_USERNAME` usa o login como identidade no NiFi

Credenciais de bind

Não armazene managerPassword em repositório Git. Use um arquivo de valores privado (fora do controle de versão) ou um mecanismo de gestão de Secrets para injetar essa credencial no deploy.

Para LDAPS (TLS), substitua ldap:// por ldaps:// e use a porta 636.

Certificados TLS (cert-manager)

O NiFi opera em HTTPS com certificados gerados automaticamente via cert-manager. A configuração SSL fica sob nifiCluster.security.ssl:

nifiCluster:
  security:
    ssl:
      enabled: true
      secrets:
        create: true
        tlsSecretName: "nifi-cluster-ca"
        pkiBackend: cert-manager
        issuerRef:
          name: selfsigned-issuer
          kind: Issuer

Campo	Descrição
`ssl.enabled`	Habilita TLS (derivado automaticamente de `protocol: https`)
`ssl.secrets.create`	Cria automaticamente o Secret de TLS
`ssl.secrets.pkiBackend`	`cert-manager` delega a emissão ao cert-manager
`ssl.secrets.issuerRef.name`	Nome do Issuer ou ClusterIssuer no cluster

Pré-requisito: cert-manager via tdp-crds

No TDP, o chart tdp-crds instala os CRDs necessários, incluindo os do cert-manager. Instale o tdp-crds antes do tdp-nifi:

Terminal input
helm upgrade --install tdp-crds \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-crds \
  --namespace tdp --create-namespace

Quando nifikop.webhook.enabled=true, os controllers do cert-manager (cert-manager, cainjector e webhook) também precisam estar em execução no cluster.

Boas práticas

Aspecto	Recomendação
Ambiente de desenvolvimento	Modo 1 (sem autenticação), acesso via port-forward
Ambiente compartilhado / produção	Modo 2 com LDAPS (porta 636) e HTTPS habilitado
Credenciais	Nunca versionar `managerPassword` em valores públicos
Certificados	Usar `cert-manager` via `tdp-crds` em produção
Políticas centralizadas	Modo 3 com Ranger quando houver auditoria e controle centralizado de acesso

Solução de problemas

Problema	Causa provável	Solução
Pod NiFi não sobe com HTTPS	`cert-manager` ausente ou Issuer não encontrado	Verificar instalação do cert-manager e nome do Issuer
Login LDAP falha	DN de bind ou senha incorretos	Testar bind com `ldapsearch` antes de configurar
Certificado inválido no navegador	Uso de `selfsigned-issuer`	Esperado em desenvolvimento; usar CA válida em produção
Plugin Ranger não conecta	`adminIdentity` incorreto ou Secret JKS ausente	Verificar `nifiCluster.security.authorization.ranger.adminIdentity` e Secret `ranger-nifi-client-tls-password`
NifiCluster preso em estado intermediário	Webhook do NiFiKop sem cert-manager	Verificar `nifikop.webhook.enabled` e se os controllers do cert-manager estão prontos

Modos de segurança​

Modo 1: sem autenticação e sem controle de políticas​

Modo 2: LDAP com políticas gerenciadas pelo NiFi​

Gerenciamento declarativo de usuários (opcional)​

Modo 3: LDAP com políticas gerenciadas pelo Ranger​

Resumo: chaves por modo​

Regras práticas​

Configuração LDAP detalhada​

Certificados TLS (cert-manager)​

Pré-requisito: cert-manager via tdp-crds​

Boas práticas​

Solução de problemas​