Nouvelle mise à niveau Apache RocketMQ ACL 2.0

[Aperçu de diffusion en direct] Les grands modèles remplaceront-ils les programmeurs ? "

Auteur : Tu Zhong

introduction

En tant que middleware de messagerie distribuée populaire, RocketMQ est largement utilisé dans divers systèmes et microservices distribués à grande échelle. Il joue un rôle important dans la communication asynchrone, le découplage du système, l'écrêtage des pics et le remplissage des vallées, ainsi que la notification des messages. Avec l'évolution de la technologie et l'expansion de l'entreprise, les défis liés à la sécurité sont devenus de plus en plus importants, et le contrôle d'accès aux systèmes de messagerie est devenu particulièrement important. Cependant, la version ACL 1.0 existante de RocketMQ n'est plus en mesure de répondre aux développements futurs. Par conséquent, nous avons lancé la version mise à niveau de RocketMQ ACL 2.0 pour améliorer encore la sécurité des données RocketMQ. Cet article présentera les nouvelles fonctionnalités, les principes de fonctionnement ainsi que les configurations et pratiques associées de RocketMQ ACL 2.0.

Arrière-plan amélioré

Points douloureux de l'ACL 1.0

Le processus d'authentification et d'autorisation de RocketMQ ACL 1.0 est illustré dans la figure ci-dessus. Lors de l'utilisation, il existe les problèmes suivants :

Liste blanche IP pour contourner le contrôle d'accès : dans les pratiques de sécurité standard, la liste blanche IP est souvent utilisée pour empêcher les clients d'accéder aux ressources uniquement à partir d'adresses IP ou de plages d'adresses IP spécifiques. Cependant, dans ACL 1.0, la liste blanche IP est anormalement utilisée comme moyen de contourner la vérification d'authentification, s'écartant ainsi de l'intention de sécurité des pratiques standard. Cet écart de conception peut entraîner des risques de sécurité potentiels, en particulier dans les scénarios de réseau public dans lesquels plusieurs clients partagent la même adresse IP, ce qui peut amener des adresses IP non autorisées à contourner les contrôles d'accès normaux sur les données du cluster.

Manque de contrôle précis des API de gestion : RocketMQ fournit plus de 130 API de gestion et de contrôle, prenant en charge la configuration du cluster, la gestion des métadonnées du sujet et du groupe, ainsi que des opérations telles que la requête de message et la réinitialisation du site. Ces opérations impliquent le traitement de données sensibles et affectent la stabilité du système. Il devient donc essentiel de définir avec précision la portée des API et des données accessibles en fonction des différents rôles ou responsabilités des utilisateurs. Cependant, ACL 1.0 ne prend en charge que 9 API, y compris la configuration du sujet, des métadonnées de groupe et du courtier. Les API restantes peuvent être utilisées par des attaquants pour attaquer le système et voler des données sensibles. De plus, la mise en œuvre du contrôle d'accès pour un si grand nombre d'API de gestion nécessite beaucoup de travail de codage avec la conception existante et augmente le risque de manquer des éléments lorsque de nouvelles API sont ajoutées.

Manque de contrôle d'accès entre les composants du cluster : l'architecture RocketMQ couvre plusieurs composants clés tels que NameServer, le nœud maître-esclave Broker et le proxy. Actuellement, le mécanisme de vérification des autorisations de clé est manquant pour l'accès mutuel entre ces composants. Par conséquent, une fois que vous avez créé un nœud esclave Broker ou un composant proxy en dehors du cluster, vous pouvez contourner le mécanisme de sécurité existant et accéder et obtenir des données sensibles dans le cluster. Cela aura sans aucun doute un impact énorme sur la sécurité des données du système et sur la stabilité. des menaces du cluster.

Caractéristiques et principes

Nouvelles fonctionnalités d'ACL 2.0

RocketMQ ACL 2.0 résout les problèmes d'ACL 1.0 et apporte également six nouvelles fonctionnalités majeures, comme suit :

