Comment résoudre les problèmes d'authentification et d'autorisation lorsque j'utilise mon cluster Amazon MSK avec l'authentification SASL/SCRAM activée ?

Résolution

Erreur « ClusterAuthorizationException » dans les journaux de l’agent

Lorsque vous accédez à votre cluster Amazon MSK, le message d'erreur suivant peut s'afficher : « 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. »

L'erreur précédente s'affiche lorsque les deux conditions suivantes sont remplies :

• L'authentification SASL/SCRAM est activée sur votre cluster Amazon MSK.
• Vous définissez ResourceType sur CLUSTER et operation sur CLUSTER_ACTION dans les listes de contrôle d'accès (ACL) de votre cluster.

Le cluster Amazon MSK ne prend pas en charge les paramètres précédents car ceux-ci empêchent la réplication interne d'Apache Kafka. Lorsque les deux conditions précédentes sont remplies, l'identité des agents est ANONYME pour la communication entre les agents. Si vous souhaitez 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. Cette action évite de restreindre la réplication entre les agents.

Pour accorder cette autorisation à l’utilisateur ANONYME, exécutez la commande suivante :

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

Erreur d'authentification SASL

Si vous avez modifié le nom d'utilisateur ou le mot de passe de votre code secret AWS Secrets Manager, mais que les anciennes informations d'identification sont toujours actives, vous recevez une erreur d'authentification.

Un secret AWS Secrets Manager ne peut être associé qu'à un seul utilisateur. Lorsque l'utilisateur n'a plus besoin d'accéder au cluster, vous devez dissocier le secret et mettre à jour l'ACL.

Lorsque vous mettez à jour le nom d'utilisateur du secret, AWS Secrets Manager ne dissocie pas automatiquement l'ancien nom d'utilisateur. Il est recommandé de créer un nouveau secret pour le nouvel utilisateur. Si vous devez utiliser l'ancien secret, dissociez-le d'abord, puis mettez à jour les informations d'identification avant de l'associer à nouveau. Pour plus d’informations, consultez la section Utilisation d’utilisateurs.

Les utilisateurs non administrateurs peuvent créer et modifier des ACL sans autorisation

Par défaut, tous les utilisateurs sont autorisés à créer ou à modifier des ACL. Pour empêcher les utilisateurs non administrateurs de modifier l'ACL via Apache ZooKeeper, placez les nœuds ZooKeeper dans un groupe de sécurité distinct. Assurez-vous également que toutes les commandes et connexions client d'Apache Kafka sont exécutées via des agents bootstrap au lieu d'Apache ZooKeeper.

Remarque : Vous pouvez utiliser la chaîne bootstrap pour effectuer toutes les opérations Apache Kafka.

Informations connexes

Listes ACL Apache Kafka

Secrets Scram