Segurança — Kafka

ChartVersion3.0.1TypeapplicationAppVersion4.1.0

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

Este documento cobre autenticação e autorização do cluster Kafka (brokers) e da Kafka UI.
Para listeners plain/TLS, consulte Configuração do Kafka.

Modelo de segurança

A autenticação da Kafka UI e a autenticação no broker Kafka são preocupações separadas:

• um usuário humano autentica-se na Kafka UI via kafka-ui.applicationConfig.auth (por exemplo LOGIN_FORM ou LDAP);
• o backend da Kafka UI conecta-se ao Kafka usando o principal técnico configurado em kafka-ui.connection.authentication;
• os brokers Kafka avaliam ACLs para o principal Kafka usado pela aplicação, não para o usuário humano que fez login na UI.

Exemplo:

• o usuário LDAP fry faz login na Kafka UI;
• a Kafka UI conecta-se ao Kafka como kafka-ui;
• criação de tópicos, leitura de mensagens e ações administrativas são avaliadas pelo Kafka como principal kafka-ui.

Isso significa que as decisões de auditoria e autorização do Kafka baseiam-se no usuário Kafka configurado para a UI (kafka-ui), não no nome de usuário LDAP que fez login.

Autenticação no broker (SCRAM-SHA-512)

Segurança desabilitada (padrão)

Por padrão, autenticação e autorização estão desabilitadas:

security:
  enabled: false
  authentication:
    enabled: false
  authorization:
    enabled: false

Os listeners plain e TLS operam sem autenticação. Adequado apenas para ambientes internos controlados.

Habilitar SCRAM-SHA-512 e ACLs simples

Para habilitar autenticação SCRAM-SHA-512 com ACLs simples:

security:
  enabled: true
  listener: plain
  authentication:
    enabled: true
    type: scram-sha-512
  authorization:
    enabled: true
    type: simple
    superUsers:
      - platform-admin

Com security.enabled: true, o Strimzi cria recursos KafkaUser declarativos e aplica ACLs conforme security.users.

Usuário produtor (exemplo)

security:
  users:
    - name: producer-app
      acls:
        - resource:
            type: topic
            name: orders.events
            patternType: literal
          operations:
            - Write
            - Create
            - Describe
        - resource:
            type: cluster
          operations:
            - IdempotentWrite

Usuário consumidor (exemplo)

security:
  users:
    - name: consumer-app
      acls:
        - resource:
            type: topic
            name: orders.events
            patternType: literal
          operations:
            - Read
            - Describe
        - resource:
            type: group
            name: orders-consumer
            patternType: literal
          operations:
            - Read

Superusuário (exemplo)

security:
  authorization:
    superUsers:
      - admin-user
  users:
    - name: admin-user

A entrada admin-user é renderizada como KafkaUser; o acesso de superusuário é concedido por security.authorization.superUsers. Superusuários não precisam de ACLs.

O Strimzi gera um Secret com credenciais para cada KafkaUser:

Terminal input

kubectl -n <NAMESPACE> get kafkauser producer-app -o yaml
kubectl -n <NAMESPACE> get secret producer-app -o jsonpath='{.data.password}' | base64 -d

Propriedades típicas de cliente SCRAM:

bootstrap.servers=tdp-kafka-kafka-bootstrap:9092
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="producer-app" password="<PASSWORD>";

Kafka UI — autenticação web

A Kafka UI suporta dois modos de autenticação web:

Modo	Descrição
LOGIN_FORM	Usuário e senha definidos em kafka-ui.applicationConfig
LDAP	Autenticação delegada a um servidor LDAP/AD corporativo

LOGIN_FORM (padrão)

kafka-ui:
  applicationConfig:
    auth:
      type: LOGIN_FORM
    spring:
      security:
        user:
          name: admin
          password: <PASSWORD>

LDAP (opcional)

O chart oferece duas formas de fornecer a senha de bind LDAP da Kafka UI. Em ambas, a autenticação web é delegada ao servidor LDAP — a diferença está em como a senha de bind chega ao pod.

Forma 1 — senha inline no values (não recomendada)

Evite em produção

Esta forma grava a senha de bind em texto plano no arquivo de valores. Use apenas em testes isolados — nunca em ambientes acessíveis nem em arquivos de values versionados no Git.