Définition fine des autorisations de ressources API : ACL 2.0 définit toutes les ressources du système RocketMQ, y compris les clusters, les espaces de noms, les sujets et les groupes de consommateurs, pour obtenir un contrôle d'accès indépendant pour tous les types de ressources. De plus, il intègre toutes les API dans le champ d'application du contrôle des autorisations, couvrant diverses opérations, notamment l'envoi et la réception de messages, la gestion des clusters, les métadonnées, etc., garantissant qu'un contrôle strict des autorisations est imposé sur toute opération de toutes les ressources.

Plusieurs modes de correspondance pour les ressources autorisées : dans un environnement de cluster avec de nombreuses ressources, autoriser chaque ressource une par une entraînera des processus de configuration compliqués et des charges de gestion. Par conséquent, ACL 2.0 introduit trois modes de correspondance flexibles : correspondance exacte, correspondance de préfixe et correspondance par caractère générique. Ces modes permettent aux utilisateurs de définir rapidement des paramètres unifiés basés sur les conventions de dénomination et les caractéristiques structurelles des ressources, de simplifier les opérations de gestion des autorisations et d'améliorer l'efficacité de la configuration.

Prise en charge du contrôle d'accès entre les composants du cluster : étant donné que tous les types de ressources et opérations API sont inclus dans le système de contrôle d'accès, les connexions et l'accès entre les composants au sein du cluster sont également soumis au contrôle des autorisations, y compris l'élection du leader entre le courtier maître et l'esclave et la réplication des données. processus, ainsi que l'accès aux données du proxy au courtier, etc. Cela peut efficacement éviter les problèmes potentiels de fuite de données et les risques pour la stabilité du système, et améliorer la sécurité et la fiabilité de l'ensemble du cluster.

Séparation de l'authentification de l'utilisateur et de la vérification de l'autorité : En dissociant les deux modules clés d'authentification et d'autorisation, le système peut fournir des options flexibles telles que « uniquement authentification sans authentification » pour s'adapter aux besoins de divers scénarios. De plus, les deux composants peuvent évoluer et se développer indépendamment, donnant ainsi naissance à diverses méthodes d'authentification et méthodes d'authentification avancées.

Équilibre entre sécurité et performances : Lorsque l'ACL est activée, chaque requête du client doit passer par un processus complet d'authentification et d'autorisation. Cela garantit la sécurité du système, mais introduit également une surcharge de performances. Dans ACL 2.0, des stratégies d'authentification et d'autorisation sans état et des stratégies d'authentification et d'autorisation avec état sont fournies pour répondre à deux exigences de sécurité et de performances différentes : exigences de sécurité extrêmes et sécurité contrôlable mais priorité aux performances.

Mécanisme de plug-in flexible et extensible : sur le marché actuel, il existe plusieurs implémentations de méthodes d'authentification, et les méthodes d'autorisation ont également des exigences de personnalisation pour différents scénarios. Par conséquent, ACL 2.0 a conçu un cadre de plug-in pour définir et abstraire les interfaces à différents niveaux afin de prendre en charge l'expansion future de l'authentification et de l'autorisation et permettre aux utilisateurs de personnaliser et de mettre en œuvre les solutions correspondantes en fonction de leurs propres besoins professionnels.

modèle de contrôle d'accès

Le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC) sont les deux principales méthodes du système de contrôle d'accès. RocketMQ ACL 2.0 intègre ces deux méthodes pour créer un système de contrôle d'accès plus flexible et plus puissant.

RBAC est un modèle de contrôle d'accès basé sur les rôles qui attribue des autorisations via des rôles. RocketMQ ACL 2.0 divise les rôles d'utilisateur en super utilisateurs (Super) et utilisateurs normaux (Normal). Les super utilisateurs ont le niveau d'autorisations le plus élevé et peuvent accéder aux ressources sans autorisation, ce qui simplifie la dépendance aux autorisations lors de l'initialisation du cluster et des questions d'exploitation et de maintenance quotidiennes. Les utilisateurs ordinaires doivent disposer des autorisations correspondantes avant d'accéder aux ressources, ce qui convient à l'accès à la demande aux ressources dans les scénarios commerciaux.

