Gestión de la autenticación en las instancias de Event Streams

Event Streams da soporte a dos mecanismos SASL (Simple Authentication and Security Layer) como métodos de autenticación para Event Streams de forma predeterminada: PLAIN y OAUTHBEARER.

El cliente Kafka configurado con SASL PLAIN utiliza una clave de API de IAM como contraseña de texto sin formato en el proceso de autenticación, Event Streams envía la clave de API a IAM para su verificación. Cuando se autentica, este cliente se mantendrá conectado y no necesitará volver a autenticarse hasta que se desconecte y desee volver a conectarse.

El cliente Kafka configurado con SASL OAUTHBEARER utiliza la señal de acceso de IAM en el proceso de autenticación, Event Streams verifica la señal mediante la clave pública de IAM. Puesto que una señal de acceso de IAM tiene una hora de caducidad (normalmente a una hora), se necesita el cliente Kafka para volver a generar una nueva señal y volver a pasar por el proceso de autenticación cuando la señal anterior se acerca a la hora de caducidad. Este enfoque proporciona una mejor seguridad en comparación con SASL PLAIN de dos maneras:

  1. La clave de API siempre permanece en el lado del cliente para generar la señal de acceso y ya no se envía a los intermediarios de Kafka a través de la red, lo que elimina el riesgo de exposición de la clave de API.
  2. El proceso de autenticación se produce de forma regular cuando la señal de acceso caduca y esto minimiza el riesgo de exposición de la señal.

Para una autenticación más segura, SASL OAUTHBEARER es el único método de autenticación recomendado para los clientes Kafka. Consulte Configuración del cliente de API de Kafka sobre cómo configurar SASL OAUTHBEARER en clientes Kafka.

Los usuarios de empresa tienen la opción de inhabilitar SASL PLAIN en sus instancias de empresa. Utilice el siguiente comando:

ibmcloud resource service-instance-update <instance-name> -p '{"iam_token_only":true}'

Conexión a Event Streams

Para obtener más información sobre cómo obtener una credencial de clave de seguridad para una aplicación externa, consulte Conexión a Event Streams.

Gestión de la autorización para los recursos de Event Streams

Puede proteger los recursos de Event Streams de forma muy precisa para gestionar el acceso que desea otorgar a cada usuario sobre cada recurso.

Cuando se cambian las políticas y permisos de IAM, a veces pueden tardar varios minutos en reflejarse en el servicio subyacente.

¿Qué puedo proteger?

En Event Streams, tiene acceso seguro a los recursos siguientes:

  • Clúster (clúster): puede controlar qué aplicaciones y usuarios pueden conectarse al servicio.
  • Temas (tema): puede controlar la capacidad de los usuarios y las aplicaciones para crear, suprimir, leer y escribir en un tema.
  • Grupos de consumidores (grupo): puede controlar la capacidad de una aplicación para unirse a un grupo de consumidores.
  • Transacciones de productor (txnid): puede controlar la posibilidad de utilizar la función de productor transaccional en Kafka (es decir, escrituras únicas y atómicas en varias particiones).

Los niveles de acceso (también conocidos como rol) que puede asignar a un usuario a cada recurso son los siguientes.

Ejemplo Event Streams funciones y acciones de usuario
Rol de acceso Descripción de acciones Acciones de ejemplo
Lector Realizar acciones de sólo lectura dentro de Event Streams como ver recursos. Permitir que una aplicación se conecte a un clúster mediante la asignación de acceso de lectura al tipo de recurso de clúster.
Writer Los escritores tienen más permisos que el rol de lector, que incluyen la edición de recursos de Event Streams. Permitir que una aplicación produzca temas mediante la asignación de acceso de escritura a los tipos de nombre de tema y recurso de tema.
Gestor Los gestores tienen más permisos que el rol de escritor para completar acciones con privilegios. Además, pueden crear y editar recursos de Event Streams. Permitir el acceso completo a todos los recursos mediante la asignación del acceso de gestión a la instancia de Event Streams.

¿Cómo se asigna el acceso?