kafka-ui:
  applicationConfig:
    auth:
      type: LDAP
    spring:
      ldap:
        urls: ldap://<LDAP_HOST>:389
        base: "<LDAP_USER_BASE_DN>"
        admin-user: "<LDAP_BIND_DN>"
        admin-password: "<LDAP_BIND_PASSWORD>"
    management:
      health:
        ldap:
          enabled: true

Forma 2 — senha via Secret (recomendada)

A senha de bind LDAP não deve ficar em texto plano no arquivo de valores. Crie um Secret e injete-a via kafka-ui.envs.secretMappings. A Kafka UI é uma aplicação Spring Boot — a variável de ambiente SPRING_LDAP_ADMIN_PASSWORD sobrescreve a propriedade spring.ldap.admin-password em tempo de execução.

Crie o Secret antes de instalar o chart:

Terminal input

kubectl create secret generic kafka-ui-ldap-secret \
  --from-literal=admin-password=<LDAP_BIND_PASSWORD> \
  -n <NAMESPACE>

kafka-ui:
  enabled: true
  yamlApplicationConfig: null
  yamlApplicationConfigConfigMap:
    name: tdp-kafka-ui-config
    keyName: config.yml
  applicationConfig:
    auth:
      type: LDAP
    spring:
      ldap:
        urls: ldap://<LDAP_HOST>:389
        base: "<LDAP_USER_BASE_DN>"
        admin-user: "<LDAP_BIND_DN>"
    management:
      health:
        ldap:
          enabled: true
  envs:
    secretMappings:
      SPRING_LDAP_ADMIN_PASSWORD:
        name: kafka-ui-ldap-secret
        keyName: admin-password

Campo	Descrição	Exemplo
urls	Endereço do servidor LDAP	ldap://ldap.empresa.com.br:389
base	Base DN de busca de usuários	dc=empresa,dc=com,dc=br
admin-user	DN do usuário de bind	cn=kafkaui,dc=empresa,dc=com,dc=br
admin-password	Senha do bind — injetada via envs.secretMappings (Secret kafka-ui-ldap-secret), nunca inline no values	—
management.health.ldap.enabled	Habilita o health-check LDAP da Kafka UI	true

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

Configuração completa

Para um deploy com broker seguro (security.enabled: true), combine este bloco de autenticação da UI com o bloco da seção Kafka UI — conexão com o broker (abaixo), no mesmo arquivo de values.

Kafka UI — conexão com o broker

Quando security.enabled=true, crie um KafkaUser correspondente ao principal técnico da UI.
O Strimzi gera um Secret com o mesmo nome do usuário por padrão.

SASL automático

Quando security.enabled=true, o chart injeta automaticamente security.protocol, sasl.mechanism e sasl.jaas.config na conexão da Kafka UI com o broker (kafka-ui.connection). Não é necessário definir essas propriedades manualmente.

security:
  enabled: true
  authentication:
    enabled: true
  authorization:
    enabled: true

kafka-ui:
  connection:
    clusterName: TDP
    bootstrapServers: tdp-kafka-kafka-bootstrap:9092
    authentication:
      username: kafka-ui
      existingSecret:
        name: kafka-ui
        passwordKey: password

Verifique o Secret gerado:

Terminal input

kubectl -n <NAMESPACE> get kafkauser kafka-ui -o yaml
kubectl -n <NAMESPACE> get secret kafka-ui -o yaml

Risco de superusuário

Se kafka-ui for promovido a superUser, todo acesso administrativo via UI será executado com privilégios totais no broker.
Restrinja o acesso à Kafka UI a um conjunto pequeno de usuários confiáveis nesse cenário.

Propriedades típicas de cliente SCRAM para consumidores:

bootstrap.servers=tdp-kafka-kafka-bootstrap:9092
group.id=orders-consumer
security.protocol=SASL_PLAINTEXT
sasl.mechanism=SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="consumer-app" password="<PASSWORD>";

RBAC da Kafka UI

O bloco kafka-ui.rbac injeta a seção rbac no config.yml da Kafbat UI, permitindo restringir ações da UI por usuário LDAP — sem conceder acesso administrativo a todos os usuários autenticados.

Modelo recomendado:

• apenas um pequeno conjunto de usuários LDAP confiáveis deve ter permissões completas na UI;
• todos os demais usuários da Kafka UI devem receber permissões somente-leitura;
• se kafka-ui estiver configurado como superUser do Kafka, o RBAC da UI deve estar sempre habilitado.

