Comment résoudre les problèmes courants liés à l'utilisation de mon cluster Amazon MSK avec l'authentification SASL/SCRAM ?

Résolution

Vous obtenez l'erreur ClusterAuthorizationException dans les journaux de l’agent

Le message d'erreur suivant peut s'afficher lorsque vous accédez à votre cluster 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.

Cette erreur s'affiche lorsque les deux conditions suivantes sont remplies :

• L'authentification Simple Authentication and Security Layer (SASL) /Salted Challenge Response Mechanism (SCRAM) est activée sur votre cluster Amazon MSK.
• Vous avez défini ResourceType=CLUSTER et operation=CLUSTER_ACTION dans les listes de contrôle d'accès (ACL) de votre cluster.

Le cluster Amazon MSK ne prend pas en charge ce paramètre car ce paramètre empêche la réplication interne Apache Kafka. Avec ce paramètre, l'identité des agents apparaît comme ANONYME pour les communications entre agents. Si vous avez besoin que votre cluster prenne en charge ces ACL lors de l'utilisation de l'authentification SASL/SCRAM, vous devez accorder les autorisations pour TOUTES les opérations à l'utilisateur ANONYME. Cela empêche la restriction de la réplication entre les agents. Utilisez la commande suivante pour accorder cette autorisation à l'utilisateur ANONYME :

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

Vous avez modifié le nom d'utilisateur et/ou le mot de passe de votre AWS Secrets Manager secret, mais les anciennes informations d'identification sont toujours actives

Un AWS Secrets Manager secret doit être associé à un seul utilisateur. Si l'utilisateur n'a plus besoin d'accéder au cluster, le secret doit être dissocié et les ACL doivent être mises à jour. Lorsque vous mettez à jour le nom d'utilisateur du secret, l'ancien nom d'utilisateur n'est pas automatiquement dissocié. Par conséquent, c'est une bonne pratique de créer un nouveau secret pour le nouvel utilisateur. Si vous devez utiliser l'ancien secret, dissociez d'abord le secret, puis mettez à jour les informations d'identification avant d’associer le secret à nouveau. Pour plus d'informations, consultez la section Travailler avec les utilisateurs.

Les utilisateurs non administrateurs peuvent créer de nouvelles ACL et modifier les ACL existantes

Par défaut, n'importe quel utilisateur peut créer ou modifier des ACL. Pour empêcher les utilisateurs non administrateurs de créer ou de mettre à jour des ACL à l'aide d'Apache ZooKeeper, veillez à restreindre l'accès à Apache ZooKeeper en plaçant les nœuds ZooKeeper dans un groupe de sécurité distinct. Veillez également à ce que toutes les commandes Apache Kafka et les connexions client sont exécutées via des agents d'amorçage au lieu d'Apache ZooKeeper. Notez que toutes les opérations Apache Kafka peuvent être effectuées à l'aide de la chaîne d'amorçage.

Informations connexes

ACL Apache Kafka

Secrets Scram