Como soluciono problemas de autenticação e permissão ao usar meu cluster do Amazon MSK com a autenticação SASL/SCRAM ativada?

Resolução

Erro “ClusterAuthorizationException” nos logs do agente

Ao acessar seu cluster do Amazon MSK, é possível receber a seguinte mensagem de erro: "org.apache.kafka.common.errors.ClusterAuthorizationException: Request Request(processor=11, connectionId=INTERNAL_IP-INTERNAL_IP-0, session=Session(User:ANONYMOUS,/INTERNAL_IP), listenerName=ListenerName(REPLICATION_SECURE), securityProtocol=SSL, buffer=null) is not authorized."

Você recebe o erro acima quando as duas condições a seguir são verdadeiras:

• Seu cluster do Amazon MSK tem a autenticação SASL/SCRAM ativada.
• Você define resourceType como CLUSTER e operation como CLUSTER_ACTION nas listas de controle de acesso (ACLs) do seu cluster.

O cluster do Amazon MSK não suporta as configurações anteriores porque as configurações impedem a replicação interna do Apache Kafka. Quando ambas as condições anteriores forem verdadeiras, a identidade dos agentes é ANÔNIMA para comunicação entre agentes. Se precisar que seu cluster ofereça suporte a essas ACLs ao usar a autenticação SASL/SCRAM, você deverá conceder permissões para TODAS as operações ao usuário ANÔNIMO. Isso evita a restrição da replicação entre os agentes.

Execute o comando a seguir para conceder permissão ao usuário ANÔNIMO:

./kafka-acls.sh --authorizer-properties
zookeeper.connect=example-ZookeeperConnectString --add --allow-principal
User:ANONYMOUS --operation ALL --cluster

Erro de autenticação SASL

Se você alterou o nome de usuário ou a senha do seu segredo do AWS Secrets Manager, mas as credenciais antigas ainda estiverem ativas, você receberá um erro de autenticação.

Um segredo do AWS Secrets Manager só pode ser associado a um único usuário. Quando o usuário não precisar mais acessar o cluster, você deverá dissociar o segredo e atualizar a ACL.

Quando você atualiza o nome de usuário no segredo, o AWS Secrets Manager não dissocia automaticamente o nome de usuário antigo. É uma prática recomendada criar um novo segredo para o novo usuário. Se você precisar usar o segredo antigo, primeiro dissocie o segredo e, em seguida, atualize as credenciais antes de associá-lo novamente. Para mais informações, consulte Trabalhar com usuários.

Usuários não administradores podem criar e modificar ACLs sem autorização

Por padrão, todos os usuários têm permissão para criar ou modificar ACLs. Para evitar que usuários não administradores modifiquem a ACL por meio do Apache ZooKeeper, coloque os nós do ZooKeeper em um grupo de segurança separado. Além disso, certifique-se de que todos os comandos e conexões do cliente do Apache Kafka sejam executados por meio de agentes de bootstrap em vez do Apache ZooKeeper.

Observação: é possível usar a string de bootstrap para realizar todas as operações do Apache Kafka.

Informações relacionadas

ACLs de Apache Kafka

Scram secrets (Segredos do Scram)