ABAC est un modèle de contrôle d'accès basé sur les attributs qui exprime les politiques de contrôle d'accès à travers des attributs multidimensionnels tels que les utilisateurs, les ressources, les environnements, les opérations, etc. RocketMQ ACL 2.0 fournit ce mécanisme de contrôle d'accès flexible pour les utilisateurs ordinaires. Aidez les administrateurs à mettre en œuvre un contrôle d’accès plus raffiné aux ressources en fonction des besoins de l’entreprise, des responsabilités des utilisateurs et d’autres facteurs.

Dans le système de sécurité, l'authentification et l'autorisation jouent respectivement des rôles différents. RocetMQ ACL 2.0 sépare l'authentification et l'autorisation en modules. Cela garantit que les deux composants remplissent leurs fonctions et réduit la complexité du système. Les services d'authentification sont dédiés à vérifier la légitimité des identités des utilisateurs, tandis que les services d'autorisation se concentrent sur la gestion des autorisations des utilisateurs et du contrôle d'accès. Cette division rend non seulement le code plus facile à gérer, à maintenir et à développer, mais offre également aux utilisateurs une flexibilité d'utilisation. En fonction des besoins, les utilisateurs peuvent choisir d'activer les services d'authentification ou d'autorisation séparément, ou ils peuvent choisir d'activer les deux en même temps. Cela permet à RocketMQ ACL de répondre au déploiement rapide de scénarios simples et de s'adapter aux exigences de sécurité strictes dans des environnements complexes.

Authentification

L'authentification est un mécanisme de sécurité conçu pour vérifier l'authenticité de la personne qui initie la demande d'accès. Il est utilisé pour garantir que seuls les utilisateurs ou entités légitimes et authentifiés peuvent accéder aux ressources protégées ou effectuer des opérations spécifiques. En termes simples, l'authentification consiste à répondre à la question « Qui êtes-vous ? » avant d'accéder à une ressource ou à un service.

La version RocketMQ ACL 2.0 conserve le même mécanisme d'authentification que l'ACL 1.0, c'est-à-dire une méthode d'authentification basée sur AK/SK. Cette méthode utilise principalement une technologie de cryptage symétrique pour vérifier l'identité du client, garantissant que les informations d'authentification sensibles (telles que les mots de passe) ne seront pas transmises en texte clair sur le réseau, améliorant ainsi la sécurité globale de l'authentification.

modèle d'agent

Afin d'améliorer le contrôle d'accès et la gestion des autorisations du système RocketMQ, ACL 2.0 a apporté les améliorations et extensions suivantes au modèle principal :

1. Abstraction du modèle de sujet unifié : afin de réaliser le contrôle d'accès et la gestion des autorisations de différentes entités, une interface de sujet unifiée est conçue pour permettre à plusieurs instances du système de servir de sujets d'accès aux ressources. En tant que sujet accédant aux ressources, l'utilisateur implémente l'interface du sujet selon ce modèle. Cela fournit des capacités d’extension pour l’adaptation des autorisations à de nouveaux types d’entités à l’avenir.

2. Classification des rôles et octroi des autorisations :

Super utilisateur : Afin de simplifier le processus de gestion, le super utilisateur obtient automatiquement toutes les autorisations sans avoir besoin d'une configuration séparée, simplifiant ainsi l'initialisation du système et la gestion quotidienne de l'exploitation et de la maintenance.
Utilisateurs ordinaires : les autorisations des utilisateurs ordinaires nécessitent une autorisation explicite. ACL 2.0 fournit des outils de gestion des autorisations pertinents qui peuvent accorder les autorisations appropriées aux utilisateurs ordinaires en fonction des politiques et des exigences de sécurité de l'organisation.

