Control de acceso con ACLs de Kafka

En este documento, se describe cómo usar las listas de control de acceso (ACL) de Apache Kafka para controlar el acceso en Google Cloud Managed Service para Apache Kafka.

Las ACL de Apache Kafka proporcionan un control de acceso detallado dentro del clúster de Kafka. Managed Service para Apache Kafka habilita StandardAuthorizer de forma predeterminada, lo que almacena las ACL en los metadatos del clúster de Kafka basado en KRaft.

Estas LCA controlan qué usuarios autenticados pueden realizar operaciones específicas en recursos específicos de Kafka, como producir o consumir mensajes en un tema.
Estas ACL son útiles para controlar las interacciones con el clúster a través de clientes estándar de Apache Kafka, que solo están sujetos a una verificación de IAM a nivel del clúster para la conexión inicial. Para obtener más información, consulta Control de acceso con IAM.

Cómo funciona el control de acceso de la ACL de Kafka

El cliente interactúa con el autorizador de ACL estándar de Kafka dentro del clúster. El autorizador evalúa las ACL de Apache Kafka pertinentes para autorizar operaciones específicas solicitadas por la entidad principal, como producir en un tema o consumir desde un grupo. La entidad principal que se usa para la verificación de la LCA se deriva de uno de los siguientes métodos de autenticación:

SASL: Es la cuenta principal de IAM, como el correo electrónico de una cuenta de servicio.
mTLS: Es el nombre distinguido (DN) del certificado de cliente, que puede transformarse con reglas de asignación de principales.

Para obtener una seguridad integral, debes configurar lo siguiente:

Permisos de IAM para el acceso de administración Para obtener más información, consulta Control de acceso con IAM.
ACL de Kafka para operaciones y acceso a datos dentro del clúster desde clientes de Apache Kafka de código abierto, independientemente del método de autenticación.

Uso de las ACL de Apache Kafka

Las vinculaciones de ACL de Apache Kafka tienen el siguiente formato:


Principal P is [Allowed/Denied] Operation O From Host H on any resource matching Resource Pattern RP.

A continuación, se incluye una lista de información importante sobre el formato:

Principal(P): Es la identidad del usuario que se autoriza. Tiene el prefijo User:.
- Para la autenticación SASL, esta es la entidad de IAM, como User:my-service-account@my-project.iam.gserviceaccount.com.
- Para la autenticación mTLS, este es el nombre distinguido (DN) del certificado de cliente, como User:CN=my-client,OU=my-org-unit. El formato exacto depende del sujeto del certificado. Las reglas de asignación de principales pueden transformar este valor.
Tipo de permiso(Permitido/Rechazado): Indica si la vinculación de la LCA permite o rechaza el acceso. Las vinculaciones de denegación tienen prioridad.
Operación(O): Es la acción que se realiza, como leer, escribir o crear. Para obtener información sobre qué operaciones se aplican a qué recursos para los distintos protocolos de Kafka, consulta Operaciones y recursos en protocolos en la documentación de Apache Kafka.
Host(H): Es la máquina desde la que se origina la solicitud. Dado que Managed Service para Apache Kafka traduce las direcciones de red del cliente, no se admite el uso de hosts que no sean '*'.
Patrón de recurso(RP): Es un patrón que se usa para hacer coincidir recursos específicos. Un patrón de recursos consta de un tipo de recurso, un nombre de recurso y un tipo de patrón (LITERAL o PREFIXED).

Acceso predeterminado

Los clústeres de Managed Service para Apache Kafka operan con la propiedad allow.everyone.if.no.acl.found de Apache Kafka establecida en true. La presencia o ausencia de LCA de Kafka determina directamente el nivel de acceso a los recursos:

Si no se definen ACLs de Kafka para un recurso específico, como un tema, se les otorga acceso a todos los principales autenticados. Esta configuración permite que los clústeres de Managed Service para Apache Kafka se puedan operar de inmediato, sin necesidad de configurar ACLs.
En cuanto definas cualquier ACL de Kafka para ese recurso, el acceso se restringirá. Solo los principales a los que se les otorgó permiso de forma explícita con una entrada ALLOW en una LCA de Kafka pueden acceder a los recursos coincidentes (a menos que se bloqueen específicamente con una entrada DENY).

