Nova atualização do Apache RocketMQ ACL 2.0

[Antevisão da transmissão ao vivo] Os modelos grandes substituirão os programadores? "

Autor: Tu Zhong

introdução

Como um middleware de mensagens distribuídas popular, o RocketMQ é amplamente utilizado em vários sistemas e microsserviços distribuídos em grande escala. Ele desempenha papéis importantes na comunicação assíncrona, no desacoplamento do sistema, na redução de picos e no preenchimento de vales e na notificação de mensagens. Com a evolução da tecnologia e a expansão da escala dos negócios, os desafios relacionados com a segurança tornaram-se cada vez mais proeminentes e o controlo de acesso aos sistemas de mensagens tornou-se particularmente importante. No entanto, a versão ACL 1.0 existente do RocketMQ não é mais capaz de atender ao desenvolvimento futuro. Portanto, lançamos a versão atualizada do RocketMQ ACL 2.0 para melhorar ainda mais a segurança dos dados do RocketMQ. Este artigo apresentará os novos recursos, princípios de funcionamento e configurações e práticas relacionadas do RocketMQ ACL 2.0.

Plano de fundo atualizado

Pontos problemáticos do ACL 1.0

O processo de autenticação e autorização do RocketMQ ACL 1.0 é mostrado na figura acima. Durante o uso, existem os seguintes pontos problemáticos:

Lista de permissões de IP para ignorar o controle de acesso : Em práticas de segurança padrão, a lista de permissões de IP é frequentemente usada para restringir o acesso de clientes a recursos apenas de IPs ou intervalos de IP específicos. No entanto, na ACL 1.0, a lista branca de IP é usada de forma anormal como um meio de contornar a verificação de autenticação, desviando-se da intenção de segurança da prática padrão. Esse desvio de design pode causar riscos potenciais à segurança, especialmente em cenários de rede pública onde vários clientes compartilham o mesmo IP, o que pode fazer com que endereços IP não autorizados ignorem as verificações normais de controle de acesso aos dados do cluster.

Falta de controle refinado de APIs de gerenciamento : RocketMQ fornece mais de 130 APIs de gerenciamento e controle, suportando configuração de cluster, gerenciamento de metadados de tópico e grupo, bem como operações como consulta de mensagens e redefinição de site. Estas operações envolvem o processamento de dados sensíveis e afetam a estabilidade do sistema. Portanto, torna-se fundamental definir com precisão o escopo de APIs e dados acessíveis com base nas diferentes funções ou responsabilidades do usuário. No entanto, o ACL 1.0 oferece suporte apenas a 9 APIs, incluindo tópico, metadados de grupo e configuração do corretor. As APIs restantes podem ser usadas por invasores para atacar o sistema e roubar dados confidenciais. Além disso, implementar o controle de acesso para tantas APIs de gerenciamento exige muito trabalho de codificação com o design existente e aumenta o risco de coisas serem perdidas quando novas APIs são adicionadas.

Falta de controle de acesso entre os componentes do cluster : a arquitetura RocketMQ cobre vários componentes principais, como NameServer, nó mestre-escravo do Broker e Proxy. Atualmente, falta o mecanismo de verificação de permissão de chave para acesso mútuo entre esses componentes. Portanto, depois de construir um nó escravo do Broker ou um componente Proxy fora do cluster, você pode ignorar o mecanismo de segurança existente e acessar e obter dados confidenciais no cluster. Isso sem dúvida terá um enorme impacto na segurança dos dados do sistema e na estabilidade. das ameaças do aglomerado.

Características e princípios

Novos recursos do ACL 2.0

RocketMQ ACL 2.0 resolve os problemas do ACL 1.0 e também traz seis novos recursos importantes, como segue:

Definição de permissão de recurso de API fina : ACL 2.0 define todos os recursos no sistema RocketMQ, incluindo clusters, namespaces, tópicos e grupos de consumidores, para obter controle de acesso independente para todos os tipos de recursos. Além disso, traz todas as APIs para o escopo do controle de permissão, abrangendo diversas operações, incluindo envio e recebimento de mensagens, gerenciamento de cluster, metadados, etc., garantindo que um controle rigoroso de permissão seja imposto a qualquer operação de todos os recursos.

