Apache RocketMQ ACL 2.0 nueva actualización

Mobile 2024-04-26 23:44:31 views: null

Autor: Tu Zhong

introducción

Como middleware de mensajería distribuida popular, RocketMQ se usa ampliamente en varios sistemas y microservicios distribuidos a gran escala. Desempeña un papel importante en la comunicación asincrónica, el desacoplamiento del sistema, la reducción de picos y el llenado de valles, y la notificación de mensajes. Con la evolución de la tecnología y la expansión de la escala empresarial, los desafíos relacionados con la seguridad se han vuelto cada vez más prominentes y el control de acceso a los sistemas de mensajería se ha vuelto particularmente importante. Sin embargo, la versión ACL 1.0 existente de RocketMQ ya no puede afrontar el desarrollo futuro. Por lo tanto, lanzamos la versión mejorada de RocketMQ ACL 2.0 para mejorar aún más la seguridad de los datos de RocketMQ. Este artículo presentará las nuevas características, principios de funcionamiento y configuraciones y prácticas relacionadas de RocketMQ ACL 2.0.

Fondo actualizado

Puntos débiles de ACL 1.0

El proceso de autenticación y autorización de RocketMQ ACL 1.0 se muestra en la figura anterior. Durante el uso, existen los siguientes puntos débiles:

Lista blanca de IP para evitar el control de acceso : en las prácticas de seguridad estándar, la lista blanca de IP se utiliza a menudo para restringir el acceso de los clientes a recursos solo desde IP o rangos de IP específicos. Sin embargo, en ACL 1.0, la lista blanca de IP se utiliza de forma anormal como un medio para eludir la verificación de autenticación, desviándose de la intención de seguridad de la práctica estándar. Esta desviación de diseño puede causar riesgos potenciales de seguridad, especialmente en escenarios de redes públicas donde varios clientes comparten la misma IP, lo que puede causar que las direcciones IP no autorizadas eviten las verificaciones de control de acceso normales a los datos del clúster.

Falta de control detallado de las API de administración : RocketMQ proporciona más de 130 API de administración y control, que admiten la configuración del clúster, la administración de metadatos de temas y grupos, así como operaciones como consulta de mensajes y restablecimiento de sitios. Estas operaciones implican el procesamiento de datos sensibles y afectan la estabilidad del sistema. Por lo tanto, resulta fundamental definir con precisión el alcance de las API y los datos accesibles en función de las diferentes funciones o responsabilidades de los usuarios. Sin embargo, ACL 1.0 solo admite 9 API, incluidos temas, metadatos de grupo y configuración de agente. Los atacantes pueden utilizar las API restantes para atacar el sistema y robar datos confidenciales. Además, implementar el control de acceso para tantas API de administración requiere mucho trabajo de codificación con el diseño existente y aumenta el riesgo de que se pasen por alto cosas cuando se agregan nuevas API.

Falta de control de acceso entre los componentes del clúster : la arquitectura RocketMQ cubre múltiples componentes clave, como NameServer, el nodo maestro-esclavo del Broker y el Proxy. Actualmente, falta el mecanismo clave de verificación de permisos para el acceso mutuo entre estos componentes. Por lo tanto, una vez que construye un nodo esclavo de Broker o un componente Proxy fuera del clúster, puede omitir el mecanismo de seguridad existente y acceder y obtener datos confidenciales en el clúster. Esto sin duda tendrá un gran impacto en la seguridad y la estabilidad de los datos del sistema. de las amenazas.

Características y principios

Nuevas funciones de ACL 2.0

RocketMQ ACL 2.0 resuelve los problemas de ACL 1.0 y también trae seis características nuevas importantes, como se muestra a continuación:

Definición fina de permisos de recursos API : ACL 2.0 define todos los recursos en el sistema RocketMQ, incluidos clústeres, espacios de nombres, temas y grupos de consumidores, para lograr un control de acceso independiente para todo tipo de recursos. Además, incluye todas las API en el alcance del control de permisos, cubriendo diversas operaciones, incluido el envío y recepción de mensajes, administración de clústeres, metadatos, etc., garantizando que se imponga un control de permisos estricto en cualquier operación de todos los recursos.

Múltiples modos de coincidencia para recursos autorizados : en un entorno de clúster con muchos recursos, autorizar cada recurso uno por uno traerá procesos de configuración complicados y cargas de administración. Por lo tanto, ACL 2.0 introduce tres modos de coincidencia flexibles: coincidencia exacta, coincidencia de prefijo y coincidencia de comodines. Estos modos permiten a los usuarios realizar rápidamente configuraciones unificadas basadas en las convenciones de nomenclatura y las características estructurales de los recursos, simplificar las operaciones de administración de permisos y mejorar la eficiencia de la configuración.

Admitir control de acceso entre componentes del clúster : dado que todos los tipos de recursos y operaciones API están incluidos en el sistema de control de acceso, las conexiones y el acceso entre componentes dentro del clúster también están sujetos a control de permisos, incluida la elección de líder entre el corredor maestro y el esclavo, y la replicación de datos. proceso, así como el acceso a datos desde Proxy a Broker, etc. Esto puede evitar eficazmente posibles problemas de fuga de datos y riesgos para la estabilidad del sistema, y ​​mejorar la seguridad y confiabilidad de todo el clúster.

Separación de autenticación de usuario y verificación de autoridad : al desacoplar los dos módulos clave de autenticación y autorización, el sistema puede proporcionar opciones flexibles como "solo autenticación sin autenticación" para adaptarse a las necesidades de diversos escenarios. Además, los dos componentes pueden evolucionar y desarrollarse de forma independiente, dando lugar a varios métodos de autenticación y métodos de autenticación avanzados.

Equilibrio entre seguridad y rendimiento : cuando ACL está habilitado, cada solicitud del cliente debe pasar por un proceso completo de autenticación y autorización. Esto garantiza la seguridad del sistema, pero también introduce una sobrecarga de rendimiento. En ACL 2.0, se proporcionan estrategias de autorización y autenticación sin estado y estrategias de autorización y autenticación con estado para cumplir con dos requisitos diferentes de seguridad y rendimiento: requisitos de seguridad extremos y seguridad controlable pero prioridad de rendimiento.

Mecanismo de complemento flexible y extensible : en el mercado actual, existen múltiples implementaciones de métodos de autenticación y los métodos de autorización también tienen requisitos de personalización para diferentes escenarios. Por lo tanto, ACL 2.0 ha diseñado un marco de complementos para definir y abstraer interfaces en diferentes niveles para respaldar la futura expansión de la autenticación y autorización y permitir a los usuarios personalizar e implementar las soluciones correspondientes de acuerdo con sus propias necesidades comerciales.

modelo de control de acceso

El control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC) son los dos métodos principales en el sistema de control de acceso. RocketMQ ACL 2.0 integra estos dos métodos para crear un sistema de control de acceso más flexible y potente.

RBAC es un modelo de control de acceso basado en roles que asigna permisos a través de roles. RocketMQ ACL 2.0 divide los roles de usuario en superusuarios (Super) y usuarios normales (Normal). Los superusuarios tienen el nivel más alto de permisos y pueden acceder a los recursos sin autorización, lo que simplifica la dependencia de los permisos durante la inicialización del clúster y la operación y el mantenimiento diarios. Los usuarios comunes deben recibir los permisos correspondientes antes de acceder a los recursos, lo cual es adecuado para el acceso a recursos bajo demanda en escenarios comerciales.

ABAC es un modelo de control de acceso basado en atributos que expresa políticas de control de acceso a través de atributos multidimensionales como usuarios, recursos, entornos, operaciones, etc. RocketMQ ACL 2.0 proporciona este mecanismo de control de acceso flexible para usuarios normales. Ayude a los administradores a implementar un control de acceso más refinado a los recursos según las necesidades comerciales, las responsabilidades del usuario y otros factores.