Managed Service para Apache Kafka le otorga a su agente de servicio acceso administrativo a tu clúster. Este acceso permite que el agente de servicio realice las operaciones solicitadas por la API de Managed Service para Apache Kafka, independientemente de otras ACL configuradas en el clúster. Managed Service para Apache Kafka logra esto modificando la implementación de StandardAuthorizer. La modificación otorga al agente de servicio permisos similares a los de los superusuarios, excepto para las operaciones de lectura y escritura. No puedes cambiar esta configuración.

Principales de Kafka

Las entidades de Kafka para los clústeres de Managed Service para Apache Kafka se especifican con el prefijo Kafka StandardAuthorizer "User:".

Para SASL/IAM: La principal es la cuenta deGoogle Cloud . Por ejemplo, para otorgar acceso a la cuenta de servicio test-kafka-client@test-project.iam.gserviceaccount.com, usa la principal de Kafka "User:test-kafka-client@test-project.iam.gserviceaccount.com". Los principales de la ACL de Kafka deben especificar un usuario, una cuenta de servicio o un principal de IAM individual, pero no un grupo ni un conjunto de principales. Las ACL de Kafka no admiten la resolución de membresías de grupos para principales de Google Cloud .
Para mTLS: El principal se deriva del nombre distinguido (DN) del asunto del certificado de cliente. Por ejemplo, User:CN=client1,OU=dev,O=MyOrg,L=City,ST=State,C=US. Puedes usar reglas de asignación de principales de mTLS para transformar el DN en una cadena principal más fácil de usar para las ACL.

Para crear una LCA que se aplique a todos los miembros de un Grupo de Google o un conjunto de principales, puedes usar un principal de cuenta de servicio de proxy y la suplantación de identidad de la cuenta de servicio:

Crea una cuenta de servicio para usarla como proxy del grupo.
Otorga al grupo de Google o al conjunto de principales el rol de Creador de tokens de cuenta de servicio en la cuenta de servicio. Consulta Administra el acceso a las cuentas de servicio
Agrega LCA de Kafka para la cuenta de servicio del proxy. Un ejemplo de principal sería el siguiente: User:group-proxy@test-project.iam.gserviceaccount.com.
Usa la suplantación de identidad de la cuenta de servicio en los clientes de Kafka para autenticarte en Kafka como la cuenta de servicio. Google Cloud IAM autoriza a una principal individual como miembro del grupo que puede actuar en nombre de la cuenta de servicio del proxy. Además, Kafka autoriza la cuenta de servicio del proxy en función de las ACL existentes en el clúster.

Operaciones de Kafka para productores y consumidores

Una operación es una acción que se realiza en un recurso. Para cada recurso, una operación se asigna a una o más solicitudes del protocolo de Kafka para ese recurso. Por ejemplo, una operación READ para el tipo de recurso topic se asigna a los protocolos Fetch, OffsetCommit y TxnOffsetCommit de Apache Kafka.

Para otorgar acceso de productor principal a un tema, sigue estos pasos:

En el recurso del tema, permite las operaciones WRITE y CREATE.
Si usas IDs de transacción, en el recurso de ID de transacción, permite la operación WRITE.

Para otorgar acceso de consumidor principal a un tema, sigue estos pasos:

En el recurso del tema, permite la operación READ.
En el recurso del grupo de consumidores, permite la operación READ.

Para obtener más información sobre las operaciones válidas en los recursos que admite la API de Kafka, consulta Operaciones y recursos en protocolos en la documentación de Apache Kafka.

Configura las LCA para el comportamiento de denegación predeterminado

Los clústeres de Kafka administrados se configuran con allow.everyone.if.no.acl.found = true. Por lo tanto, de forma predeterminada, si no se configuran ACL en un recurso, todas las principales pueden acceder a él.