Se adjuntan políticas de Cloud Identity and Access Management (IAM) a los recursos que se van a controlar. Cada política define el nivel de acceso que debe tener un usuario concreto y a qué recurso o conjunto de recursos. Una política consta de la información siguiente:

  • El tipo de servicio al que se aplica la política. Por ejemplo, Event Streams. Puede definir el ámbito de una política de modo que incluya todos los tipos de servicio.
  • La instancia del servicio que se va a proteger. Puede definir el ámbito de una política de modo que incluya todas las instancias de un tipo de servicio.
  • El tipo de recurso que se va a proteger. Los valores válidos son cluster, topic, group, schema o txnid. La especificación de un tipo es opcional. Si no especifica un tipo, la política se aplica a todos los recursos de la instancia de servicio. Si desea especificar más de un tipo de recurso, debe crear una política por recurso.
  • El recurso que se va a proteger. Especifique los recursos de tipo topic, group, schema y txnid. Si no especifica el recurso, la política se aplica a todos los recursos del tipo especificado en la instancia de servicio.
  • El rol que se asigna al usuario. Por ejemplo, lector, escritor o gestor.

Para obtener más información sobre IAM, utilice IBM Cloud Identity and Access Management.

Para ver un ejemplo de cómo establecer políticas, consulte IBM Cloud IAM Service IDs and API Keys.

Recurso de comodín

Puede aprovechar el recurso de comodín de IAM para establecer políticas para grupos de recursos en Event Streams. Por ejemplo, si das a todos tus temas nombres como Dept1_Topic1 y Dept1_Topic2, puedes establecer políticas para temas que se llamen Dept1_* y estas políticas se aplican a todos los temas con ese prefijo. Para obtener más información, consulte Asignación de acceso mediante políticas comodín.

¿Cuáles son los valores de seguridad predeterminados?

De forma predeterminada, cuando se suministra Event Streams, al usuario que lo ha suministrado se le otorga el rol de gestor sobre todos los recursos de la instancia. Además, cualquier usuario que tenga un rol de administrador para 'Todos' los servicios o 'Todos' Event Streams las instancias de servicio en la misma cuenta también tiene acceso completo.

A continuación, puede aplicar más políticas para ampliar el acceso a otros usuarios. Puede definir el ámbito de una política de modo que se aplique a Event Streams en conjunto o a recursos individuales de Event Streams. Para más información, consulte Acciones comunes.

Sólo los usuarios con un rol de administración para una cuenta pueden asignar políticas a los usuarios. Para asignar políticas, utilice el panel de control de IBM Cloud o los mandatos ibmcloud.

Acciones comunes

Las tablas siguientes resumen algunas acciones comunes de Event Streams y el acceso que necesita asignar.

Requisitos del clúster

Al controlar el acceso al recurso de clúster, puede determinar qué aplicaciones y usuarios se pueden conectar al servicio. Además de las políticas necesarias para los tipos de recursos siguientes, es necesario acceder a ResourceType: Cluster y a un Role: Reader, Writer, Manager.

Acciones de productor

En la tabla siguiente se describen los requisitos de rol y recurso que necesita un usuario o una aplicación que genera mensajes para Event Streams. Además de las políticas necesarias para este tipo de recurso, es necesario acceder a ResourceType: Cluster y a un Role: Reader, Writer, Manager.

Acciones de los productores
Acciones de productor Tema Grupo txnid
Enviar un mensaje a un tema. Writer Writer [1]
Permitir que una aplicación produzca a un tema de forma transaccional. Writer Lector Writer
Inicializar una transacción. Writer
Confirmar una transacción. Writer Writer
Terminar anormalmente una transacción. Writer
Enviar desplazamientos a una transacción. Lector Writer

Acciones del consumidor

La tabla siguiente describe los requisitos de rol y recurso que necesita un usuario o aplicación que consume mensajes de Event Streams. Además de las políticas necesarias para este tipo de recurso, es necesario acceder a ResourceType: Cluster y a un Role: Reader, Writer, Manager.

Acciones de los consumidores
Acciones del consumidor Tema Grupo txnid
Permitir que una aplicación consuma un tema (grupo de consumidores). Lector Lector [2]
Permitir que una aplicación se conecte y consuma desde un tema específico (sin grupo de consumidores). Lector
Permitir que una aplicación se conecte y consuma desde cualquier tema (sin grupo de consumidores). Lector
Utilice Kafka Streams. Gestor Lector
Suprimir grupo de consumidores. Gestor
Asignar. Lector
Confirmar asíncrono. Lector Lector
Confirmar sincronización. Lector Lector
Imponer reequilibrio. Lector
Sondeo. Lector
Suscribirse. Lector
Anular suscripción. Lector Writer

