En esta página, se describen los métodos de autenticación compatibles para las aplicaciones cliente que se conectan a los agentes de Google Cloud Managed Service para Apache Kafka.
Para las aplicaciones cliente de Google Cloud Managed Service para Apache Kafka que se ejecutan en Google Cloud servicios como Google Kubernetes Engine, Compute Engine, Cloud Run o Cloud Run Functions, tienes las siguientes opciones de autenticación:
SASL/OAUTHBEARER (recomendado): Este es el método más seguro y sin interrupciones para los clientes dentro de Google Cloud. Usa credenciales predeterminadas de la aplicación (ADC) para encontrar automáticamente la identidad de la cuenta de servicio asociada con el entorno. Esto elimina la necesidad de administrar y distribuir archivos de credenciales estáticas, como las claves de cuentas de servicio.
SASL/PLAIN: Este es un método útil para el desarrollo inicial. El cliente se autentica con una clave de cuenta de servicio de larga duración.
mTLS: Esta es una opción si el estándar de tu organización es la autenticación basada en certificados. Tu aplicación en Google Cloud está configurada con un certificado y una clave de cliente.
Para las aplicaciones cliente que se ejecutan fuera de Google Cloud, como en un centro de datos local o en otro proveedor de servicios en la nube, considera los siguientes métodos de autenticación. Elige el mejor método según la postura de seguridad y la infraestructura de identidad existente de tu organización.
Federación de identidades para cargas de trabajo con SASL/OAUTHBEARER (recomendado): Este es el método más seguro para los clientes externos. Te permite otorgar identidades de sistemas externos, como AWS, Microsoft Azure o un proveedor de identidad local como ADFS, la capacidad de actuar en nombre de unaGoogle Cloud cuenta de servicio. En lugar de administrar claves de cuentas de servicio de larga duración, el cliente usa su credencial preferida para obtener un Google Cloud token de acceso Google Cloud de corta duración. Luego, el cliente usa este token para la autenticación, lo que reduce significativamente el riesgo de seguridad asociado con los archivos de credenciales estáticas.
mTLS: Este método es independiente del proveedor y es adecuado si tu organización ya usa una infraestructura de clave pública (PKI) para administrar los certificados TLS de identidad del servicio. Permite que los clientes se autentiquen sin una identidad específica de Google Cloud. Sin embargo, al igual que con el uso de claves de cuentas de servicio, este enfoque requiere que administres el ciclo de vida y la distribución de credenciales de larga duración, como los certificados de cliente.
SASL/PLAIN con una clave de cuenta de servicio: Este método proporciona una forma directa para que un cliente externo se autentique como una identidad de Google Cloud . Descarga un archivo JSON de claves de la cuenta de servicio y úsalo en la configuración de SASL/PLAIN de tu cliente. En general, este método no se recomienda para las cargas de trabajo de producción, ya que requiere administrar y proteger una credencial estática de larga duración en el cliente.
Comparación de funciones entre SASL y mTLS
El mecanismo de autenticación principal para Managed Service para Apache Kafka es SASL (Capa de autenticación y seguridad simple), que se integra directamente con los servicios de identidad deGoogle Cloud. Como base, SASL autentica a los clientes con un principal de Google Cloud IAM, como una cuenta de servicio. Para la autorización, SASL proporciona flexibilidad: puedes administrar el acceso a los clústeres con roles de IAM detallados y las listas de control de acceso (LCA) de Kafka.
Por el contrario, la mTLS ofrece un método de autenticación independiente del proveedor que no se basa en Google Cloud IAM. En cambio, la mTLS autentica a un cliente según su certificado TLS, en el que la identidad se deriva del nombre del sujeto del certificado.
Esta distinción genera una diferencia clave en la forma en que se maneja la autorización. A diferencia de las entidades principales de SASL, las entidades principales de mTLS deben autorizarse exclusivamente con las LCA de Kafka; no se pueden administrar con roles de Google Cloud IAM.
Te recomendamos que configures las ACL de Kafka para tu clúster. Si no se configura ninguna LCA, el comportamiento predeterminado de Kafka otorga a todas las entidades autenticadas (ya sea que usen SASL o mTLS) acceso completo al clúster. Para obtener más información sobre cómo configurar las ACL de Kafka, consulta Crea una ACL de Managed Service para Apache Kafka.
Managed Service for Apache Kafka admite la autenticación mTLS con certificados de cliente emitidos por las autoridades certificadoras que se encuentran en el servicio de CA. Si tu organización usa una raíz de confianza externa, puedes integrarla creando una CA subordinada dentro del servicio de CA que se encadena a tu CA externa.
En la siguiente tabla, se comparan las características de los métodos de autenticación.
| Función | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| Identidad principal | Google Cloud Principal de IAM | Google Cloud Principal de IAM | Nombre del sujeto del certificado |
| Tipo de credencial | Credenciales predeterminadas de la aplicación (ADC) o token de OAuth 2.0 | Clave de cuenta de servicio codificada en Base64 | Certificado de cliente y clave privada |
| Método de autorización | Google Cloud Roles de IAM o ACL de Kafka | Google Cloud Roles de IAM o ACL de Kafka | Solo ACL de Kafka |
| Caso práctico | Clientes en Google Cloud; clientes externos que usan la federación de Workload Identity | Clientes simples, situaciones de prueba o sistemas heredados en los que se requiere el uso de una clave de cuenta de servicio | Es independiente del proveedor, por lo que resulta ideal para aplicaciones locales, de múltiples nubes o de PKI existentes. |
| Configuración del cliente | Configuración de JAAS con una clase de controlador de acceso especializada (Java) o un servidor de autenticación local (no Java) | Configuración de JAAS con PlainLoginModule estándar (Java) | Propiedades de almacén de claves y almacén de confianza (por ejemplo, security.protocol=SSL) |
| Disponibilidad del clúster | Todos los clústeres | Todos los clústeres | Clústeres creados después del 24 de junio de 2025 |
Elige entre SASL y mTLS
La elección del método de autenticación se basa en las políticas de seguridad y la infraestructura existente de tu organización. Para la mayoría de los casos de uso, recomendamos usar SASL con Google Cloud IAM.
SASL con Google Cloud IAM o la federación de identidades para cargas de trabajo proporciona la experiencia más flexible e integrada para la autenticación y la autorización. Utiliza el sistema de identidad de Google Cloudcomo la única fuente de información para administrar permisos. Elige esta ruta si quieres hacer lo siguiente:
Administra de forma centralizada los permisos para tus clientes de Kafka con los conocidosGoogle Cloud roles de IAM.
Evita administrar credenciales estáticas en los clientes.
Permite que los clientes de otras nubes, como AWS o Azure, o los proveedores de identidad locales, como Okta o ADFS, se autentiquen con la federación de identidades para cargas de trabajo. Este método proporciona una solución de identidad segura y compatible con cualquier nube sin necesidad de cambiar a un protocolo de autenticación diferente.
Elige mTLS si tu organización tiene un requisito estricto para la autenticación basada en certificados. Esta necesidad surge cuando migras una implementación local existente de Kafka que ya usa certificados TLS para la identidad o cuando la política corporativa exige certificados de cliente para todas las aplicaciones. Si bien la mTLS proporciona una seguridad sólida a nivel del transporte, recuerda que la autorización para los clientes de mTLS se debe administrar exclusivamente con las LCA de Kafka, que son independientes de Google Cloud IAM.
Flujo de trabajo para configurar SASL/PLAIN o SASL/OAUTHBEARER
Para configurar un cliente para que use la autenticación SASL con Managed Service para Apache Kafka, se deben otorgar permisos a la identidad del cliente y, luego, configurar la aplicación cliente según el mecanismo SASL elegido. A continuación, se presenta una descripción general del flujo de trabajo requerido. Para obtener instrucciones detalladas sobre cómo configurar SASL, consulta Configura la autenticación SASL.
Otorga permisos de IAM. Primero, debes otorgar el rol de cliente de Kafka administrado (
roles/managedkafka.client) a la cuenta de servicio que tu cliente usa para la autenticación. Este rol proporciona el permisomanagedkafka.clusters.connectnecesario para conectarse a los clústeres de Kafka dentro del proyecto.Configura el cliente de Kafka. La configuración específica del cliente depende de si usas el mecanismo SASL/OAUTHBEARER o SASL/PLAIN.
Para SASL/OAUTHBEARER (recomendado): Este mecanismo usa las credenciales predeterminadas de la aplicación (ADC). La configuración depende del idioma del cliente:
Clientes de Java: Agrega la biblioteca de autenticación especializada Google Cloud a la ruta de clase de tu aplicación. Luego, configura las propiedades del cliente de Kafka para usar la clase
GcpLoginCallbackHandlerproporcionada, que controla automáticamente la autenticación con ADC.GcpLoginCallbackHandleres una clase que se usa con el mecanismo de autenticación OAUTHBEARER de Kafka, diseñado específicamente para usarse con Managed Service for Apache Kafka. Controla el proceso de obtención de un token web JSON (JWT) del proveedor de identidad de Google, lo que permite que los clientes de Kafka se autentiquen con el servicio mediante ADC.Clientes que no son de Java: Ejecuta un servidor de autenticación local proporcionado en la máquina del cliente. Este servidor usa ADC para recuperar credenciales y proporcionárselas al cliente de Kafka. Luego, el cliente se configura para obtener su token de autenticación del extremo de este servidor local.
Para SASL/PLAIN
Este mecanismo usa una combinación de nombre de usuario y contraseña. La aplicación cliente debe configurarse para usar el protocolo de seguridad SASL_SSL, el mecanismo PLAIN y una configuración de JAAS que especifique la clase
PlainLoginModule.El nombre de usuario es la dirección de correo electrónico de la cuenta de servicio. La contraseña se puede generar de dos maneras:
Codificando en base64 un archivo JSON de claves de cuenta de servicio
Obtener un token de acceso de corta duración
Configura la autorización. Después de que un cliente se autentica correctamente con SASL, su acceso se controla con los permisos definidos en los roles de IAM o las ACL de Kafka en el clúster.
Limitaciones de SASL
El método de autenticación SASL tiene las siguientes limitaciones:
La autenticación SASL está inherentemente vinculada a los principales de IAM. No es adecuado para organizaciones que requieren una separación estricta de la identidad deGoogle Cloud o que usan identidades que no son de Google, a menos que configures la federación de identidades para cargas de trabajo.
SASL no usa certificados de cliente para la autenticación. No es una solución directa para las organizaciones que dependen de una PKI existente para identificar aplicaciones.
Flujo de trabajo para configurar mTLS
La configuración de mTLS para Managed Service for Apache Kafka implica configurar autoridades de certificación, el clúster de Kafka y tus clientes de Kafka. Para obtener instrucciones detalladas sobre cómo configurar mTLS, consulta Configura la autenticación de mTLS.
Configura las autoridades certificadoras (AC). Primero debes crear y configurar grupos de CA en Certificate Authority Service (CA Service). Si creas grupos de CA en un proyecto diferente, asegúrate de otorgar permiso al agente de servicio de Managed Service para Apache Kafka (
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com) para acceder a estos grupos. Debes crear certificados raíz y subordinados dentro de los grupos de CA.Configura el clúster de Kafka. Crea o actualiza tu clúster para habilitar mTLS. Para ello, proporciona los identificadores de recursos de los grupos de AC configurados. También recomendamos configurar la propiedad del agente
ssl.principal.mapping.rulespara crear nombres de principales simplificados para usarlos en las LCA. Puedes hacerlo con los comandos de Google Cloud CLI.Configura los clientes de Kafka. Obtén certificados de cliente de tus AC y, luego, instálalos en el entorno de tu cliente, por ejemplo, en un almacén de claves Java. Luego, la aplicación cliente se debe configurar con el protocolo de seguridad (SSL) correcto y la ubicación de su almacén de claves para conectarse al puerto de arranque mTLS dedicado del clúster, que es
9192.Supervisa mTLS. Después de la configuración, supervisa la métrica
managedkafka.googleapis.com/mtls_truststore_update_countpara verificar que el clúster actualice correctamente sus certificados de CA desde los grupos del servicio de CA, lo que intenta hacer periódicamente. También puedes usar Cloud Logging.
Limitaciones de mTLS
La función de mTLS tiene las siguientes limitaciones:
Solo puedes usar la función de mTLS en clústeres de Managed Service para Apache Kafka creados después del 24 de junio de 2025.
Debes configurar la autorización para las entidades principales de mTLS con las LCA de Kafka. No puedes usar vinculaciones de roles de IAM para autorizar clientes de mTLS.
El servicio solo autentica a los clientes que presentan certificados administrados por el servicio de CA. Sin embargo, puedes integrar una raíz de confianza externa creando una CA subordinada dentro del servicio de CA que se encadena a tu CA externa.
Puedes configurar un clúster para que confíe en un máximo de 10 grupos de entidades certificadoras.