Para configurar un comportamiento de default-deny similar al de IAM, primero puedes configurar el acceso para un usuario administrador en todos los recursos del clúster. Como resultado, cada recurso obtiene una LCA definida, y se suprime el comportamiento de allow.everyone.if.no.acl.found. De forma predeterminada, se deniega el acceso a cualquier principal que no esté permitido de forma explícita por una LCA de ALLOW.

Por ejemplo, para establecer ACL en todos los recursos del clúster para la cuenta de servicio clusterAdmin@test-project.iam.gserviceaccount.com, crea las siguientes entradas de ACL.

El siguiente comando de gcloud CLI otorga a una cuenta de servicio llamada clusterAdmin@test-project.iam.gserviceaccount.com acceso administrativo completo (--operation=ALL) a un clúster de Kafka específico ubicado en una región en particular. Este permiso permite que la cuenta de servicio realice cualquier operación en el clúster desde cualquier host.

gcloud managed-kafka acls add-acl-entry cluster \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

El siguiente comando de gcloud CLI otorga a una cuenta de servicio llamada clusterAdmin@test-project.iam.gserviceaccount.com acceso administrativo completo (--operation=ALL) a todos los temas dentro de un clúster de Kafka específico ubicado en una región en particular. Este permiso permite que la cuenta de servicio realice cualquier operación en todos los temas desde cualquier host.

gcloud managed-kafka acls add-acl-entry allTopics \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

El siguiente comando de gcloud CLI otorga a una cuenta de servicio llamada clusterAdmin@test-project.iam.gserviceaccount.com acceso administrativo completo (--operation=ALL) a todos los grupos de consumidores dentro de un clúster de Kafka específico ubicado en una región en particular. Este permiso permite que la cuenta de servicio realice cualquier operación en todos los grupos de consumidores desde cualquier host.

gcloud managed-kafka acls add-acl-entry allConsumerGroups \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

El siguiente comando de gcloud CLI otorga a una cuenta de servicio llamada clusterAdmin@test-project.iam.gserviceaccount.com acceso administrativo completo (--operation=ALL) a todos los IDs de transacción dentro de un clúster de Kafka específico ubicado en una región en particular. Este permiso permite que la cuenta de servicio realice cualquier operación en todos los IDs de transacción desde cualquier host.

gcloud managed-kafka acls add-acl-entry allTransactionalIds \
    --principal=`User:clusterAdmin@test-project.iam.gserviceaccount.com` \
    --operation=ALL \
    --permission-type=ALLOW \
    --host=* \
    --cluster=CLUSTER_ID \
    --location=LOCATION

A continuación, se incluye una lista de información importante sobre los comandos:

--principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': Es la principal a la que se aplica la ACL. El principal es una cuenta deGoogle Cloud , con el prefijo User: de Kafka StandardAuthorizer.
--operation=all: Es la operación de Kafka que se otorga, que, en este caso, es acceso total.
--permission-type=ALLOW: Esta entrada de LCA otorga acceso.
--host='*': Es el host desde el que la principal puede acceder al recurso. '*' otorga acceso desde cualquier host. Managed Service para Apache Kafka solo admite ACL con el host '*'.
CLUSTER_ID: Es el nombre de tu clúster de Managed Service para Apache Kafka.
LOCATION: Es la región Google Cloud en la que se encuentra tu clúster de Managed Service para Apache Kafka, como us-central1.

Configura las LCA

Puedes configurar las ACL de Apache Kafka con las APIs de ACL de Managed Service para Apache Kafka o con herramientas de Apache Kafka de código abierto, como la CLI del autorizador de Apache Kafka kafka-acls.sh o Admin Client.

Managed Service para Apache Kafka organiza las ACL según los patrones de recursos de Kafka. El patrón de recursos se define de la siguiente manera:

Tipo de recurso: clúster, tema, grupo de consumidores o ID transaccional
Tipo de patrón: literal o con prefijo (todos los recursos cuyo nombre comience con la cadena proporcionada)
Nombre del recurso: Es el nombre o el prefijo del recurso al que se aplican las entradas de la LCA.