En el sistema de seguridad, la autenticación y la autorización desempeñan funciones diferentes respectivamente. RocetMQ ACL 2.0 separa la autenticación y la autorización en módulos. Esto asegura que ambos componentes cumplan con sus funciones y reduce la complejidad del sistema. Los servicios de autenticación se dedican a verificar la legitimidad de las identidades de los usuarios, mientras que los servicios de autorización se centran en gestionar los permisos de los usuarios y el control de acceso. Esta división no solo hace que el código sea más fácil de administrar, mantener y expandir, sino que también brinda a los usuarios flexibilidad de uso. Dependiendo de las necesidades, los usuarios pueden optar por habilitar los servicios de autenticación o autorización por separado, o pueden optar por habilitar ambos al mismo tiempo. Esto permite que RocketMQ ACL cumpla con la implementación rápida de escenarios simples y se adapte a estrictos requisitos de seguridad en entornos complejos.

Autenticación

La autenticación es un mecanismo de seguridad diseñado para verificar la autenticidad de la persona que inicia la solicitud de acceso. Se utiliza para garantizar que solo aquellos usuarios o entidades legítimos autenticados puedan acceder a recursos protegidos o realizar operaciones específicas. En pocas palabras, la autenticación consiste en responder a la pregunta "¿Quién es usted?" antes de acceder a un recurso o servicio.

La versión RocketMQ ACL 2.0 mantiene el mismo mecanismo de autenticación que ACL 1.0, es decir, el método de autenticación basado en AK/SK. Este método utiliza principalmente tecnología de cifrado simétrico para verificar la identidad del cliente, garantizando que la información de autenticación confidencial (como contraseñas) no se transmita en texto claro en la red, mejorando así la seguridad de autenticación general.

modelo de agente

Para mejorar el control de acceso y la gestión de permisos del sistema RocketMQ, ACL 2.0 ha realizado las siguientes mejoras y extensiones al modelo principal:

1. Abstracción del modelo de sujeto unificado: para realizar el control de acceso y la gestión de permisos de diferentes entidades, se diseña una interfaz de sujeto unificada para permitir que múltiples instancias en el sistema sirvan como sujetos para el acceso a recursos. Como uno de los sujetos que accede a los recursos, el usuario implementa la interfaz del sujeto de acuerdo con este modelo. Esto proporciona capacidades de expansión para la adaptación de permisos a nuevos tipos de entidades en el futuro.

2. Clasificación de roles y concesión de permisos:

  • Superusuario : para simplificar el proceso de gestión, al superusuario se le otorgan automáticamente todos los permisos sin necesidad de una configuración separada, lo que simplifica la inicialización del sistema y la gestión diaria de operación y mantenimiento.
  • Usuarios comunes : los permisos de los usuarios comunes requieren autorización explícita. ACL 2.0 proporciona herramientas de administración de permisos relevantes que pueden otorgar permisos apropiados a usuarios comunes según las políticas y los requisitos de seguridad de la organización.

3. Admite la gestión del estado del usuario: para hacer frente a posibles riesgos de seguridad, como la filtración de contraseñas de usuarios, ACL 2.0 proporciona funciones de habilitación y deshabilitación de usuarios. Cuando ocurre un incidente de seguridad, el estado del usuario se puede desactivar para detener rápidamente el sangrado, evitando así el acceso ilegal.

Proceso de certificación

Proceso del cliente:

  1. Al construir una solicitud RPC, el cliente verifica si el nombre de usuario y la contraseña están configurados. Si no están configurados, el cliente envía la solicitud directamente;
  2. Si está configurado, el algoritmo de cifrado preestablecido se utiliza para cifrar los parámetros de la solicitud y generar la firma digital correspondiente (Firma).
  3. Agregue el nombre de usuario y la firma a la solicitud y envíela al servidor para su autenticación.

