Control de acceso para Managed Service para Apache Kafka

En este documento, se describe cómo funciona el control de acceso en Managed Service para Apache Kafka.

Agente de servicio de Kafka administrado

Managed Service para Apache Kafka usa un agente de servicio para acceder a los recursos de Google Cloud. Después de habilitar la API de Managed Kafka, se crea el agente de servicio de Managed Kafka.

El agente de servicio de Kafka administrado es un principal con el identificador service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com, en el que PROJECT_NUMBER es el número de tu proyecto de Google Cloud .

Este agente de servicio requiere el rol de IAM de agente de servicio de Kafka administrado (roles/managedkafka.serviceAgent) en el proyecto. Este rol se otorga automáticamente cuando habilitas la API. Si revocas este rol, Managed Service para Apache Kafka no podrá crear, actualizar ni borrar clústeres.

Para algunas tareas, el agente de servicio de Kafka administrado requiere roles adicionales. Por ejemplo, si usas Kafka Connect, es posible que debas otorgar permiso al agente de servicio para acceder a fuentes y receptores, como Pub/Sub o BigQuery.

Control de acceso para clientes

En general, hay dos formas de realizar operaciones en los recursos de Managed Service para Apache Kafka:

  • Es la API de Managed Kafka. Esta opción abarca las llamadas directas a las APIs de REST, así como el uso de Google Cloud CLI, la consola de Google Cloud o las bibliotecas cliente.

  • Es la API de Apache Kafka de código abierto. Muchos clientes de Kafka de código abierto usan esta API.

Control de acceso con la API de Managed Kafka

Cuando se usa la API de Managed Kafka, Identity and Access Management (IAM) realiza la autorización. Para realizar una operación en un recurso, la principal debe tener los permisos necesarios de la API de Managed Kafka para esa operación. En la documentación de cada tarea, se indican los roles de IAM necesarios para realizarla. Por ejemplo, para permitir que una principal cree temas de Kafka, otórgale el rol de Editor del tema de Kafka administrado.

Control de acceso con la API de Apache Kafka

Los clientes que usan la API de Apache Kafka se autentican con SASL o TLS mutua (mTLS).

  • Si un cliente se conecta con SASL, el principal de autenticación necesita el permiso de IAM managedkafka.clusters.connect. Para otorgar este permiso, puedes asignar el rol de Cliente de Kafka administrado (roles/managedkafka.client) a la principal.

  • Si un cliente se conecta con mTLS, no se requiere el permiso managedkafka.clusters.connect. En cambio, los clientes usan certificados de cliente para autenticarse.

Después de que el cliente se conecta, el servicio usa ACL de Kafka para autorizar las operaciones del cliente, como leer o alterar recursos.

Control de acceso combinado

Para una seguridad integral, debes configurar lo siguiente:

  • Permisos de IAM para el acceso de administración

  • Permiso de IAM para conectarse al clúster, si los clientes usan SASL.

  • ACL de Kafka para el acceso y las operaciones de datos en el clúster desde clientes de Apache Kafka de código abierto, independientemente del método de autenticación.

Por ejemplo, supongamos que deseas evitar que una principal edite temas. Para ello, deberás configurar los siguientes controles de acceso:

  • Deniega al principal el permiso de managedkafka.topics.update para evitar que use la API de Managed Kafka para actualizar temas (por ejemplo, con la consola de Google Cloud ).

  • De manera opcional, deniega el permiso managedkafka.clusters.connect a la principal para evitar que se conecte al clúster con autenticación SASL.

  • Si la principal necesita acceso a SASL por otros motivos o si se conecta con mTLS, crea una ACL de Kafka que rechace las operaciones ALTER, ALTER_CONFIGS y DELETE en los temas. Para ver ejemplos específicos, consulta Cómo rechazar la modificación de todos los temas.

Control de acceso a nivel del recurso

Para restringir los permisos de IAM de una principal a recursos específicos de Managed Service para Apache Kafka dentro de un proyecto, como clústeres o temas individuales, usa condiciones de IAM.

En el siguiente ejemplo, se muestra una condición de IAM que permite el acceso solo si el tipo de recurso es managedkafka.googleapis.com/Topic y el nombre del recurso termina en "test-topic":

{
    "expression": "resource.name.endsWith(\"topic-1\") &&\nresource.type == \"managedkafka.googleapis.com/Topic\"",
    "title": "topic-1",
    "description": "Grant access only to topic-1"
}

Algunas solicitudes de Managed Service para Apache Kafka, como la creación o las actualizaciones de clústeres, devuelven operaciones de larga duración. Si otorgas acceso a nivel del clúster, incluye acceso para todos los recursos de tipo managedkafka.googleapis.com/Operation, además de la condición de recurso por clúster. Este permiso garantiza que la entidad principal pueda iniciar la operación y supervisar su progreso.

¿Qué sigue?

Apache Kafka® es una marca registrada de The Apache Software Foundation o sus afiliados en Estados Unidos y otros países.