Un recurso de ACL de Managed Service para Apache Kafka representa todo el control de acceso configurado para un solo patrón de recursos de Kafka, como una lista repetida de entradas de ACL. El nombre del recurso de LCA identifica de forma única el patrón de recursos de la vinculación de la LCA. Para obtener más información, consulta ID de LCA.

Puedes administrar las ACL de Managed Service para Apache Kafka a nivel del recurso de ACL (todas las entradas de ACL para un patrón de recursos) o de forma incremental agregando y quitando entradas de ACL individuales para un patrón de recursos de ACL.

Para obtener más información, consulta Crea una ACL de Kafka administrada y Agrega una entrada de ACL de Kafka administrada.

Permite la lectura desde un tema

Para permitir que los clientes de Apache Kafka de código abierto que se ejecutan como la cuenta de servicio test-kafka-client@test-project.iam.gserviceaccount.com lean el tema topic-name, crea una entrada de ACL de Managed Service para Apache Kafka con el comando managed-kafka acls add-acl-entry:

gcloud managed-kafka acls add-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=READ \
    --permission-type=ALLOW \
    --host='*'

A continuación, se incluye una lista de información importante sobre el comando:

topic/topic-name: Especifica el tema de Managed Service para Apache Kafka al que deseas otorgar acceso. Reemplaza topic-name por el nombre real de tu tema. El prefijo topic/ indica que esta entrada de LCA se aplica a un patrón de recursos de tema específico (literal).
LOCATION: Es la región Google Cloud en la que se encuentra tu clúster de Managed Service para Apache Kafka, como us-central1.
CLUSTER_ID: Es el nombre de tu clúster de Managed Service para Apache Kafka.
--principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': Es la principal a la que se aplica la ACL. El principal es una cuenta deGoogle Cloud , con el prefijo User: de Kafka StandardAuthorizer.
--operation=READ: Es la operación de Kafka a la que se otorga acceso, que es READ en este caso.
--permission-type=ALLOW: Indica que esta entrada de LCA otorga acceso.
--host='*': Especifica el host desde el que la principal puede acceder al recurso. '*' otorga acceso desde cualquier host. Managed Service para Apache Kafka solo admite ACL con el host '*'.

Para quitar el acceso de lectura, puedes usar el comando remove-acl-entry con los mismos parámetros.

gcloud managed-kafka acls remove-acl-entry topic/topic-name \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=READ \
    --permission-type=ALLOW \
    --host='*'

Permite escribir en todos los temas con un prefijo común

Para permitir que los clientes de Apache Kafka de código abierto que se ejecutan como la cuenta de servicio test-kafka-client@test-project.iam.gserviceaccount.com escriban en todos los temas cuyo nombre comience con el prefijo topic-prefix, agrega una entrada de ACL de Kafka administrado de la siguiente manera:

gcloud managed-kafka acls add-acl-entry topicPrefixed/topic-prefix \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

A continuación, se incluye una lista de información importante sobre el comando:

topicPrefixed/topic-prefix: Especifica el patrón de recursos de Managed Service para Apache Kafka al que deseas otorgar acceso. Reemplaza topic-prefix por el prefijo real de tus temas. El prefijo topicPrefixed/ indica que esta entrada de LCA se aplica a un patrón de recursos con prefijo: todos los temas que coinciden con el prefijo determinado.
PROJECT: Es el ID de tu proyecto Google Cloud en el que se encuentra tu clúster de Managed Service para Apache Kafka.
LOCATION: Es la región Google Cloud en la que se encuentra tu clúster de Managed Service para Apache Kafka, como us-central1.
CLUSTER_ID: Es el nombre de tu clúster de Managed Service para Apache Kafka.
--principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': Principal al que se aplica la LCA. El principal es una cuenta deGoogle Cloud , con el prefijo User: de Kafka StandardAuthorizer.
--operation=WRITE: Es la operación de Kafka a la que se otorga acceso, que es WRITE en este caso.
--permission-type=ALLOW: Esta entrada de LCA otorga acceso.
--host='*': Es el host desde el que la principal puede acceder al recurso. '*' otorga acceso desde cualquier host. Managed Service para Apache Kafka solo admite ACL con el host '*'.

