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 Google Cloud recursos. Después de habilitar la API de Kafka administrado, se crea el agente de servicio de Kafka administrado.

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 tu Google Cloud número de proyecto.

Este agente de servicio requiere el rol de IAM 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 al agente de servicio permiso 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 Kafka administrado. Esta opción abarca la llamada directa a las APIs de REST, así como el uso de Google Cloud CLI, la Google Cloud consola 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 Kafka administrado

Cuando se usa la API de Kafka administrado, 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 Kafka administrado 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 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 con 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 otorgar el rol Cliente de Kafka administrado (roles/managedkafka.client) en la principal.

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

Después de que el cliente se conecta, el servicio usa las ACL de Kafka para autorizar las operaciones del cliente, como leer o modificar 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 a los datos y las operaciones dentro del 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, debes configurar los siguientes controles de acceso:

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

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

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

Control de acceso a nivel de los recursos

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 las actualizaciones de clústeres, muestran 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 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 de Estados Unidos y otros países.