Vários modos de correspondência para recursos autorizados : Em um ambiente de cluster com muitos recursos, autorizar cada recurso um por um trará processos de configuração complicados e encargos de gerenciamento. Portanto, o ACL 2.0 introduz três modos de correspondência flexíveis: correspondência exata, correspondência de prefixo e correspondência curinga. Esses modos permitem que os usuários façam configurações unificadas rapidamente com base nas convenções de nomenclatura e características estruturais dos recursos, simplifiquem as operações de gerenciamento de permissões e melhorem a eficiência da configuração.

Suporte ao controle de acesso entre componentes do cluster : como todos os tipos de recursos e operações de API estão incluídos no sistema de controle de acesso, as conexões e o acesso entre os componentes do cluster também estão sujeitos ao controle de permissão, incluindo a eleição do Líder entre o Broker mestre e o escravo e a replicação de dados. processo, bem como acesso a dados do Proxy ao Broker, etc. Isso pode efetivamente evitar possíveis problemas de vazamento de dados e riscos à estabilidade do sistema e aumentar a segurança e a confiabilidade de todo o cluster.

Separação de autenticação de usuário e verificação de autoridade : Ao desacoplar os dois módulos principais de autenticação e autorização, o sistema pode fornecer opções flexíveis como “somente autenticação sem autenticação” para se adaptar às necessidades de vários cenários. Além disso, os dois componentes podem evoluir e desenvolver-se de forma independente, dando origem a vários métodos de autenticação e métodos de autenticação avançados.

Equilíbrio entre segurança e desempenho : Quando a ACL está habilitada, cada solicitação do cliente deve passar por um processo completo de autenticação e autorização. Isso garante a segurança do sistema, mas também introduz sobrecarga de desempenho. No ACL 2.0, estratégias de autenticação e autorização sem estado e estratégias de autenticação e autorização com estado são fornecidas para atender a dois requisitos diferentes de segurança e desempenho: requisitos de segurança extremos e segurança controlável, mas com prioridade de desempenho.

Mecanismo de plug-in flexível e extensível : No mercado atual, existem múltiplas implementações de métodos de autenticação, e os métodos de autorização também possuem requisitos de personalização para diferentes cenários. Portanto, o ACL 2.0 projetou uma estrutura de plug-in para definir e abstrair interfaces em diferentes níveis para suportar futuras expansões de autenticação e autorização e permitir que os usuários personalizem e implementem soluções correspondentes de acordo com suas próprias necessidades de negócios.

modelo de controle de acesso

O controle de acesso baseado em funções (RBAC) e o controle de acesso baseado em atributos (ABAC) são os dois métodos principais no sistema de controle de acesso. RocketMQ ACL 2.0 integra esses dois métodos para criar um sistema de controle de acesso mais flexível e poderoso.