3. Prise en charge de la gestion du statut des utilisateurs : afin de faire face aux risques de sécurité possibles, tels que la fuite du mot de passe utilisateur, ACL 2.0 fournit des fonctions d'activation et de désactivation des utilisateurs. Lorsqu'un incident de sécurité se produit, le statut de l'utilisateur peut être désactivé pour arrêter rapidement l'hémorragie, empêchant ainsi tout accès illégal.

Processus de certification

Processus client :

Lors de la construction d'une requête RPC, le client vérifie si le nom d'utilisateur et le mot de passe sont définis. S'ils ne sont pas configurés, le client envoie la requête directement ;
S'il est configuré, l'algorithme de cryptage prédéfini est utilisé pour crypter les paramètres de la demande et générer la signature numérique correspondante (Signature).
Ajoutez le nom d'utilisateur et la signature à la demande et envoyez-la au serveur pour authentification.

Processus serveur :

Après avoir reçu la demande, le serveur vérifie d'abord si l'authentification est activée. Si elle n'est pas activée, elle passera sans vérification. Si elle est activée, il passera à l'étape suivante.
Le serveur analyse et assemble les paramètres liés à la demande d'authentification et obtient des informations, notamment le nom d'utilisateur et la signature.
Recherchez les informations relatives à l'utilisateur dans la base de données locale via le nom d'utilisateur. Si l'utilisateur n'existe pas, le traitement sera renvoyé comme Aucun si l'utilisateur existe, puis passez à l'étape suivante.
Obtenez le mot de passe de l'utilisateur, utilisez le même algorithme de cryptage pour crypter la demande de génération d'une signature et comparez-le avec la signature transmise par le client. Si les deux sont cohérents, l'authentification réussit. Si elles sont incohérentes, l'authentification échoue.

Autorisation

Idée de base

L'autorisation est un mécanisme de sécurité conçu pour déterminer si un demandeur d'accès a l'autorisation d'opérer sur une ressource spécifique. En termes simples, l'autorisation consiste à répondre à la question « qui a effectué quelles opérations sur quelles ressources et dans quelles circonstances » avant d'accéder aux ressources.

Basé sur le modèle « Contrôle d'accès basé sur les attributs (ABAC) », RocketMQ ACL 2.0 couvre la série de concepts de base suivante. Lors de la mise en œuvre du système, les concepts suivants seront utilisés comme lignes directrices pour achever la conception et la mise en œuvre de l'ensemble du mécanisme de gestion des droits et d'autorisation.

modèle d'autorisation

Concept de base du modèle de contrôle d'accès basé sur les attributs (ABAC), ACL 2.0 a soigneusement conçu le modèle d'autorisation. Les points clés sont les suivants :

Politique d'autorisations rétrocompatibles : par défaut, ACL 2.0 correspond et vérifie uniquement les autorisations définies par l'utilisateur. Si aucune correspondance n'est trouvée, il est considéré qu'il n'y a aucune autorisation pour accéder à la ressource. Cependant, étant donné que dans ACL 1.0, il existe un paramètre d'autorisation par défaut, qui permet la détermination par défaut de « aucun accès autorisé » et « avec accès autorisé » pour les ressources sans correspondance. Par conséquent, nous avons implémenté la compatibilité avec la stratégie d'autorisation par défaut pour garantir une migration transparente d'ACL 1.0 vers ACL 2.0.

Mode de correspondance de ressources flexible : en termes de types de ressources, ACL 2.0 prend en charge les clusters, les espaces de noms, les sujets, les groupes de consommateurs et d'autres types, qui sont utilisés pour contrôler l'accès à différents types de ressources. En termes de noms de ressources, trois modes de correspondance exacte (LITERAL), de correspondance de préfixe (PREFIXED) et de correspondance de caractères génériques (ANY) sont introduits pour permettre aux utilisateurs de définir rapidement des règles d'accès unifiées basées sur les spécifications de dénomination et les structures des ressources et de simplifier les autorisations. . gérer.

