Control de acceso para Managed Service para Apache Kafka

En Managed Service para Apache Kafka, controlas el acceso a tus clústeres y temas de Kafka con una combinación de permisos de Identity and Access Management (IAM) y listas de control de acceso (LCA) de Kafka:

  • Usa IAM para otorgar permisos de acceso de administración y para que los clientes se conecten a un clúster cuando usen la autenticación SASL.

  • Usa las ACL de Kafka para el acceso a los datos y las operaciones de los clientes de Apache Kafka de código abierto.

En esta página, se proporciona una descripción general de estas opciones de control de acceso.

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 una 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

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

  • La API de Managed Kafka Esta opción abarca llamar a las APIs de REST directamente, así como usar Google Cloud CLI, la consola de Google Cloud o las bibliotecas cliente.

  • 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, la autorización la realiza Identity and Access Management (IAM). Para realizar una operación en un recurso, la principal debe tener los permisos de la API de Managed Kafka necesarios para esa operación. En la documentación de cada tarea, se enumeran los roles de IAM necesarios para esa tarea. Por ejemplo, para permitir que una principal cree temas de Kafka, otórgale el rol de editor de temas de Kafka administrado.

Control de acceso con la API de Apache Kafka

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

  • Si un cliente se conecta con SASL, la principal de autenticación necesita el permiso de IAM managedkafka.clusters.connect. Para otorgar este permiso, puedes asignar el rol 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 obtener 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 a los datos dentro del clúster y las operaciones de los clientes de Apache Kafka de código abierto, independientemente del método de autenticación.

Por ejemplo, supongamos que quieres evitar que una principal edite temas. Para ello, debes configurar los siguientes controles de acceso:

  • Deniega al principal el permiso 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 a la principal el permiso managedkafka.clusters.connect para evitar que se conecte al clúster con la autenticación de 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 Deniega la modificación de todos los temas.

Control de acceso a nivel de 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 las 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 actualización de clústeres, devuelven operaciones de larga duración. Si otorgas acceso a nivel del clúster, incluye acceso para todos los recursos del tipo managedkafka.googleapis.com/Operation, además de la condición de recurso por clúster. Este permiso garantiza que el 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.