kafka-ui:
  rbac:
    enabled: true
    roles:
      - name: admins
        clusters:
          - TDP
        subjects:
          - provider: ldap
            type: user
            value: fry
        permissions:
          - resource: topic
            value: ".*"
            actions: all
      - name: readonly
        clusters:
          - TDP
        subjects:
          - provider: ldap
            type: user
            value: leela
        permissions:
          - resource: topic
            value: ".*"
            actions:
              - view
              - messages_read

Com esse modelo, fry usa a UI completa e leela pode apenas visualizar tópicos e ler mensagens — mas o Kafka ainda vê ambas as operações como principal kafka-ui.

Produtores e consumidores externos

Aplicações externas devem autenticar-se diretamente no Kafka com identidades próprias, sem reutilizar o principal técnico kafka-ui.

Recomendações:

• crie um KafkaUser por aplicação ou fronteira de segurança;
• conceda apenas as ACLs necessárias;
• deixe o Strimzi gerar e gerenciar credenciais sempre que possível;
• distribua o Secret gerado de forma segura ao runtime da aplicação.

Listeners internos por padrão

Os exemplos abaixo assumem que o cliente alcança o listener Kafka selecionado. Este chart expõe listeners internos por padrão — o acesso a partir de fora do cluster exige exposição adicional de listener, não coberta por estes exemplos.

Autenticação TLS (cliente)

Para autenticação TLS de cliente, defina o usuário com authentication.type: tls e conecte-se via listener TLS:

security:
  listener: tls
  users:
    - name: consumer-tls
      authentication:
        type: tls
      acls:
        - resource:
            type: topic
            name: orders.events
            patternType: literal
          operations:
            - Read
            - Describe
        - resource:
            type: group
            name: orders-consumer
            patternType: literal
          operations:
            - Read

O Secret gerado contém ca.crt, user.crt, user.key, user.p12 e user.password.

Propriedades típicas de cliente TLS usando arquivos PEM:

bootstrap.servers=tdp-kafka-kafka-bootstrap:9093
security.protocol=SSL
ssl.truststore.type=PEM
ssl.keystore.type=PEM
ssl.truststore.certificates=/etc/kafka-user/ca.crt
ssl.keystore.certificate.chain=/etc/kafka-user/user.crt
ssl.keystore.key=/etc/kafka-user/user.key

Orientações de ACL para produtores e consumidores

Use um principal Kafka por aplicação ou tipo de carga. Evite compartilhar um principal amplo entre vários sistemas.

Tipo	ACLs típicas
Produtor	Write, Create, Describe no(s) tópico(s); IdempotentWrite no cluster para produção idempotente
Consumidor	Read, Describe nos tópicos; Read no consumer group
Ferramenta admin / manutenção	Identidade separada; evite reutilizar credenciais de produtor/consumidor
Superusuário	Somente quando estritamente necessário; não usar All desnecessariamente

Não versionar senhas SCRAM em values.yaml público. Prefira createSecret: false com Secrets externos em produção.

Recomendações

Aspecto	Recomendação
Ambiente de desenvolvimento	LOGIN_FORM com senha forte, acesso via port-forward
Ambiente compartilhado / produção	LDAP com LDAPS (porta 636)
Broker em produção	security.enabled: true com SCRAM-SHA-512 e ACLs mínimas
Credenciais	Nunca versionar senhas em values.yaml público
Exposição da UI	Prefira Ingress com TLS ou port-forward controlado

Solução de problemas

Problema	Causa provável	Solução
Credenciais inválidas na UI (LOGIN_FORM)	Senha incorreta ou typo em name/password	Verificar kafka-ui.applicationConfig.spring.security.user
Login LDAP falha com "invalid credentials"	Bind DN ou senha incorretos	Testar bind com ldapsearch externo
Login LDAP falha com "connection refused"	Host/porta LDAP inacessível pelo pod	Verificar conectividade de rede
Kafka UI não conecta ao broker	Secret ou bootstrap incorretos	Verificar kafka-ui.connection e Secret do KafkaUser
Falha de startup por RBAC	Recursos ou ações RBAC incompatíveis com a versão da UI	Verificar kafka-ui.rbac.roles e logs do pod
Mudanças no applicationConfig não refletem	Pod não reiniciado após atualização	kubectl -n <NAMESPACE> rollout restart deployment <RELEASE_NAME>-kafka-ui