Types d'opérations de ressources fines : En termes d'interfaces d'envoi de messages et de consommation, elles sont définies respectivement comme opérations PUB et SUB. En termes d'interfaces de gestion de cluster et de ressources, cinq opérations sont définies : CREATE, UPDATE, DELETE, LIST et GET. Grâce à cet affinement des types d'opérations, il peut aider les utilisateurs à simplifier la compréhension et la configuration des opérations sans avoir à se soucier des définitions d'interface spécifiques au niveau des opérations de ressources.

Vérification solide de l'environnement d'accès : Au niveau de l'environnement de demande d'accès, ACL 2.0 ajoute la vérification de la source IP de la demande du client. Cette vérification est contrôlée au niveau de chaque ressource et peut contrôler avec précision chaque ressource. La source IP peut être une adresse IP spécifique ou un segment IP pour répondre au contrôle d'accès IP à différentes granularités et ajouter une ligne de défense solide à la sécurité du système.

Processus d'autorisation

Processus client :

Lorsque le client construit une requête RPC, il construit les paramètres d'entrée d'interface pour cet appel, et l'interface correspond à la définition de l'opération derrière les autorisations.
Le client définit les informations sur les ressources pour cette visite dans les paramètres d'entrée de l'interface, puis transmet des paramètres tels que l'utilisateur et la ressource au serveur.

Processus serveur :

Après avoir reçu la demande, le serveur vérifie d'abord si l'autorisation est activée. S'il n'est pas activé, il passe sans vérification ; s'il est activé, il passe à l'étape suivante ;
Le serveur analyse et rassemble les paramètres liés à l'autorisation dans la demande. Ces données incluent les informations sur l'utilisateur, les ressources consultées, les opérations effectuées et l'environnement demandé.
Recherchez les informations relatives à l'utilisateur dans le stockage de données local via le nom d'utilisateur. Si l'utilisateur n'existe pas, une erreur sera renvoyée si l'utilisateur existe, passez à l'étape suivante.
Déterminez si l'utilisateur actuel est un super utilisateur. S'il s'agit d'un super utilisateur, la demande sera transmise directement sans vérification d'autorisation. S'il s'agit d'un utilisateur ordinaire, passez à l'étape suivante pour une vérification détaillée de l'autorisation.
Obtenez la liste des politiques d'autorisation pertinentes en fonction du nom d'utilisateur, faites correspondre les ressources, les opérations et l'environnement demandés cette fois-ci et triez-les en fonction de la priorité.
Les décisions sont prises en fonction de la stratégie d'autorisation ayant la priorité la plus élevée. Si la stratégie d'autorisation autorise l'opération, la réussite de l'autorisation sera renvoyée. Si l'opération est refusée, une erreur d'absence d'autorisation sera renvoyée.

Analyse des paramètres d'autorisation

Dans ACL 2.0, l'analyse des paramètres liés à l'autorisation (y compris les ressources, les opérations, etc.) est optimisée en fonction du type d'opération et de la fréquence des demandes.

Analyse codée en dur

Pour les interfaces telles que l'envoi et la consommation de messages, les paramètres sont relativement complexes et la fréquence des requêtes est relativement élevée. Compte tenu des exigences de commodité et de performances de l'analyse, le codage en dur est utilisé pour l'analyse.

Analyse des annotations

Pour un grand nombre d'interfaces de gestion et de contrôle, la charge de travail de codage en dur est énorme, la fréquence d'appel de ces interfaces est faible et les exigences de performances ne sont pas élevées. Par conséquent, les annotations sont utilisées pour l'analyse afin d'améliorer l'efficacité du codage.

Priorité de la politique d'autorisation