Acciones de administración

Además de las políticas necesarias para este tipo de recurso, es necesario acceder a ResourceType: Cluster y a un Role: Reader, Writer, Manager.

Acciones de la Administración
Acciones de administración Tema Grupo txnid
Modificar configuraciones de tema. Gestor
Modificar desplazamientos de grupo de consumidores. Lector Lector
Cree particiones. Gestor
Crear temas. Gestor
Suprimir desplazamientos de grupo de consumidores. Lector Gestor
Suprimir grupos de consumidores. Gestor
Suprimir registros. Gestor
Suprimir temas. Gestor
Describa a los productores. Lector
Productores de vallas. Writer
Modifique de forma incremental las configuraciones de tema. Gestor
Eliminar miembros del grupo de consumidores. Lector

Acciones de registro de esquema

Con las acciones de registro de esquema, puede modificar la versión del esquema, como por ejemplo crear, actualizar y suprimir artefactos o versiones de artefactos (solo plan Enterprise). Artefacto es el término que Event Streams utiliza para describir esquemas relacionados, a menudo asociados y utilizados por un tema Kafka determinado. El término asunto se utiliza a menudo para describir el mismo concepto. Para obtener más información, consulte Utilización del registro de esquemas de Event Streams. Además de las políticas necesarias para este tipo de recurso, es necesario acceder a ResourceType: Cluster y a un Role: Reader, Writer, Manager.

Acciones del Registro de Esquemas
Acciones de registro de esquema Esquema
Obtener artefacto más reciente. Lector
Listar versiones. Lector
Obtener versión. Lector
Obtener metadatos por contenido. Lector
Obtener metadatos. Lector
Obtener metadatos de versión. Lector
Obtenga la serie de esquema identificada por el ID de entrada. Lector
Recuperar sólo el esquema identificado por el ID de entrada. Lector
Obtenga los pares de versión de asunto identificados por el ID de entrada. Lector
Obtener una lista de versiones registradas bajo el asunto especificado. Lector
Obtener regla de compatibilidad de artefacto. Lector
Obtener una versión específica del esquema registrado bajo este asunto. Lector
Obtener el esquema para la versión especificada de este asunto. Lector
Registrar un nuevo esquema bajo el asunto especificado (si la versión ya existe). Lector
Compruebe si un esquema ya se ha registrado bajo el asunto especificado. Lector
Obtener una lista de los ID de esquemas que hacen referencia al esquema con el asunto y la versión dados. Lector
Pruebe la compatibilidad del esquema de entrada con una versión determinada del esquema de un sujeto. Lector
Realice una comprobación de compatibilidad en el esquema con una o más versiones del asunto. Lector
Obtener nivel de compatibilidad para un asunto. Lector
Registrar un nuevo esquema bajo el asunto especificado (si se va a crear la versión). Writer
Crear artefacto. Writer
Actualizar artefacto. Writer
Inhabilitar artefacto. Writer
Crear versión. Writer
Suprimir versión. Gestor
Actualizar estado de artefacto. Gestor
Actualizar estado de versión. Gestor
Suprimir artefacto. Gestor
Crear regla de compatibilidad de artefacto. Gestor
Actualizar regla de compatibilidad de artefactos. Gestor
Actualizar el nivel de compatibilidad para el asunto especificado. Gestor
Suprimir regla de compatibilidad de artefacto. Gestor
Suprime el asunto especificado y su nivel de compatibilidad asociado si está registrado. Gestor
Suprimir una versión específica del esquema registrado bajo este asunto. Gestor
Suprime la configuración de nivel de compatibilidad de nivel de asunto especificada y vuelve al valor predeterminado global. Gestor
Actualice la regla de compatibilidad global. [3]
Actualice el nivel de compatibilidad global. [4]

Acciones de compatibilidad de registro de esquema

Para la interoperación con aplicaciones existentes, el registro de esquemas de Event Streams da soporte a un subconjunto de la API de registro de esquemas de Confluent v7.2. Para realizar estas acciones, necesita el siguiente acceso a nivel de recurso.