Para quitar el acceso de escritura a esta cuenta de servicio, quita la entrada de la LCA:

gcloud managed-kafka acls remove-acl-entry topicPrefixed/topic-prefix \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=WRITE \
    --permission-type=ALLOW \
    --host='*'

Denegar la modificación de todos los temas

Para evitar que los clientes de Apache Kafka de código abierto que se ejecutan como la cuenta de servicio test-kafka-client@test-project.iam.gserviceaccount.com modifiquen todos los temas de un clúster, puedes crear un recurso de ACL de Managed Service para Apache Kafka con una lista de recursos AclEntry para rechazar las operaciones ALTER, ALTER_CONFIGS y DELETE en todos los temas. Este enfoque define el estado requerido en una sola configuración.

Como alternativa, puedes obtener el mismo resultado agregando de forma imperativa tres entradas de ACL separadas con el comando gcloud managed-kafka acls add-acl-entry. Este método implica ejecutar el comando para denegar el acceso a cada una de las operaciones ALTER, ALTER_CONFIGS y DELETE, de la siguiente manera:

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=ALTER \
    --permission-type=DENY \
    --host='*'

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=ALTER_CONFIGS \
    --permission-type=DENY \
    --host='*'

gcloud managed-kafka acls add-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=DELETE \
    --permission-type=DENY \
    --host='*'

La siguiente información se aplica a cada uno de los comandos de add-acl-entry:

allTopics: Especifica que esta LCA se aplica a todos los temas del clúster de Managed Service para Apache Kafka.
LOCATION: Es la región Google Cloud en la que se encuentra tu clúster de Managed Service para Apache Kafka, como us-central1.
CLUSTER_ID: Es el nombre de tu clúster de Managed Service para Apache Kafka.
--principal='User:test-kafka-client@test-project.iam.gserviceaccount.com': Especifica el principal al que se aplica la LCA. La principal es una cuenta deGoogle Cloud , con el prefijo StandardAuthorizer de Kafka User:.
--operation: Especifica la operación de Kafka que se rechaza:
- ALTER: Incluye acciones como cambiar la cantidad de particiones o el factor de replicación.
- ALTER_CONFIGS: Incluye la modificación de la configuración a nivel del tema.
- DELETE: Incluye el borrado de temas.
--permission-type=DENY: Indica que estas entradas de LCA bloquean el acceso para las operaciones especificadas.
--host='*': Especifica que este rechazo se aplica independientemente del host desde el que se origina la solicitud. Managed Service para Apache Kafka solo admite ACL con el host '*'.

Para quitar estas restricciones, usa el comando remove-acl-entry para cada una de las entradas agregadas con los mismos parámetros. Por ejemplo, para volver a permitir la eliminación de temas, haz lo siguiente:

gcloud managed-kafka acls remove-acl-entry allTopics \
    --cluster=CLUSTER_ID \
    --location=LOCATION
    --principal='User:test-kafka-client@test-project.iam.gserviceaccount.com' \
    --operation=DELETE \
    --permission-type=DENY \
    --host='*'

Solución de problemas relacionados con las LCA

El autorizador estándar de Apache Kafka escribe registros de auditoría de forma predeterminada en las denegaciones de autorización. Si recibes un error de autorización de Kafka, puedes confirmar la principal, el recurso y la operación que se rechazaron buscando StandardAuthorizerData logAuditMessage en los registros del clúster.

Por ejemplo, aquí se muestra un registro de clúster de muestra.

org.apache.kafka.metadata.authorizer.StandardAuthorizerData logAuditMessage\n
INFO: Principal = User:556291496362-compute@developer.iam.gserviceaccount.com is
Denied operation = DESCRIBE from host = 172.16.0.20 on resource = Topic:LITERAL:t1
for request = Metadata with resourceRefCount = 1 based on rule DefaultDeny

¿Qué sigue?

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

Control de acceso con ACLs de Kafka Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.