Proceso del servidor:

  1. Después de recibir la solicitud, el servidor primero verifica si la autenticación está activada. Si no está activada, pasará sin verificación; si está activada, pasará al siguiente paso.
  2. El servidor analiza y ensambla los parámetros relacionados con la autenticación de la solicitud y obtiene información que incluye el nombre de usuario y la firma.
  3. Consulte información relacionada con el usuario en la base de datos local a través del nombre de usuario. Si el usuario no existe, el procesamiento se devolverá como Ninguno si el usuario existe, luego continúe con el siguiente paso.
  4. Obtenga la contraseña del usuario, utilice el mismo algoritmo de cifrado para cifrar la solicitud para generar una Firma y compárela con la Firma pasada por el cliente. Si las dos son consistentes, la autenticación es exitosa. Si son inconsistentes, la autenticación falla.

Autorización

Idea principal

La autorización es un mecanismo de seguridad diseñado para determinar si un solicitante de acceso tiene permiso para operar en un recurso específico. En pocas palabras, la autorización consiste en responder a la pregunta "quién realizó qué operaciones en qué recursos y en qué circunstancias" antes de acceder a los recursos.

Basado en el modelo "Control de acceso basado en atributos (ABAC)", RocketMQ ACL 2.0 cubre la siguiente serie de conceptos básicos. En la implementación del sistema, los siguientes conceptos se utilizarán como guía para completar el diseño y la implementación de todo el mecanismo de autorización y gestión de derechos.

modelo de permiso

El concepto central del modelo de control de acceso basado en atributos (ABAC), ACL 2.0 ha diseñado cuidadosamente el modelo de permiso. Los puntos clave son los siguientes:

Política de permisos compatibles con versiones anteriores : de forma predeterminada, ACL 2.0 solo coincide y verifica los permisos definidos por el usuario. Si no se encuentra ninguna coincidencia, se considera que no hay permiso para acceder al recurso. Sin embargo, considerando que en ACL 1.0, hay una configuración de permiso predeterminada, que permite la determinación predeterminada de "acceso sin permiso" y "acceso con permiso" para recursos no coincidentes. Por lo tanto, hemos implementado compatibilidad con la política de permisos predeterminada para garantizar una migración fluida de ACL 1.0 a ACL 2.0.

Modo de coincidencia de recursos flexible : en términos de tipos de recursos, ACL 2.0 admite clústeres, espacios de nombres, temas, grupos de consumidores y otros tipos, que se utilizan para controlar el acceso a diferentes tipos de recursos. En términos de nombres de recursos, se introducen tres modos de coincidencia exacta (LITERAL), coincidencia de prefijo (PREFIXED) y coincidencia de comodines (ANY) para facilitar a los usuarios establecer rápidamente reglas de acceso unificado basadas en las especificaciones de nombres y estructuras de los recursos y simplificar los permisos. . administrar.

Tipos de operaciones de recursos finos : en términos de interfaces de consumo y envío de mensajes, se definen como operaciones PUB y SUB respectivamente. En términos de interfaces de administración de recursos y clústeres, se definen cinco operaciones: CREAR, ACTUALIZAR, ELIMINAR, LISTAR y OBTENER. A través de este refinamiento de los tipos de operaciones, puede ayudar a los usuarios a simplificar la comprensión y configuración de las operaciones sin tener que preocuparse por definiciones de interfaz específicas en el nivel de operación de recursos.

Verificación sólida del entorno de acceso : En términos del entorno para solicitar acceso, ACL 2.0 agrega verificación de la fuente IP de la solicitud del cliente. Esta verificación se controla a nivel de cada recurso y puede controlar con precisión cada recurso. La fuente de IP puede ser una dirección IP específica o un segmento de IP para cumplir con el control de acceso de IP en diferentes granularidades y agregar una sólida línea de defensa a la seguridad del sistema.