Tabla de acciones de compatibilidad
Acciones de compatibilidad de registro de esquema Esquema
Obtenga la serie de esquema identificada por el ID de entrada. Lector
Recupera sólo el esquema identificado por el ID de entrada. Lector
Obtener los tipos de esquema que están registrados con el registro de esquema.
Obtenga los pares de versión de asunto identificados por el ID de entrada. Lector
Obtener una lista de asuntos registrados.
Obtener una lista de versiones registradas bajo el asunto especificado. Lector
Suprime el asunto especificado y su nivel de compatibilidad asociado si está registrado. Gestor
Obtener una versión específica del esquema registrado bajo este asunto. Lector
Obtener el esquema para la versión especificada de este asunto. Lector
Registrar un nuevo esquema bajo el asunto especificado. Lector/Escritor [5]
Compruebe si un esquema ya se ha registrado bajo el asunto especificado. Lector
Suprime una versión específica del esquema registrado bajo este asunto. Gestor
Obtener una lista de los ID de esquemas que hacen referencia al esquema con el asunto y la versión dados. Lector
Pruebe la compatibilidad del esquema de entrada con una versión determinada del esquema de un sujeto. Lector
Realice una comprobación de compatibilidad en el esquema con una o más versiones del asunto. Lector
Actualizar nivel de compatibilidad global. [6]
Obtener nivel de compatibilidad global.
Actualizar el nivel de compatibilidad para el asunto especificado. Gestor
Obtener nivel de compatibilidad para un asunto. Lector
Suprime la configuración de nivel de compatibilidad de nivel de sujeto especificada y vuelve al valor predeterminado global. Gestor

Gestión del acceso al registro de esquemas

El modelo de autorización para el Registro de Esquemas utiliza el mismo estilo de políticas que se describen en la sección Gestión de la autorización a sus recursos Event Streams de este documento.

Recursos de IAM

Con el nuevo tipo de recurso schema IAM, es posible crear políticas que controlen el acceso utilizando distintos grados de granularidad, como en los siguientes ejemplos.

  • Un esquema específico.
  • Conjunto de esquemas seleccionados mediante una expresión comodín.
  • Todos los esquemas almacenados por una instancia de IBM Event Streams.
  • Todos los esquemas almacenados por todas las instancias de IBM Event Streams en una cuenta.

Event Streams ya tiene el concepto de un tipo de recurso de clúster. Se utiliza para controlar todos los accesos a la instancia de servicio, siendo necesario el rol mínimo de Lector para acceder a cualquier endpoint Kafka o HTTPS. Este uso del tipo de recurso clúster también se aplica al Registro de Esquemas, por lo que se requiere un rol mínimo de Lector para acceder al registro.

Ejemplo de escenarios de autorización

La siguiente tabla describe algunos ejemplos de escenarios para interactuar con el Event Streams Schema Registry, junto con los roles que requieren los actores implicados. El proceso de gestión de esquemas se maneja por separado para desplegar aplicaciones. Por tanto, se necesitan políticas tanto para el ID de servicio que gestiona los esquemas en el registro como para la aplicación que se conecta al registro.

Ejemplos de situaciones de autorización
Escenario Rol de persona o proceso Recurso de persona o proceso Rol de aplicación Recurso de aplicación
Las nuevas versiones de esquema se colocan en el registro por una persona o proceso que está separado de las aplicaciones que utilizan los esquemas. Reader
Writer
cluster
schema
Reader
Reader
cluster
schema
Para añadir un esquema al registro es necesario especificar una regla no predeterminada que controle cómo se permite que evolucionen las versiones del esquema. Reader
Manager
cluster
schema
No aplicable No aplicable
Los esquemas se gestionan junto con el código de aplicación que utiliza el esquema. Las nuevas versiones del esquema se crean en el momento en que una aplicación intenta utilizar la nueva versión del esquema. No aplicable No aplicable Reader
Writer
cluster
schema
Se cambia la regla predeterminada global que controla la evolución del esquema. Manager cluster No aplicable No aplicable

  1. El grabador en txnid sólo es necesario para la producción transaccional. ↩︎

  2. El lector del grupo sólo es necesario si la asignación hace que el consumidor abandone su grupo actual. ↩︎

  3. No necesita acceso al recurso de esquema, en su lugar se necesita acceso de gestor en el recurso de clúster. ↩︎

  4. No necesita acceso al recurso de esquema, en su lugar se necesita acceso de gestor en el recurso de clúster. ↩︎

  5. Lector si la versión ya existe, Escritor si la versión se va a crear mediante la llamada de API. ↩︎

  6. No necesita acceso al recurso de esquema, en su lugar se necesita acceso de gestor en el recurso de clúster. ↩︎