Content Comparison

Presumisse que foi configurado o Até este ponto, foi realizada a configuração do servidor Kafka, de um producer e de um consumer. No entanto, para tanto, o producer e o consumer, 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:

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 usuário ANONYMOUS como super usuário A configuração abaixo é apenas um exemplo e deve ser comparada com a política de segurança vigente em sua empresa:

  • O usuário ANONYMOUS será definido como 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:

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:

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:

bin/kafka-console-producer.sh --bootstrap-server localhost:9094 --topic ssl_test_topic --producer.config config/producer.properties

...

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:

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.