Como soluciono problemas comuns ao usar o cluster do Amazon MSK com a autenticação SASL/SCRAM?

Resolução

Você está recebendo o erro ClusterAuthorizationException nos logs do agente

Você pode ver a seguinte mensagem de erro ao acessar o cluster do Amazon MSK:

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.

Esse erro é retornado quando ambas as seguintes condições forem verdadeiras:

• Seu cluster do Amazon MSK tem a autenticação Simple Authentication and Security Layer (SASL)/Salted Challenge Response Mechanism (SCRAM) habilitada.
• Você definiu resourceType=CLUSTER e operation=CLUSTER_ACTION nas listas de controle de acesso (ACLs) do cluster.

O cluster do Amazon MSK não oferece suporte a essa configuração porque ela impede a replicação interna do Apache Kafka. Com essa configuração, a identidade dos agentes aparece como ANÔNIMA para a comunicação entre agentes. Se precisar que o cluster ofereça suporte a essas ACLs ao usar a autenticação SASL/SCRAM, conceda as permissões para TODAS as operações ao usuário ANÔNIMO. Isso evita a restrição da replicação entre os agentes. Use o seguinte comando para conceder essa permissão ao usuário ANÔNIMO:

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

Você alterou o nome de usuário e/ou a senha do segredo do AWS Secrets Manager, mas as credenciais antigas ainda estão ativas

Um segredo do AWS Secrets Manager deve estar associado a um único usuário. Se o usuário não precisar mais de acesso ao cluster, o segredo deverá ser dissociado, e as ACLs deverão ser atualizadas. Ao atualizar o nome de usuário no segredo, o nome de usuário antigo não é dissociado automaticamente. Portanto, é uma prática recomendada criar um novo segredo para o novo usuário. Caso precise usar o segredo antigo, primeiro dissocie o segredo e, em seguida, atualize as credenciais antes de associar o segredo novamente. Para obter mais informações, consulte Trabalhar com usuários.

Usuários não administradores podem criar novas ACLs e modificar as ACLs existentes

Por padrão, qualquer usuário pode criar ou modificar ACLs. Para impedir que usuários não administradores criem ou atualizem ACLs usando o Apache ZooKeeper, certifique-se de restringir o acesso ao Apache ZooKeeper colocando 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 de cliente do Apache Kafka sejam executados por meio de agentes de bootstrap em vez do Apache ZooKeeper. Observe que todas as operações do Apache Kafka podem ser executadas usando a string bootstrap.

Informações relacionadas

ACLs do Apache Kafka

Segredos do Scram