Come posso risolvere i problemi più comuni quando utilizzo il mio cluster Amazon MSK con autenticazione SASL/SCRAM?

Risoluzione

Nei registri del broker viene segnalato l'errore ClusterAuthorizationException

Potresti vedere il seguente messaggio di errore quando accedi al 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.

Questo errore viene visualizzato quando si verificano entrambe le seguenti condizioni:

• Il cluster Amazon MSK ha abilitato l'autenticazione SASL (Simple Authentication and Security Layer) /SCRAM (Salted Challenge Response Mechanism).
• Hai impostato resourceType=CLUSTER e operation=CLUSTER_ACTION nelle liste di controllo degli accessi (ACL) per il tuo cluster.

Il cluster Amazon MSK non supporta questa impostazione perché impedisce la replica interna di Apache Kafka. Con questa impostazione, l'identità dei broker appare come ANONYMOUS per la comunicazione tra broker. Se hai bisogno che il cluster supporti questi ACL durante l'utilizzo dell'autenticazione SASL/SCRAM, allora devi concedere le autorizzazioni per TUTTE le operazioni all'utente ANONYMOUS. Ciò impedisce la limitazione della replica tra i broker. Usa il seguente comando per concedere questa autorizzazione all'utente ANONYMOUS:

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

Hai cambiato il nome utente e/o la password per il tuo segreto di AWS Secrets Manager, ma le vecchie credenziali sono ancora attive

Un segreto di AWS Secrets Manager deve essere associato a un singolo utente. Se l'utente non ha più bisogno di accedere al cluster, il segreto deve essere dissociato e gli ACL devono essere aggiornati. Quando aggiorni il nome utente sul segreto, il vecchio nome utente non viene dissociato automaticamente. Pertanto, è una best practice creare un nuovo segreto per il nuovo utente. Se è necessario utilizzare il vecchio segreto, prima dissocia il segreto e quindi aggiorna le credenziali prima di associare nuovamente il segreto. Per ulteriori informazioni, consulta la pagina Lavorare con gli utenti.

Gli utenti non amministratori sono in grado di creare nuovi ACL e modificare gli ACL esistenti

Di default, qualsiasi utente può creare o modificare gli ACL. Per impedire agli utenti non amministratori di creare o aggiornare ACL utilizzando Apache ZooKeeper, assicurati di limitare l'accesso ad Apache ZooKeeper inserendo i nodi ZooKeeper in un gruppo di sicurezza separato. Inoltre, assicurati che tutti i comandi e le connessioni client di Apache Kafka vengano eseguiti tramite broker di bootstrap invece di Apache ZooKeeper. Ti ricordiamo che tutte le operazioni di Apache Kafka possono essere eseguite utilizzando la stringa di bootstrap.

Informazioni correlate

ACL Apache Kafka

Segreti Scram