Proceso de autorización

Proceso del cliente:

  1. Cuando el cliente construye una solicitud RPC, construye los parámetros de entrada de la interfaz para esta llamada y la interfaz corresponde a la definición de operación detrás de los permisos.
  2. El cliente establece la información de recursos para esta visita en los parámetros de entrada de la interfaz y luego pasa parámetros como usuario y recurso al servidor.

Proceso del servidor:

  1. Después de recibir la solicitud, el servidor primero verifica si la autorización está activada. Si no está activada, pasa sin verificación; si está activada, pasa al siguiente paso.
  2. El servidor analiza y ensambla los parámetros relacionados con la autorización en la solicitud. Estos datos incluyen información del usuario, recursos accedidos, operaciones realizadas y el entorno solicitado.
  3. Consulte información relacionada con el usuario en el almacenamiento de datos local a través del nombre de usuario. Si el usuario no existe, se devolverá un error si el usuario existe, vaya al siguiente paso.
  4. Determine si el usuario actual es un superusuario. Si es un superusuario, la solicitud se pasará directamente sin verificación de autorización. Si es un usuario normal, vaya al siguiente paso para una verificación de autorización detallada.
  5. Obtenga la lista de políticas de autorización relevantes según el nombre de usuario, haga coincidir los recursos, las operaciones y el entorno solicitados esta vez y ordénelos según su prioridad.
  6. Las decisiones se toman en función de la política de autorización con la mayor prioridad. Si la política de autorización permite la operación, se devolverá el éxito de la autorización. Si se deniega la operación, se devolverá un error de no permiso.

Análisis de parámetros de autorización.

En ACL 2.0, el análisis de los parámetros relacionados con la autorización (incluidos recursos, operaciones, etc.) se optimiza según el tipo de operación y la frecuencia de solicitud.

  1. Análisis codificado

Para interfaces como el envío y consumo de mensajes, los parámetros son relativamente complejos y la frecuencia de solicitud es relativamente alta. Teniendo en cuenta la conveniencia y los requisitos de rendimiento del análisis, se utiliza codificación rígida para el análisis.

  1. Análisis de anotaciones

Para una gran cantidad de interfaces de administración y control, la carga de trabajo de la codificación rígida es enorme, la frecuencia de llamadas a estas interfaces es baja y los requisitos de rendimiento no son altos. Por lo tanto, se utilizan anotaciones para el análisis para mejorar la eficiencia de la codificación.

Prioridad de la política de permisos

En términos de coincidencia de políticas de permisos, debido a que admite el modo de coincidencia difusa de recursos, el mismo recurso puede corresponder a múltiples políticas de permisos. Por lo tanto, se necesita un mecanismo de prioridad para determinar qué conjunto de políticas de permisos se utiliza en última instancia.

Supongamos que está configurada la siguiente política de autorización y que la situación coincidente de los recursos prioritarios anteriores es la siguiente:

Estrategia de autenticación y autorización.

Debido a consideraciones y compensaciones de seguridad y rendimiento, RocketMQ ACL 2.0 proporciona dos estrategias de autenticación y autorización: estrategia de autenticación y autorización sin estado (Stateless) y estrategia de autenticación y autorización con estado (Stateful).

Estrategia de autenticación y autorización sin estado (Stateless) : según esta estrategia, cada solicitud pasará por un proceso de autenticación y autorización independiente y no depende de ninguna sesión anterior ni de información de estado. Esta estricta política garantiza un mayor nivel de garantía de seguridad. Los cambios en los permisos se pueden reflejar en solicitudes posteriores en tiempo real y sin esperas. Sin embargo, esta estrategia puede causar una carga de rendimiento significativa en escenarios de alto rendimiento, como un mayor uso de la CPU del sistema y solicitudes que consumen mucho tiempo.

