Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Presumisse que foi configurado o Até este ponto, foi realizada a configuração do servidor Kafka, de um producer e de um consumer, para tanto, o producer e o consumer. No entanto, ambos, com seus respectivos certificados podem acessar , possuem acesso irrestrito a qualquer tópico e não é este o comportamento esperado que o vamos , o que não corresponde ao comportamento desejado. Portanto, é necessário tornar o servidor mais restritivo.

Edite Para isso, deve-se editar o arquivo config/kraft/server-ofb.properties e descomente descomentar as últimas 3 linhas que existem nele para que fiquem com as opções abaixo ativas.três linhas presentes no arquivo, de modo que as seguintes opções fiquem ativas:

Bloco de código
authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
allow.everyone.if.no.acl.found=false
super.users=User:ANONYMOUS

As linhas configurações acima estão definindo que agora o servidor Kafka deve:estabelecem que:

  • O servidor Kafka passará a utilizar um autorizador;

  • que este Esse autorizador, por padrão vai negar , negará qualquer conexão que não tenha recebido explicitamente uma permissão de conexãoexplícita;

  • e definindo o O usuário ANONYMOUS será definido como super usuário superusuário para que o servidor consiga realizar as executar tarefas administrativas.

Após editar as a edição das configurações, reinicie é necessário reiniciar o servidor Kafka para que as alterações sejam aplicadas.

Após isso, se você tentar se conectar Caso seja realizada uma tentativa de conexão como producer, o prompt > será aberto, mas ao tentar enviar qualquer evento, você receberá ocorrerá um erro do tipo TOPIC_AUTHORIZATION_FAILED.

O mesmo acontecerá se você Da mesma forma, ao tentar se conectar como consumer, a diferença é que o prompt nem não ficará aguardando os eventos.

Criando ACL para o producer

Agora que já conferimos Com a confirmação de que as ACL's ACLs estão restringindo o acesso, vamos deve-se habilitar o acesso do producer com base no subject de seu certificado.

PrimeiroInicialmente, precisamos é necessário extrair o subject do certificado , para isso vamos usar o comando abaixopor meio do seguinte comando:

Bloco de código
openssl x509 -in ssl/kafka-producer.crt -noout -subject -nameopt RFC2253

A resposta deste comando deve seresperada será:

subject=CN=producer

O subject real é essa corresponde à string porém sem o prefixo subject=, portanto no comando iremos usar apenas o restante (, ou seja, CN=producer).

Para dar conceder permissão como ao producer no tópico ssl_test_topic para o usuário com o certificado com o de subject CN=producer, execute-se o seguinte comando abaixo:

Bloco de código
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal "User:CN=producer" --producer --topic 'ssl_test_topic'

Finalizado Após a execução do comando acima, a seguir é conectar será possível conectar-se novamente ao tópico novamente como producer e enviar eventos com utilizando o mesmo seguinte comando que foi utilizado anteriormente:

Bloco de código
bin/kafka-console-producer.sh --bootstrap-server localhost:9094 --topic ssl_test_topic --producer.config config/producer.properties

...

Bloco de código
bin/kafka-acls.sh --bootstrap-server localhost:9092 --add --allow-principal "User:CN=consumer" --consumer --topic 'ssl_test_topic' --group '*'

Finalizado é possível conectar ao tópico novamente como consumer e receberá os eventos com o mesmo comando que utilizamos anteriormenteO mesmo procedimento deve ser realizado para o consumer.

Inicialmente, deve-se extrair o subject do certificado com o seguinte comando:

Bloco de código
bin/kafka-console-consumer.sh --bootstrap-server localhost:9095 --topic ssl_test_topic --consumer.config config/consumer.properties --from-beginning

Dessa forma, o acesso ao servidor Kafka estará devidamente controlado, garantindo a segurança na comunicação entre os componentes envolvidos.