En termes de correspondance de stratégie d'autorisation, parce qu'elle prend en charge le mode de correspondance de ressources floue, la même ressource peut correspondre à plusieurs stratégies d'autorisation. Par conséquent, un mécanisme de priorité est nécessaire pour déterminer quel ensemble de politiques d’autorisation est finalement utilisé.

Supposons que la stratégie d'autorisation suivante soit configurée et que la situation de correspondance des ressources prioritaires ci-dessus soit la suivante :

Stratégie d'authentification et d'autorisation

En raison de compromis et de considérations en matière de sécurité et de performances, RocketMQ ACL 2.0 propose deux stratégies d'authentification et d'autorisation : une stratégie d'authentification et d'autorisation sans état (Stateless) et une stratégie d'authentification et d'autorisation avec état (Stateful).

Stratégie d'authentification et d'autorisation sans état (Stateless) : Dans le cadre de cette stratégie, chaque demande passera par un processus d'authentification et d'autorisation indépendant et ne repose sur aucune information de session et d'état précédente. Cette politique stricte garantit un niveau plus élevé d’assurance de sécurité. Les modifications apportées aux autorisations peuvent être reflétées dans les demandes ultérieures de manière plus en temps réel, sans aucune attente. Cependant, cette stratégie peut entraîner une charge importante en termes de performances dans les scénarios à haut débit, comme une utilisation accrue du processeur du système et une perte de temps pour les requêtes.

Stratégie d'authentification et d'autorisation avec état (Stateful) : Dans le cadre de cette stratégie, sous la même connexion client, la même ressource et la même opération, la première demande sera entièrement authentifiée et autorisée, et les demandes suivantes ne seront pas authentifiées et autorisées à plusieurs reprises. Cette méthode peut réduire efficacement les performances et le temps de requête, et est particulièrement adaptée aux scénarios à haut débit. Cependant, cette stratégie peut introduire des compromis en matière de sécurité et les modifications apportées aux autorisations peuvent ne pas prendre effet en temps réel.

Lors du choix entre ces deux stratégies, les exigences de sécurité et les exigences de performances du système doivent être pesées. Si le système a des exigences de sécurité élevées et peut tolérer une certaine perte de performances, la stratégie d'authentification et d'autorisation sans état peut alors s'avérer un meilleur choix. Au contraire, si le système doit traiter un grand nombre de requêtes simultanées et que les exigences de sécurité peuvent être assouplies dans une certaine mesure, alors une stratégie d’authentification et d’autorisation avec état peut être plus adaptée. Lors du déploiement réel, les décisions doivent également être prises en fonction de scénarios commerciaux spécifiques et d'exigences de sécurité.

Mécanisme de plug-in

Afin de s'adapter au développement continu des méthodes d'authentification à l'avenir et de répondre aux besoins personnalisés des utilisateurs pour des scénarios spécifiques, RocketMQ ACL 2.0 offre flexibilité et évolutivité sous plusieurs aspects.

Extension des politiques d'authentification et d'autorisation : Par défaut, RocketMQ ACL 2.0 fournit des politiques d'authentification et d'autorisation sans état (Stateless) et des politiques d'authentification et d'autorisation avec état (Stateful) pour répondre aux exigences de sécurité et de performances de la plupart des utilisateurs. Cependant, de meilleures stratégies peuvent encore être explorées à l’avenir pour trouver un équilibre entre sécurité et performances.

Extension des méthodes d'authentification et d'autorisation : Actuellement, en termes d'authentification, il existe de nombreuses implémentations matures sur le marché. RocketMQ n'en implémente actuellement qu'une seule, réservée via les capacités du plug-in, et d'autres peuvent être facilement introduites à l'avenir. Mécanisme d'authentification. En termes d'autorisation, RocketMQ implémente un ensemble de méthodes d'autorisation traditionnelles basées sur le modèle ABAC pour s'adapter à un large éventail de besoins des utilisateurs. Mais il fournit également des fonctionnalités de plug-in pour faciliter l'adaptation d'un plus grand nombre de solutions adaptées aux développements futurs.