Estrategia de autorización y autenticación con estado (Stateful) : según esta estrategia, bajo la misma conexión de cliente, el mismo recurso y la misma operación, la primera solicitud estará completamente autenticada y autorizada, y las solicitudes posteriores no se autenticarán ni autorizarán repetidamente. Este método puede reducir efectivamente el rendimiento y el tiempo de solicitud, y es especialmente adecuado para escenarios con alto rendimiento. Sin embargo, esta estrategia puede comprometer la seguridad y es posible que los cambios en los permisos no surtan efecto en tiempo real.

Al elegir entre estas dos estrategias, es necesario sopesar los requisitos de seguridad y de rendimiento del sistema. Si el sistema tiene altos requisitos de seguridad y puede tolerar una cierta pérdida de rendimiento, entonces la estrategia de autorización y autenticación sin estado puede ser una mejor opción. Por el contrario, si el sistema necesita manejar una gran cantidad de solicitudes simultáneas y los requisitos de seguridad pueden relajarse hasta cierto punto, entonces una estrategia de autenticación y autorización con estado puede ser más adecuada. Durante la implementación real, también se deben tomar decisiones basadas en escenarios comerciales específicos y requisitos de seguridad.

Mecanismo enchufable

Para adaptarse al desarrollo continuo de métodos de autenticación en el futuro y satisfacer las necesidades personalizadas de los usuarios para escenarios específicos, RocketMQ ACL 2.0 proporciona flexibilidad y escalabilidad en múltiples aspectos.

Ampliación de las políticas de autenticación y autorización : de forma predeterminada, RocketMQ ACL 2.0 proporciona políticas de autenticación y autorización sin estado (Stateless) y políticas de autenticación y autorización con estado (Stateful) para cumplir con los requisitos de seguridad y rendimiento de la mayoría de los usuarios. Sin embargo, aún se pueden explorar mejores estrategias en el futuro para lograr un equilibrio entre seguridad y rendimiento.

Ampliación de los métodos de autenticación y autorización : actualmente, en términos de autenticación, hay muchas implementaciones maduras en el mercado. RocketMQ actualmente solo implementa una de ellas. Está reservado a través de capacidades de complemento, y se pueden introducir más fácilmente en el futuro. Mecanismo de autenticación. En términos de autorización, RocketMQ implementa un conjunto de métodos de autorización convencionales basados ​​en el modelo ABAC para adaptarse a una amplia gama de necesidades de los usuarios. Pero también proporciona capacidades de complemento para facilitar la adaptación de más soluciones que se ajusten al desarrollo futuro.

Orquestación de procesos de autenticación y autorización : basado en el patrón de diseño de la cadena de responsabilidad, RocketMQ ACL 2.0 organiza de manera flexible sus procesos de autenticación y autorización predeterminados. Los usuarios pueden ampliar o reescribir estos nodos de la cadena de responsabilidad para personalizar la lógica de autenticación y autorización para sus escenarios comerciales específicos.

Extensión del almacenamiento de usuarios y permisos : RocketMQ usa RocksDB de forma predeterminada para almacenar datos de usuarios y permisos localmente en el nodo Broker. Sin embargo, al implementar interfaces predefinidas, los usuarios pueden migrar fácilmente estos datos a cualquier servicio o sistema de almacenamiento de terceros, optimizando así su diseño arquitectónico y eficiencia operativa.

Registro de auditoría

Los registros de auditoría se utilizan para registrar y monitorear todas las operaciones de control de acceso relacionadas con la autenticación y autorización. A través del registro de actualización, podemos rastrear cada solicitud de acceso para garantizar la confiabilidad y seguridad del sistema. Al mismo tiempo, también ayuda a solucionar problemas, realizar actualizaciones seguras y cumplir con los requisitos de cumplimiento.

RocketMQ ACL 2.0 admite registros de auditoría relacionados con la autenticación y autorización. El formato es el siguiente:

Registro de autenticación

# 认证成功日志
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 认证失败日志
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