RBAC é um modelo de controle de acesso baseado em funções que aloca permissões por meio de funções. RocketMQ ACL 2.0 divide as funções de usuário em superusuários (Super) e usuários normais (Superusuários têm o mais alto nível de permissão e podem acessar recursos sem autorização, o que simplifica a dependência de permissão durante a inicialização do cluster e questões diárias de operação e manutenção. Os usuários comuns precisam receber permissões correspondentes antes de acessar os recursos, o que é adequado para acesso sob demanda aos recursos em cenários de negócios.

ABAC é um modelo de controle de acesso baseado em atributos que expressa políticas de controle de acesso por meio de atributos multidimensionais, como usuários, recursos, ambientes, operações, etc. RocketMQ ACL 2.0 fornece esse mecanismo flexível de controle de acesso para usuários comuns. Ajude os administradores a implementar um controle de acesso mais refinado aos recursos com base nas necessidades de negócios, responsabilidades do usuário e outros fatores.

No sistema de segurança, a autenticação e a autorização desempenham funções diferentes, respectivamente. Isto garante que ambos os componentes cumpram as suas funções e reduz a complexidade do sistema. Os serviços de autenticação são dedicados a verificar a legitimidade das identidades dos usuários, enquanto os serviços de autorização se concentram no gerenciamento de permissões de usuários e no controle de acesso. Essa divisão não apenas torna o código mais fácil de gerenciar, manter e expandir, mas também oferece flexibilidade de uso aos usuários. Dependendo das necessidades, os usuários podem optar por habilitar os serviços de autenticação ou autorização separadamente ou podem optar por habilitar ambos ao mesmo tempo. Isso permite que o RocketMQ ACL atenda à implantação rápida de cenários simples e se adapte a requisitos rígidos de segurança em ambientes complexos.

Autenticação

A autenticação é um mecanismo de segurança projetado para verificar a autenticidade da pessoa que inicia a solicitação de acesso. É usado para garantir que apenas os usuários ou entidades legítimas e autenticadas possam acessar recursos protegidos ou realizar operações específicas. Simplificando, a autenticação responde à pergunta “Quem é você?” antes que um recurso ou serviço seja acessado.

A versão RocketMQ ACL 2.0 mantém o mesmo mecanismo de autenticação do ACL 1.0, ou seja, método de autenticação baseado em AK/SK. Este método utiliza principalmente tecnologia de criptografia simétrica para verificar a identidade do cliente, garantindo que informações confidenciais de autenticação (como senhas) não sejam transmitidas em texto não criptografado na rede, melhorando assim a segurança geral da autenticação.

modelo de agente

Para melhorar o controle de acesso e gerenciamento de permissões do sistema RocketMQ, o ACL 2.0 fez as seguintes melhorias e extensões no modelo principal:

1. Abstração do modelo de assunto unificado: Para realizar o controle de acesso e gerenciamento de permissões de diferentes entidades, uma interface de assunto unificada é projetada para permitir que múltiplas instâncias no sistema sirvam como sujeitos para acesso a recursos. Como um dos sujeitos que acessam os recursos, o usuário implementa a interface do sujeito de acordo com este modelo. Isto fornece capacidades de expansão para adaptação de permissão a novos tipos de entidades no futuro.

2. Classificação de funções e concessão de permissão:

Superusuário : Para simplificar o processo de gerenciamento, o superusuário recebe automaticamente todas as permissões sem a necessidade de configuração separada, simplificando assim a inicialização do sistema e o gerenciamento diário da operação e manutenção.
Usuários comuns : as permissões de usuários comuns requerem autorização explícita. ACL 2.0 fornece ferramentas relevantes de gerenciamento de permissões que podem conceder permissões apropriadas a usuários comuns com base nas políticas e requisitos de segurança da organização.

3. Suporte ao gerenciamento de status do usuário: Para lidar com possíveis riscos de segurança, como vazamento de senha do usuário, o ACL 2.0 fornece funções de ativação e desativação do usuário. Quando ocorre um incidente de segurança, o status do usuário pode ser desativado para estancar rapidamente o sangramento, evitando assim o acesso ilegal.

Processo de certificação

Processo do cliente:

Ao construir uma solicitação RPC, o cliente verifica se o nome de usuário e a senha estão configurados, o cliente envia a solicitação diretamente;
Se configurado, o algoritmo de criptografia predefinido é utilizado para criptografar os parâmetros da solicitação e gerar a assinatura digital correspondente (Assinatura).
Anexe o nome de usuário e a assinatura à solicitação e envie-a ao servidor para autenticação.

Processo do servidor:

Após receber a solicitação, o servidor primeiro verifica se a autenticação está habilitada. Se não estiver habilitada, passará sem verificação, se estiver habilitada, irá para a próxima etapa.
O servidor analisa e monta os parâmetros relacionados à autenticação da solicitação e obtém informações incluindo nome de usuário e assinatura.
Consultar informações relacionadas ao usuário no banco de dados local através do nome do usuário. Se o usuário não existir, o processamento será retornado como Nenhum se o usuário existir, então prossiga para a próxima etapa.
Obtenha a senha do usuário, use o mesmo algoritmo de criptografia para criptografar a solicitação para gerar uma assinatura e compare-a com a assinatura passada pelo cliente. Se os dois forem consistentes, a autenticação será bem-sucedida.

Autorização

Ideia central

Autorização é um mecanismo de segurança projetado para determinar se um solicitante de acesso tem permissão para operar em um recurso específico. Simplificando, a autorização consiste em responder à pergunta “quem executou quais operações em quais recursos e em quais circunstâncias” antes de os recursos serem acessados.

Baseado no modelo "Controle de acesso baseado em atributos (ABAC)", RocketMQ ACL 2.0 cobre a seguinte série de conceitos básicos. Na implementação do sistema, os seguintes conceitos serão usados como orientação para completar o design e implementação de todo o mecanismo de gestão e autorização de direitos.

modelo de permissão

O conceito central do modelo de controle de acesso baseado em atributos (ABAC), ACL 2.0, projetou cuidadosamente o modelo de permissão. Os pontos principais são os seguintes:

Política de permissões compatíveis com versões anteriores : por padrão, o ACL 2.0 apenas corresponde e verifica as permissões definidas pelo usuário. Se nenhuma correspondência for encontrada, considera-se que não há permissão para acessar o recurso. Porém, considerando que no ACL 1.0, existe uma configuração de permissão padrão, que permite a determinação padrão de “sem acesso com permissão” e “com acesso com permissão” para recursos não correspondentes. Portanto, implementamos a compatibilidade com a política de permissão padrão para garantir uma migração perfeita do ACL 1.0 para o ACL 2.0.

Modo flexível de correspondência de recursos : Em termos de tipos de recursos, o ACL 2.0 oferece suporte a cluster, namespace, tópico, grupo de consumidores e outros tipos, que são usados para controlar o acesso a diferentes tipos de recursos. Em termos de nomes de recursos, três modos de correspondência exata (LITERAL), correspondência de prefixo (PREFIXED) e correspondência curinga (ANY) são introduzidos para facilitar aos usuários a definição rápida de regras de acesso unificadas com base nas especificações de nomenclatura e estruturas de recursos e simplificar as permissões. . gerenciar.

Tipos de operação de recursos finos : Em termos de interfaces de envio e consumo de mensagens, são definidos como operações PUB e SUB, respectivamente. Em termos de interfaces de gerenciamento de cluster e recursos, são definidas cinco operações: CREATE, UPDATE, DELETE, LIST e GET. Através deste refinamento dos tipos de operação, pode ajudar os utilizadores a simplificar a compreensão e configuração das operações sem terem de se preocupar com definições de interface específicas ao nível da operação de recursos.

Verificação sólida do ambiente de acesso : Em termos de ambiente de solicitação de acesso, o ACL 2.0 adiciona a verificação da origem do IP da solicitação do cliente. Essa verificação é controlada no nível de cada recurso e pode controlar com precisão cada recurso. A fonte IP pode ser um endereço IP específico ou um segmento IP para atender ao controle de acesso IP em diferentes granularidades e adicionar uma linha sólida de defesa à segurança do sistema.

Processo de autorização

Processo do cliente:

Quando o cliente constrói uma solicitação RPC, ele constrói os parâmetros de entrada da interface para essa chamada, e a interface corresponde à definição da operação por trás das permissões.
O cliente define as informações de recurso para esta visita nos parâmetros de entrada da interface e, em seguida, passa parâmetros como usuário e recurso para o servidor.

Processo do servidor:

Após receber a solicitação, o servidor primeiro verifica se a autorização está habilitada. Se não estiver habilitada, passa sem verificação, se estiver habilitada, passa para a próxima etapa.
O servidor analisa e monta os parâmetros relacionados à autorização na solicitação. Esses dados incluem informações do usuário, recursos acessados, operações executadas e o ambiente solicitado.
Consultar informações relacionadas ao usuário no armazenamento de dados local através do nome de usuário. Se o usuário não existir, um erro será retornado; se o usuário existir, vá para a próxima etapa.
Determine se o usuário atual é um superusuário. Se for um superusuário, a solicitação será passada diretamente sem verificação de autorização. Se for um usuário comum, vá para a próxima etapa para verificação detalhada de autorização.
Obtenha a lista de políticas de autorização relevantes com base no nome do usuário, combine os recursos, operações e ambiente solicitados desta vez e classifique-os de acordo com a prioridade.
As decisões são tomadas com base na política de autorização com maior prioridade. Se a política de autorização permitir a operação, o sucesso da autorização será retornado. Se a operação for negada, um erro sem permissão será retornado.

Análise de parâmetros de autorização

No ACL 2.0, a análise de parâmetros relacionados à autorização (incluindo recursos, operações, etc.) é otimizada com base no tipo de operação e na frequência de solicitação.

Análise codificada

Para interfaces como envio e consumo de mensagens, os parâmetros são relativamente complexos e a frequência de solicitação é relativamente alta. Levando em consideração os requisitos de conveniência e desempenho da análise, a codificação rígida é usada para análise.

Análise de anotação

Para um grande número de interfaces de gerenciamento e controle, a carga de trabalho de codificação rígida é enorme, a frequência de chamada dessas interfaces é baixa e os requisitos de desempenho não são altos. Portanto, anotações são usadas para análise para melhorar a eficiência da codificação.

Prioridade da política de permissão

Em termos de correspondência de políticas de permissão, porque suporta o modo de correspondência de recursos difusos, o mesmo recurso pode corresponder a várias políticas de permissão. Portanto, é necessário um mecanismo de prioridade para determinar qual conjunto de políticas de permissão será usado em última instância.

Suponha que a seguinte política de autorização esteja configurada e que a situação de correspondência dos recursos prioritários acima seja a seguinte:

Estratégia de autenticação e autorização

Devido a compensações e considerações de segurança e desempenho, o RocketMQ ACL 2.0 fornece duas estratégias para autenticação e autorização: estratégia de autenticação e autorização sem estado (Stateless) e estratégia de autenticação e autorização com estado (Stateful).

Estratégia de autenticação e autorização sem estado (Stateless) : Nesta estratégia, cada solicitação passará por um processo independente de autenticação e autorização e não depende de nenhuma sessão anterior e informações de estado. Esta política rigorosa garante um nível mais elevado de garantia de segurança. As alterações nas permissões podem ser refletidas em solicitações subsequentes de maneira mais em tempo real, sem qualquer espera. No entanto, esta estratégia pode causar uma carga significativa de desempenho em cenários de alto rendimento, como aumento do uso da CPU do sistema e solicitação demorada.

Estratégia de autenticação e autorização com estado (Stateful) : Sob esta estratégia, sob a mesma conexão de cliente, o mesmo recurso e a mesma operação, a primeira solicitação será totalmente autenticada e autorizada, e as solicitações subsequentes não serão autenticadas e autorizadas repetidamente. Este método pode efetivamente reduzir o desempenho e o tempo de solicitação e é especialmente adequado para cenários com alto rendimento. No entanto, esta estratégia pode introduzir compromissos de segurança e as alterações nas permissões podem não ter efeito em tempo real.

Ao escolher entre essas duas estratégias, os requisitos de segurança e de desempenho do sistema precisam ser ponderados. Se o sistema tiver altos requisitos de segurança e puder tolerar uma certa perda de desempenho, a estratégia de autenticação e autorização sem estado pode ser uma escolha melhor. Pelo contrário, se o sistema precisar lidar com um grande número de solicitações simultâneas e os requisitos de segurança puderem ser relaxados até certo ponto, então uma estratégia de autenticação e autorização com estado pode ser mais adequada. Durante a implantação real, as decisões também devem ser tomadas com base em cenários de negócios e requisitos de segurança específicos.

Mecanismo de plug-in

Para se adaptar ao desenvolvimento contínuo de métodos de autenticação no futuro e atender às necessidades personalizadas dos usuários para cenários específicos, o RocketMQ ACL 2.0 oferece flexibilidade e escalabilidade em vários aspectos.

Extensão das políticas de autenticação e autorização : Por padrão, o RocketMQ ACL 2.0 fornece políticas de autenticação e autorização sem estado (Stateless) e políticas de autenticação e autorização com estado (Stateful) para atender aos requisitos de segurança e desempenho da maioria dos usuários. No entanto, melhores estratégias ainda podem ser exploradas no futuro para encontrar um equilíbrio entre segurança e desempenho.

Expansão dos métodos de autenticação e autorização : Atualmente, em termos de autenticação, existem muitas implementações maduras no mercado. Atualmente, o RocketMQ implementa apenas um deles. É reservado por meio de recursos de plug-in e mais podem ser facilmente introduzidos no futuro. Mecanismo de autenticação. Em termos de autorização, RocketMQ implementa um conjunto de métodos de autorização convencionais baseados no modelo ABAC para se adaptar a uma ampla gama de necessidades do usuário. Mas também fornece recursos de plug-in para facilitar a adaptação de mais soluções que se ajustem ao desenvolvimento futuro.

Orquestração de processos de autenticação e autorização : com base no padrão de design da cadeia de responsabilidade, o RocketMQ ACL 2.0 orquestra com flexibilidade seus processos padrão de autenticação e autorização. Os usuários podem estender ou reescrever esses nós da cadeia de responsabilidade para personalizar a lógica de autenticação e autorização para seus cenários de negócios específicos.

Extensão de armazenamento de usuários e permissões : RocketMQ usa RocksDB por padrão para armazenar dados de usuários e permissões localmente no nó do Broker. No entanto, ao implementar interfaces predefinidas, os usuários podem migrar facilmente esses dados para qualquer serviço ou sistema de armazenamento de terceiros, otimizando assim seu projeto arquitetônico e eficiência operacional.

Registro de auditoria

Os logs de auditoria são usados para registrar e monitorar todas as operações de controle de acesso relacionadas à autenticação e autorização. Por meio do log de atualização, podemos rastrear todas as solicitações de acesso para garantir a confiabilidade e segurança do sistema. Ao mesmo tempo, também ajuda a solucionar problemas, realizar atualizações seguras e atender aos requisitos de conformidade.

RocketMQ ACL 2.0 suporta logs de auditoria relacionados à autenticação e autorização. O formato é o seguinte:

Registro de autenticação

# 认证成功日志
[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 autorização

# 授权成功日志
[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.

Configuração e uso

Arquitetura de implantação

Em termos de arquitetura de implantação, RocketMQ oferece duas formas de implantação, ou seja, arquitetura integrada de armazenamento e computação e arquitetura separada de armazenamento e computação.

Arquitetura integrada de armazenamento e computação

Na arquitetura integrada de armazenamento e computação RocketMQ, o componente Broker assume responsabilidades de computação e armazenamento, fornece serviços externos e recebe solicitações de acesso de todos os clientes. Portanto, o componente Broker desempenha um papel importante na autenticação e autorização. Além disso, o componente Broker também é responsável pela manutenção e armazenamento dos metadados relacionados à autenticação e autorização.

Arquitetura de separação de armazenamento e cálculo

Na arquitetura de armazenamento e separação de cálculo do RocketMQ, o armazenamento é feito pelo componente Broker e o cálculo é feito pelo componente Proxy. Todas as solicitações externas são atendidas pelo Proxy. Portanto, a autenticação e autorização das solicitações são realizadas pelo componente Proxy. O Broker é responsável pelo armazenamento de metadados e fornece serviços de gerenciamento e consulta de metadados de autenticação e autorização necessários para o componente Proxy.

Configuração de cluster

Configuração de autenticação

lista de parâmetros

Se você deseja habilitar a função de autenticação no lado do servidor, os parâmetros e casos de uso relevantes incluem principalmente o seguinte:

Configuração do corretor

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

Configuração de proxy

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

Configuração de autorização

lista de parâmetros

Se você deseja habilitar a função de autorização no lado do servidor, os parâmetros e casos de uso relevantes incluem principalmente o seguinte:

Configuração do corretor

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

Configuração de proxy

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

Como usar

Uso de linha de comando

Gerenciamento de usuários

Com relação ao gerenciamento de usuários ACL, as definições de interface e casos de uso relevantes são os seguintes.

Definição de interface

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

Gerenciamento de ACL

Com relação ao gerenciamento da autorização ACL, as definições de interface e casos de uso relevantes são os seguintes.

Definição de interface

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 do cliente

Em relação ao uso do ACL, o ACL 2.0 e o ACL 1.0 são usados da mesma forma, sem qualquer diferença. Consulte o caso oficial para obter detalhes.

envio de mensagem

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 mensagens

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();

Expansão e migração

Expansão

Se desejar expandir um Broker enquanto o cluster estiver em execução, será necessário sincronizar todos os metadados com o novo Broker. O ACL 2.0 fornece interfaces de usuário de cópia e de autorização de cópia correspondentes para suportar esta operação.

Definição de interface

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

migrar

Se você já estiver usando o ACL 1.0 e quiser migrar perfeitamente para o ACL 2.0, as soluções correspondentes também serão fornecidas. Você só precisará fazer as configurações a seguir.

Definição de configuração

Habilite a seguinte configuração no arquivo de configuração do Broker:

migrateAuthFromV1Enabled = true

Nota especial

Após habilitar a configuração acima, a execução será acionada automaticamente durante a inicialização do Broker. Esta função de migração gravará as informações de permissão do usuário no ACL 1.0 na estrutura de armazenamento correspondente do ACL 2.0.

Usuários e permissões que ainda não existem no ACL 2.0 serão adicionados automaticamente pelo sistema. A função de migração não substituirá usuários e permissões existentes para evitar a substituição de quaisquer modificações feitas no ACL 2.0.

A lista branca de IP no ACL 1.0 é usada para ignorar verificações de controle de acesso e não corresponde ao comportamento do ACL 2.0, portanto, não será migrada para o ACL 2.0. Se você já usou os recursos relevantes, conclua a transformação antes de migrar.

Planejamento e Resumo

planejamento

O planejamento futuro do RocketMQ ACL pode ser refletido nos dois aspectos a seguir:

Extensões ricas de autenticação e autorização : Existem soluções ricas de autenticação e autorização no mercado, e outros produtos de armazenamento ou computação também adotam vários métodos de implementação. Para acompanhar as tendências de desenvolvimento da indústria, o RocketMQ ACL também se esforçará para inovar no futuro para atender às necessidades mais amplas e em constante mudança dos clientes. Ao mesmo tempo, continuaremos a aprofundar a investigação e a desenvolver melhores estratégias de autenticação e autorização para alcançar o equilíbrio ideal entre segurança e desempenho.
Operações visuais de permissão de usuário : atualmente, usuários e permissões só podem ser configurados no ACL por meio de ferramentas de linha de comando, o que não é suficientemente amigável. No futuro, esperamos fornecer uma interface de gerenciamento visual clara e fácil de usar no RocketMQ Dashboard, simplificando assim o processo de configuração e reduzindo o limite técnico para gerenciamento. Por outro lado, o Dashboard existente ainda não integrou o sistema de controle de acesso ACL, que também será incorporado no futuro para fornecer aos usuários direitos de acesso para operar diversos recursos no Dashboard.

Resumir

RocketMQ ACL 2.0 passou por novas atualizações em termos de design de modelo, escalabilidade, segurança e desempenho. Ele foi projetado para fornecer aos usuários controle de acesso refinado e, ao mesmo tempo, simplificar o processo de configuração de permissões. Todos são bem-vindos para experimentar a nova versão e aplicá-la no ambiente de produção. Esperamos o feedback, a discussão e a participação de todos na comunidade para promover conjuntamente o crescimento e o progresso tecnológico da comunidade RocketMQ. Bem-vindo a ingressar no Grupo DingTalk de desenvolvedores Apache RocketMQ China. (Número do grupo: 21982288)

Links Relacionados:

[1] Site de aprendizado chinês RocketMQ ttps://rocketmq-learning.com

[2] Fila de mensagens na nuvem RocketMQ https://www.aliyun.com/product/rocketmq