Orchestration des processus d'authentification et d'autorisation : Basé sur le modèle de conception de chaîne de responsabilité, RocketMQ ACL 2.0 orchestre de manière flexible ses processus d'authentification et d'autorisation par défaut. Les utilisateurs peuvent étendre ou réécrire ces nœuds de chaîne de responsabilité pour personnaliser la logique d'authentification et d'autorisation pour leurs scénarios commerciaux spécifiques.

Extension du stockage des utilisateurs et des autorisations : RocketMQ utilise RocksDB par défaut pour stocker les données d'utilisateur et d'autorisation localement sur le nœud Broker. Cependant, en implémentant des interfaces prédéfinies, les utilisateurs peuvent facilement migrer ces données vers n'importe quel service ou système de stockage tiers, optimisant ainsi leur conception architecturale et leur efficacité opérationnelle.

Journal d'audit

Les journaux d'audit sont utilisés pour enregistrer et surveiller toutes les opérations de contrôle d'accès liées à l'authentification et à l'autorisation. Grâce au journal de mise à niveau, nous pouvons suivre chaque demande d'accès pour garantir la fiabilité et la sécurité du système. En même temps, cela aide également à résoudre les problèmes, à effectuer des mises à niveau sûres et à répondre aux exigences de conformité.

RocketMQ ACL 2.0 prend en charge les journaux d'audit liés à l'authentification et à l'autorisation. Le format est le suivant :

Journal d'authentification

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

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

Journal d'autorisation

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

Configuration et utilisation

Architecture de déploiement

En termes d'architecture de déploiement, RocketMQ propose deux formes de déploiement, à savoir une architecture intégrée de stockage et de calcul et une architecture séparée de stockage et de calcul.

Architecture intégrée de stockage et de calcul

Dans l'architecture informatique et de stockage intégrée de RocketMQ, le composant Broker assume à la fois les responsabilités informatiques et de stockage, fournit des services externes et reçoit les demandes d'accès de tous les clients. Par conséquent, le composant Broker joue un rôle important dans l’authentification et l’autorisation. De plus, le composant Broker est également responsable de la maintenance et du stockage des métadonnées liées à l'authentification et à l'autorisation.

Architecture de séparation de stockage et de calcul

Dans l'architecture de séparation de stockage et de calcul de RocketMQ, le stockage est géré par le composant Broker et le calcul est géré par le composant Proxy. Toutes les requêtes externes sont traitées par le proxy. Par conséquent, l'authentification et l'autorisation des requêtes sont assurées par le composant Proxy. Le courtier est responsable du stockage des métadonnées et fournit les services de requête et de gestion des métadonnées d’authentification et d’autorisation requis pour le composant proxy.

Configuration des clusters

Configuration de l'authentification

liste de paramètres

Si vous souhaitez activer la fonction d'authentification côté serveur, les paramètres et cas d'utilisation pertinents sont principalement les suivants :

Configuration du courtier

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

Configuration du proxy

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

Configuration des autorisations

liste de paramètres

Si vous souhaitez activer la fonction d'autorisation côté serveur, les paramètres et cas d'utilisation pertinents sont principalement les suivants :

Configuration du courtier

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

Configuration du proxy

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

comment utiliser

Utilisation de la ligne de commande

Gestion des utilisateurs

Concernant la gestion des utilisateurs ACL, les définitions d'interface et les cas d'utilisation pertinents sont les suivants.

Définition de l'interface

Cas d'utilisation

# 创建用户
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

Gestion des listes de contrôle d'accès

Concernant la gestion de l'autorisation ACL, les définitions d'interface et les cas d'utilisation pertinents sont les suivants.

Définition de l'interface

Cas d'utilisation

# 创建授权
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

Utilisation client

Concernant l'utilisation d'ACL, ACL 2.0 et ACL 1.0 sont utilisés de la même manière sans aucune différence. Veuillez vous référer au cas officiel pour plus de détails.

envoi de messages

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