Registro de autorización

# 授权成功日志
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授权失败日志
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

Configuración y uso

Arquitectura de implementación

En términos de arquitectura de implementación, RocketMQ proporciona dos formas de implementación, a saber, arquitectura integrada de almacenamiento y computación y arquitectura separada de almacenamiento y computación.

Arquitectura integrada de almacenamiento y computación

En la arquitectura informática y de almacenamiento integrada de RocketMQ, el componente Broker asume responsabilidades tanto informáticas como de almacenamiento, proporciona servicios externos y recibe solicitudes de acceso de todos los clientes. Por lo tanto, el componente Broker juega un papel importante en la autenticación y autorización. Además, el componente Broker también es responsable del mantenimiento y almacenamiento de metadatos relacionados con la autenticación y autorización.

Arquitectura de separación de almacenamiento y cálculo.

En la arquitectura de separación de almacenamiento y cálculo de RocketMQ, el almacenamiento lo maneja el componente Broker y el cálculo lo maneja el componente Proxy. Todas las solicitudes externas son atendidas por el Proxy. Por lo tanto, la autenticación y autorización de las solicitudes las realiza el componente Proxy. El corredor es responsable del almacenamiento de metadatos y proporciona los servicios de gestión y consulta de metadatos de autenticación y autorización necesarios para el componente Proxy.

Configuración del clúster

Configuración de autenticación

lista de parámetros

Si desea habilitar la función de autenticación en el lado del servidor, los parámetros relevantes y los casos de uso incluyen principalmente lo siguiente:

Configuración del corredor

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

Configuración de proxy

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

Configuración de autorización

lista de parámetros

Si desea habilitar la función de autorización en el lado del servidor, los parámetros relevantes y los casos de uso incluyen principalmente lo siguiente:

Configuración del corredor

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

Configuración de proxy

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

cómo utilizar

Uso de la línea de comando

Gestión de usuarios

Con respecto a la gestión de usuarios de ACL, las definiciones de interfaz relevantes y los casos de uso son los siguientes.

Definición de interfaz

Casos de uso

# 创建用户
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 创建用户，指定用户类型
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新用户
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 删除用户
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户详情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查询用户列表，带过滤条件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

Gestión de LCA

Con respecto a la gestión de la autorización ACL, las definiciones de interfaz relevantes y los casos de uso son los siguientes.

Definición de interfaz

Casos de uso

# 创建授权
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授权
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 删除授权
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 删除授权，指定资源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查询授权列表，带过滤条件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权详情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

Uso del cliente

Con respecto al uso de ACL, ACL 2.0 y ACL 1.0 se usan de la misma manera sin ninguna diferencia. Consulte el caso oficial para obtener más detalles.

envío de mensajes

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

Consumo de mensajes

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

Expansión y migración

Expansión

Si desea expandir un Broker mientras el clúster se está ejecutando, debe sincronizar todos los metadatos con el nuevo Broker. ACL 2.0 proporciona las interfaces de autorización de copia y usuario de copia correspondientes para admitir esta operación.

Definición de interfaz

Casos de uso

# 拷贝用户
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 拷贝授权
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

emigrar

Si ya está utilizando ACL 1.0 y desea migrar sin problemas a ACL 2.0, también se proporcionan las soluciones correspondientes. Solo necesita realizar las siguientes configuraciones.

Definición de configuración

Habilite la siguiente configuración en el archivo de configuración del Broker:

migrateAuthFromV1Enabled = true

Nota especial

Después de habilitar la configuración anterior, la ejecución se activará automáticamente durante el inicio del Broker. Esta función de migración escribirá la información de permisos del usuario en ACL 1.0 en la estructura de almacenamiento correspondiente de ACL 2.0.

El sistema agregará automáticamente los usuarios y permisos que aún no existen en ACL 2.0. La función de migración no sobrescribirá los usuarios ni los permisos existentes para evitar sobrescribir cualquier modificación que se haya realizado en ACL 2.0.

