What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SASL/PLAIN y SCRAM son dos mecanismos de autenticación que Apache Kafka admite para que un broker verifique la identidad de un cliente antes de aceptar una producción o un consumo. La diferencia práctica está en cómo se valida la contraseña y en dónde se almacenan las credenciales. En ambos casos, la documentación oficial de Apache Kafka recomienda combinarlos con TLS mediante SASL_SSL, porque la autenticación por sí sola no cifra el tráfico.
Una configuración funcional rara vez se reduce a unas pocas propiedades. Hay que definir listeners, certificados, credenciales, y permisos de autorización, y el tiempo que requiere cada paso depende de la arquitectura del clúster. Por eso esta guía se centra en las decisiones y en los puntos de coincidencia, no en un procedimiento de minutos.
Qué hace cada capa de seguridad
Antes de elegir un mecanismo conviene separar tres funciones que suelen confundirse:
- Autenticación (SASL): verifica quién es el cliente. PLAIN, SCRAM-SHA-256 y SCRAM-SHA-512 son mecanismos SASL que Kafka admite, junto con otros.
- Cifrado en tránsito (TLS/SSL): protege el canal para que nadie pueda leer lo que viaja por la red. Un protocolo
SASL_SSLcombina ambas capas;SASL_PLAINTEXTaplica SASL sin cifrado. - Autorización (ACL u otro servicio): decide qué puede hacer ese usuario sobre cada topic o grupo. Que Kafka reconozca a un principal no le concede permisos de lectura o escritura.
Cuando un cliente falla, casi siempre es porque una de estas tres capas no coincide con lo que configuró el broker.
#1 Best Overall
Qué debe coincidir entre broker y cliente
Antes de tocar credenciales, revise estos puntos en ambos lados:
- El protocolo de seguridad (
security.protocol) debe corresponder a un listener que el broker tenga abierto. - El mecanismo (
sasl.mechanism) debe estar habilitado en el broker. Un cliente que pida SCRAM-SHA-512 contra un broker que solo tenga PLAIN habilitado no podrá autenticarse. - El usuario y la contraseña de la configuración JAAS del cliente deben existir en el almacén que el broker consulta para ese mecanismo.
- Si el clúster autentica las conexiones entre brokers con SASL, la configuración inter-broker debe ser coherente con la del resto de listeners.
- Las instrucciones de aprovisionamiento deben corresponder a la versión exacta de Kafka que ejecuta el clúster.
SASL/PLAIN
PLAIN es el mecanismo más directo: el cliente envía usuario y contraseña, y el broker los compara con los valores que tiene configurados. Por esa razón, la documentación oficial lo condiciona de forma explícita a SSL. La cita exacta de Apache Kafka es: “SASL/PLAIN should be used only with SSL as transport layer to ensure that clear passwords are not transmitted on the wire without encryption.”
Rank #2
Configuración del cliente
El cliente usa el módulo PlainLoginModule dentro de sasl.jaas.config. Un ejemplo reducido de propiedades es el siguiente. Sustituya el valor de ejemplo por un secreto real gestionado fuera del archivo versionado:
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required
username="alice"
password="<secreto>";Este ejemplo no incluye los ajustes de truststore y keystore de TLS, que deben configurarse aparte.
Rank #3
Configuración del broker
En el broker, la documentación de Apache Kafka muestra una entrada KafkaServer con el módulo org.apache.kafka.common.security.plain.PlainLoginModule, las credenciales que el broker usa para sí mismo y una entrada user_<nombre> por cada usuario válido. Esas claves son secretos: deben protegerse igual que cualquier contraseña de producción.
Alternativa con callback handlers
Desde Kafka 2.0, la documentación describe callback handlers personalizados. Permiten obtener credenciales de una fuente externa y validar contraseñas contra un servidor de autenticación externo, en lugar de mantener las entradas user_ dentro del archivo de configuración del broker. Es una opción útil cuando las contraseñas ya se gestionan en otro sistema, pero exige desarrollar o integrar ese componente.
Rank #4
- Metamorphosis: Franz Kafka (Little Clothbound Classics)
SASL/SCRAM
Kafka admite SCRAM-SHA-256 y SCRAM-SHA-512. A diferencia de PLAIN, el mecanismo no transmite la contraseña en claro durante el intercambio, aunque la documentación oficial sigue recomendando TLS para proteger esos intercambios. Para habilitarlo, el broker debe tener activado el mecanismo y el usuario debe tener una credencial SCRAM creada en el almacén que corresponde a su versión.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Dónde se guardan las credenciales según la versión
| Versión de la documentación consultada | Almacén de credenciales SCRAM | Implicación práctica |
|---|---|---|
| Apache Kafka 4.3, “Authentication using SASL” | Metadata log, que es la implementación predeterminada. | La creación de credenciales se describe con herramientas como kafka-storage.sh o kafka-configs.sh. Use los parámetros de la documentación de su versión exacta. |
| Apache Kafka 3.6, “Authentication using SASL” | ZooKeeper. | Los pasos de aprovisionamiento son distintos. No los mezcle con los de un clúster KRaft. |
La diferencia de almacén no cambia el lado del cliente: security.protocol, sasl.mechanism y el módulo JAAS siguen la misma forma. Lo que cambia es cómo se crea y se consulta la credencial en el clúster.
Configuración del cliente
Un ejemplo reducido de propiedades para SCRAM-SHA-256 es:
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="<secreto>";Para SHA-512, cambie sasl.mechanism a SCRAM-SHA-512, siempre que el broker también lo tenga habilitado y la credencial se haya creado para ese mecanismo.
Comparación de PLAIN y SCRAM
| Eje | SASL/PLAIN | SASL/SCRAM-SHA-256 o SCRAM-SHA-512 |
|---|---|---|
| Módulo JAAS del cliente | PlainLoginModule |
ScramLoginModule |
| Transporte recomendado por Apache Kafka | SASL_SSL. La documentación indica que solo debe usarse con SSL para no transmitir contraseñas en claro. |
SASL_SSL. La documentación recomienda TLS para proteger los intercambios SCRAM. |
| Qué debe preparar el broker | Entradas user_<nombre> o un callback handler que valide contraseñas. |
Habilitar el mecanismo y crear la credencial en el almacén de su versión. |
| Dónde viven las credenciales | En la configuración del broker o en un sistema externo mediante callback handler. | En el metadata log (4.3, predeterminado) o en ZooKeeper (3.6), según la documentación consultada. |
| Rendimiento comparado | Not stated: las fuentes oficiales consultadas no publican mediciones. | Not stated: las fuentes oficiales consultadas no publican mediciones. |
La tabla compara configuración y operación, no velocidad. Si necesita una decisión, considere primero dónde debe vivir el secreto de cada usuario y qué herramienta de su equipo puede administrarlo.
Cómo elegir
- Elija SCRAM si quiere credenciales administradas dentro del propio clúster y no necesita que las contraseñas se validen contra un sistema externo.
- Elija PLAIN con callback handler si sus contraseñas ya viven en un servidor de autenticación corporativo y tiene capacidad para mantener ese componente.
- Elija PLAIN con entradas en el broker solo en entornos de laboratorio o con un plan explícito para retirarlo, porque cada cambio de usuario implica editar y reiniciar la configuración del broker.
Errores frecuentes y cómo evitarlos
- Usar SASL_PLAINTEXT con credenciales reales. La recomendación oficial es SSL para PLAIN y TLS para SCRAM. Si necesita una prueba temporal sin cifrado, no reutilice esas contraseñas en producción.
- Confundir autenticación con autorización. Si el cliente conecta pero recibe errores al producir o consumir, revise las ACL del topic o grupo; el error de autenticación y el de autorización tienen causas distintas.
- Pedir un mecanismo no habilitado. Compare
sasl.mechanismdel cliente con los mecanismos activos del listener del broker. - Seguir comandos de otra versión. Los pasos para crear credenciales SCRAM cambian entre ZooKeeper y metadata log. Verifique la versión exacta antes de ejecutar nada.
- Dejar secretos en el repositorio o en los logs. Use un gestor de secretos o variables de entorno, y no pegue contraseñas reales en ejemplos, tickets o capturas de configuración.
Para la documentación oficial de cada versión, consulte las páginas “Authentication using SASL” y “Security Overview” de Apache Kafka 4.3, y “Authentication using SASL” de Apache Kafka 3.6.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