Consommation des messages

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

Expansion et migration

Expansion

Si vous souhaitez développer un Broker pendant que le cluster est en cours d'exécution, vous devez synchroniser toutes les métadonnées avec le nouveau Broker. ACL 2.0 fournit les interfaces d'utilisateur de copie et d'autorisation de copie correspondantes pour prendre en charge cette opération.

Définition de l'interface

Cas d'utilisation

# 拷贝用户
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

émigrer

Si vous utilisez déjà ACL 1.0 et souhaitez migrer de manière transparente vers ACL 2.0, des solutions correspondantes sont également fournies. Il vous suffit d'effectuer les configurations suivantes.

Définition de la configuration

Activez la configuration suivante dans le fichier de configuration du Broker :

migrateAuthFromV1Enabled = true

Note spéciale

Après avoir activé la configuration ci-dessus, l'exécution sera automatiquement déclenchée lors du démarrage du Broker. Cette fonction de migration écrira les informations d'autorisation utilisateur dans ACL 1.0 dans la structure de stockage correspondante d'ACL 2.0.

Les utilisateurs et autorisations qui n'existent pas encore dans ACL 2.0 seront ajoutés automatiquement par le système. La fonction de migration n'écrasera pas les utilisateurs et les autorisations existants pour éviter d'écraser les modifications apportées dans ACL 2.0.

La liste blanche IP dans ACL 1.0 est utilisée pour contourner les contrôles d'accès et ne correspond pas au comportement d'ACL 2.0 ; elle ne sera donc pas migrée vers ACL 2.0. Si vous avez déjà utilisé les fonctionnalités pertinentes, veuillez terminer la transformation avant de migrer.

Planification et résumé

planification

La planification future de RocketMQ ACL peut se refléter dans les deux aspects suivants :

Extensions riches d'authentification et d'autorisation : Il existe des solutions riches d'authentification et d'autorisation sur le marché, et d'autres produits de stockage ou informatiques adoptent également diverses méthodes de mise en œuvre. Afin de suivre les tendances de développement du secteur, RocketMQ ACL s'efforcera également d'innover à l'avenir pour répondre aux besoins plus larges et changeants des clients. Dans le même temps, nous continuerons à approfondir la recherche et à développer de meilleures stratégies d’authentification et d’autorisation pour atteindre l’équilibre idéal entre sécurité et performances.
Opérations d'autorisation visuelle des utilisateurs : actuellement, les utilisateurs et les autorisations ne peuvent être configurés dans ACL que via des outils de ligne de commande, ce qui n'est pas assez convivial. À l'avenir, nous espérons fournir une interface de gestion visuelle claire et facile à utiliser sur RocketMQ Dashboard, simplifiant ainsi le processus de configuration et abaissant le seuil technique de gestion. D'autre part, le tableau de bord existant n'a pas encore intégré le système de contrôle d'accès ACL, qui sera également intégré à l'avenir pour fournir aux utilisateurs des droits d'accès pour exploiter diverses ressources du tableau de bord.

Résumer

RocketMQ ACL 2.0 a subi de toutes nouvelles mises à niveau en termes de conception de modèle, d'évolutivité, de sécurité et de performances. Il est conçu pour fournir aux utilisateurs un contrôle d'accès raffiné tout en simplifiant le processus de configuration des autorisations. Tout le monde est invité à essayer la nouvelle version et à l'appliquer dans l'environnement de production. Nous attendons avec impatience les commentaires, les discussions et la participation de chacun à la communauté pour promouvoir conjointement la croissance et le progrès technologique de la communauté RocketMQ. Bienvenue dans le groupe DingTalk des développeurs Apache RocketMQ Chine. (Numéro de groupe : 21982288)

Liens connexes:

[1] Site Web d'apprentissage du chinois RocketMQ ttps://rocketmq-learning.com

[2] File d'attente de messages cloud RocketMQ https://www.aliyun.com/product/rocketmq