La lista blanca de IP en ACL 1.0 se utiliza para eludir las comprobaciones de control de acceso y no coincide con el comportamiento de ACL 2.0, por lo que no se migrará a ACL 2.0. Si ya ha utilizado las capacidades relevantes, complete la transformación antes de migrar.

Planificación y resumen

planificación

La planificación futura de RocketMQ ACL puede reflejarse en los dos aspectos siguientes:

  • Extensiones enriquecidas de autenticación y autorización : existen soluciones enriquecidas de autenticación y autorización en el mercado, y otros productos informáticos o de almacenamiento también adoptan varios métodos de implementación. Para mantenerse al día con las tendencias de desarrollo de la industria, RocketMQ ACL también se esforzará por innovar en el futuro para satisfacer las necesidades más amplias y cambiantes de los clientes. Al mismo tiempo, continuaremos profundizando la investigación y desarrollando mejores estrategias de autenticación y autorización para lograr el equilibrio ideal entre seguridad y rendimiento.
  • Operaciones visuales de permisos de usuario : actualmente, los usuarios y los permisos solo se pueden configurar en ACL a través de herramientas de línea de comandos, lo que no es lo suficientemente fácil de usar. En el futuro, esperamos proporcionar una interfaz de administración visual clara y fácil de usar en RocketMQ Dashboard, simplificando así el proceso de configuración y reduciendo el umbral técnico para la administración. Por otro lado, el Panel existente aún no ha integrado el sistema de control de acceso ACL, que también se incorporará en el futuro para brindar a los usuarios derechos de acceso para operar varios recursos en el Panel.

Resumir

RocketMQ ACL 2.0 ha experimentado nuevas actualizaciones en términos de diseño de modelo, escalabilidad, seguridad y rendimiento. Está diseñado para proporcionar a los usuarios un control de acceso refinado y al mismo tiempo simplificar el proceso de configuración de permisos. Todos son bienvenidos a probar la nueva versión y aplicarla en el entorno de producción. Esperamos los comentarios, discusiones y participación de todos en la comunidad para promover conjuntamente el crecimiento y el progreso tecnológico de la comunidad RocketMQ. Bienvenido a unirse al grupo DingTalk de desarrolladores de Apache RocketMQ China. (Número de grupo: 21982288)

Enlaces relacionados:

[1] Sitio web de aprendizaje de chino RocketMQ ttps://rocketmq-learning.com

[2] Cola de mensajes en la nube RocketMQ https://www.aliyun.com/product/rocketmq

Decidí renunciar al código abierto Hongmeng Wang Chenglu, el padre del código abierto Hongmeng: El código abierto Hongmeng es el único evento de software industrial de innovación arquitectónica en el campo del software básico en China: se lanza OGG 1.0, Huawei contribuye con todo el código fuente. Google Reader es asesinado por la "montaña de mierda de códigos" Fedora Linux 40 se lanza oficialmente Ex desarrollador de Microsoft: el rendimiento de Windows 11 es "ridículamente malo" Ma Huateng y Zhou Hongyi se dan la mano para "eliminar rencores" Compañías de juegos reconocidas han emitido nuevas regulaciones : los regalos de boda de los empleados no deben exceder los 100.000 yuanes Ubuntu 24.04 LTS lanzado oficialmente Pinduoduo fue sentenciado por competencia desleal Compensación de 5 millones de yuanes
{{o.nombre}}
{{m.nombre}}

Supongo que te gusta

Origin my.oschina.net/u/3874284/blog/11059297
Recomendado
Clasificación
Diario
Más
2025-02-01(0)
2025-01-31(0)
2025-01-30(0)
2025-01-29(0)
2025-01-28(0)
2025-01-27(0)
2025-01-26(0)
2025-01-25(0)
2025-01-24(0)
2025-01-23(0)

Code World

© 2018 codetd.com