Apache RocketMQ ACL 2.0 の新しいアップグレード

著者: トゥ・ジョン

導入

RocketMQ は、一般的な分散メッセージングミドルウェアとして、さまざまな大規模分散システムやマイクロサービスで広く使用されており、非同期通信、システムの分離、ピークシェービングとバレーフィル、およびメッセージ通知において重要な役割を果たします。テクノロジーの進化とビジネス規模の拡大に伴い、セキュリティ関連の課題がますます顕在化しており、特にメッセージングシステムのアクセス制御が重要となっています。ただし、RocketMQ の既存の ACL 1.0 バージョンは、将来の開発に対応できなくなりました。そのため、RocketMQ データのセキュリティをさらに向上させるために、RocketMQ ACL 2.0 アップグレードバージョンをリリースしました。この記事では、RocketMQ ACL 2.0 の新機能、動作原理、関連する構成と実践方法を紹介します。

アップグレードされた背景

ACL 1.0の問題点

RocketMQ ACL 1.0 の認証と認可のプロセスを上の図に示します。使用中には次のような問題があります。

アクセス制御をバイパスする IP ホワイトリスト: 標準的なセキュリティ実践では、クライアントが特定の IP または IP 範囲からのみリソースにアクセスすることを制限するために、IP ホワイトリストがよく使用されます。ただし、ACL 1.0 では、IP ホワイトリストが認証検証をバイパスする手段として異常に使用されており、標準的な実践のセキュリティ目的から逸脱しています。この設計の逸脱は、特に複数のクライアントが同じ IP を共有するパブリックネットワークのシナリオで潜在的なセキュリティリスクを引き起こす可能性があり、これにより、未承認の IP アドレスがクラスターデータへの通常のアクセス制御チェックをバイパスする可能性があります。

管理 API のきめ細かい制御の欠如: RocketMQ は 130 を超える管理および制御 API を提供し、クラスター構成、トピックとグループのメタデータ管理、およびメッセージクエリやサイトリセットなどの操作をサポートします。これらの操作には機密データの処理が含まれており、システムの安定性に影響します。したがって、さまざまなユーザーの役割や責任に基づいて、アクセス可能な API とデータの範囲を正確に定義することが重要になります。ただし、ACL 1.0 は、トピック、グループメタデータ、ブローカー構成を含む 9 つの API のみをサポートします。残りの API は、攻撃者がシステムを攻撃して機密データを盗むために使用される可能性があります。さらに、非常に多くの管理 API にアクセス制御を実装するには、既存の設計で多くのコーディング作業が必要となり、新しい API が追加されたときに何かが見逃されるリスクが高まります。

クラスターコンポーネント間のアクセス制御の欠如: RocketMQ アーキテクチャは、NameServer、Broker マスター/スレーブノード、プロキシなどの複数の主要コンポーネントをカバーしています。現在、これらのコンポーネント間の相互アクセスのためのキー権限検証メカニズムがありません。したがって、ブローカースレーブノードまたはプロキシコンポーネントをクラスターの外に構築すると、既存のセキュリティメカニズムをバイパスしてクラスター内の機密データにアクセスして取得できるようになり、これは間違いなくシステムのデータセキュリティと安定性に大きな影響を与えます。クラスターの脅威。

特徴と原理

ACL 2.0の新機能

RocketMQ ACL 2.0 は ACL 1.0 の問題を解決し、次の 6 つの主要な新機能ももたらします。

細かい API リソース権限定義: ACL 2.0 は、クラスター、名前空間、トピック、コンシューマーグループを含む RocketMQ システム内のすべてのリソースを定義し、あらゆるタイプのリソースに対して独立したアクセス制御を実現します。さらに、すべての API を権限制御の範囲に組み込み、メッセージの送受信、クラスター管理、メタデータなどを含むさまざまな操作をカバーし、すべてのリソースのあらゆる操作に厳密な権限制御が課されるようにします。

認可されたリソースに対する複数のマッチングモード: 多数のリソースがあるクラスター環境では、各リソースを 1 つずつ認可すると、複雑な構成プロセスと管理の負担が生じます。したがって、ACL 2.0 では、完全一致、プレフィックス一致、およびワイルドカード一致という 3 つの柔軟な一致モードが導入されています。これらのモードにより、ユーザーはリソースの命名規則や構造的特性に基づいて統一された設定を迅速に行うことができ、権限管理操作が簡素化され、構成効率が向上します。

クラスターコンポーネント間のアクセス制御のサポート: すべてのリソースタイプと API 操作がアクセス制御システムに含まれているため、クラスター内のコンポーネント間の接続とアクセスも、ブローカーのマスターとスレーブ間のリーダーの選出やデータレプリケーションなどの権限制御の対象となります。これにより、潜在的なデータ漏洩の問題やシステムの安定性に対するリスクを効果的に回避し、クラスター全体のセキュリティと信頼性を強化できます。

ユーザー認証と権限検証の分離: 認証と認可の 2 つの主要なモジュールを分離することで、システムはさまざまなシナリオのニーズに適応するために、「認証なしで認証のみ」などの柔軟なオプションを提供できます。また、これら 2 つのコンポーネントは独立して進化・発展することができるため、さまざまな認証方式や高度な認証方式が生まれます。

セキュリティとパフォーマンスのバランス: ACL が有効な場合、クライアントからの各リクエストは完全な認証および認可プロセスを通過する必要があります。これによりシステムのセキュリティが確保されますが、パフォーマンスのオーバーヘッドも発生します。 ACL 2.0 では、ステートレスな認証および認可戦略とステートフルな認証および認可戦略が提供され、2 つの異なるセキュリティおよびパフォーマンス要件、つまり、極度のセキュリティ要件と、セキュリティは制御可能だがパフォーマンス優先という要件を満たすことができます。

柔軟で拡張可能なプラグインメカニズム: 現在の市場では、複数の認証方法が実装されており、認可方法にもさまざまなシナリオに合わせたカスタマイズ要件があります。したがって、ACL 2.0 は、将来の認証と認可の拡張をサポートし、ユーザーが独自のビジネスニーズに応じて対応するソリューションをカスタマイズして実装できるように、さまざまなレベルでインターフェイスを定義および抽象化するプラグインフレームワークを設計しました。

アクセス制御モデル

ロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) は、アクセス制御システムの 2 つの主な方法です。 RocketMQ ACL 2.0 は、これら 2 つの方法を統合して、より柔軟で強力なアクセス制御システムを作成します。

RBAC は、ロールを通じてアクセス許可を割り当てるロールベースのアクセス制御モデルです。 RocketMQ ACL 2.0 は、ユーザーの役割をスーパーユーザー (Super) と通常のユーザー (Normal) に分割し、スーパーユーザーは最高レベルの権限を持ち、承認なしでリソースにアクセスできるため、クラスターの初期化や日常の運用とメンテナンスの際の権限の依存関係が簡素化されます。一般のユーザーは、リソースにアクセスする前に、対応するアクセス許可を付与する必要があります。これは、ビジネスシナリオでのリソースへのオンデマンドアクセスに適しています。

ABAC は、ユーザー、リソース、環境、操作などの多次元属性を通じてアクセス制御ポリシーを表現する属性ベースのアクセス制御モデルです。 RocketMQ ACL 2.0 は、一般ユーザーにこの柔軟なアクセス制御メカニズムを提供します。管理者がビジネスニーズ、ユーザーの責任、その他の要素に基づいてリソースへのより洗練されたアクセス制御を実装できるようにします。

セキュリティシステムでは、認証と認可はそれぞれ異なる役割を果たします。RocetMQ ACL 2.0 は、認証と認可をモジュールに分離します。これにより、両方のコンポーネントがそれぞれの役割を確実に実行し、システムの複雑さが軽減されます。認証サービスはユーザー ID の正当性の検証に特化するのに対し、認可サービスはユーザーのアクセス許可とアクセス制御の管理に重点を置きます。この分割により、コードの管理、保守、拡張が容易になるだけでなく、ユーザーに使用上の柔軟性も提供されます。ニーズに応じて、ユーザーは認証サービスまたは認可サービスを個別に有効にすることを選択することも、両方を同時に有効にすることも選択できます。これにより、RocketMQ ACL は、単純なシナリオの迅速な展開に対応し、複雑な環境における厳格なセキュリティ要件に適応できるようになります。

認証

認証は、アクセス要求を開始した人物の信頼性を検証するために設計されたセキュリティメカニズムです。これは、正当な認証されたユーザーまたはエンティティのみが保護されたリソースにアクセスしたり、特定の操作を実行したりできるようにするために使用されます。簡単に言うと、認証とは、リソースやサービスにアクセスする前に「あなたは誰ですか?」という質問に答えることです。

RocketMQ ACL 2.0 バージョンは、ACL 1.0 と同じ認証メカニズム、つまり AK/SK ベースの認証方式を維持します。この方法では、主に対称暗号化テクノロジーを使用してクライアントの身元を確認し、機密の認証情報 (パスワードなど) がネットワーク上で平文で送信されないようにするため、全体的な認証セキュリティが向上します。

エージェントモデル

RocketMQ システムのアクセス制御と権限管理を改善するために、ACL 2.0 では、主要モデルに対して次の改善と拡張が行われました。

1. 統一サブジェクトモデルの抽象化: さまざまなエンティティのアクセス制御と権限管理を実現するために、システム内の複数のインスタンスがリソースアクセスのサブジェクトとして機能できるように、統一サブジェクトインターフェイスが設計されています。リソースにアクセスするサブジェクトの 1 つとして、ユーザーはこのモデルに従ってサブジェクトのインターフェイスを実装します。これにより、将来の新しいエンティティタイプにアクセス許可を適応させるための拡張機能が提供されます。

2. 役割の分類と権限の付与:

スーパーユーザー: 管理プロセスを簡素化するために、スーパーユーザーには個別の設定を必要とせずにすべての権限が自動的に付与されるため、システムの初期化や日常の運用保守管理が簡素化されます。
一般ユーザー: 一般ユーザーの権限には明示的な承認が必要です。 ACL 2.0 は、組織のポリシーとセキュリティ要件に基づいて、一般ユーザーに適切なアクセス許可を付与できる、関連するアクセス許可管理ツールを提供します。

3. ユーザーステータス管理のサポート: ユーザーパスワードの漏洩など、起こり得るセキュリティリスクに対処するために、ACL 2.0 はユーザーの有効化および無効化機能を提供します。セキュリティインシデントが発生した場合、ユーザーステータスを無効にして迅速に止血することができ、不正アクセスを防止します。

認証プロセス

クライアントプロセス:

RPC リクエストを作成するときに、クライアントはユーザー名とパスワードが設定されているかどうかを確認します。設定されていない場合、クライアントはリクエストを直接送信します。
構成されている場合、プリセット暗号化アルゴリズムを使用してリクエストパラメーターが暗号化され、対応するデジタル署名 (署名) が生成されます。
ユーザー名と署名をリクエストに追加し、認証のためにサーバーに送信します。

サーバープロセス:

リクエストを受信した後、サーバーはまず認証がオンになっているかどうかを確認し、オンになっていない場合は検証なしで通過し、次のステップに進みます。
サーバーは、リクエスト認証に関連するパラメータを解析して組み立て、ユーザー名や署名などの情報を取得します。
ユーザー名を使用してローカルデータベース内のユーザー関連情報を照会します。ユーザーが存在しない場合、処理は「なし」として返され、次のステップに進みます。
ユーザーのパスワードを取得し、同じ暗号化アルゴリズムを使用してリクエストを暗号化して署名を生成し、クライアントから渡された署名と比較します。両者が一致していれば認証は成功します。一致していなければ認証は失敗します。

認可

核となるアイデア

認可は、アクセス要求者が特定のリソースを操作する権限を持っているかどうかを判断するために設計されたセキュリティメカニズムです。つまり、承認とは、リソースにアクセスする前に、「誰がどのような状況でどのリソースに対してどのような操作を実行したか」という質問に答えることです。

「属性ベースのアクセス制御 (ABAC)」モデルに基づいて、RocketMQ ACL 2.0 は次の一連の中心概念をカバーします。システム実装では、権利管理および承認メカニズム全体の設計と実装を完了するためのガイダンスとして、次の概念が使用されます。

権限モデル

属性ベースのアクセス制御 (ABAC) モデルの核となる概念である ACL 2.0 は、アクセス許可モデルを慎重に設計しました。重要なポイントは次のとおりです。

下位互換性のあるアクセス許可ポリシー: デフォルトでは、ACL 2.0 はユーザー定義のアクセス許可のみを照合およびチェックし、一致が見つからない場合は、リソースにアクセスするアクセス許可がないと見なされます。ただし、ACL 1.0 にはデフォルトの権限設定があり、一致しないリソースに対して「権限アクセスなし」または「権限アクセスあり」をデフォルトで決定できることを考慮します。したがって、ACL 1.0 から ACL 2.0 へのシームレスな移行を保証するために、デフォルトのアクセス許可ポリシーとの互換性を実装しました。

柔軟なリソースマッチングモード: リソースタイプに関して、ACL 2.0 は、さまざまなタイプのリソースへのアクセスを制御するために使用されるクラスター、ネームスペース、トピック、コンシューマーグループなどのタイプをサポートします。リソース名に関しては、完全一致 (LITERAL)、接頭辞一致 (PREFIXED)、およびワイルドカード一致 (ANY) の 3 つのモードが導入され、ユーザーがリソースの命名仕様と構造に基づいて統合アクセスルールを迅速に設定し、権限を簡素化できるようになりました。。管理。

細かいリソース操作タイプ: メッセージ送信インターフェイスと消費インターフェイスに関して、それらはそれぞれ PUB 操作と SUB 操作として定義されます。クラスターとリソースの管理インターフェイスに関しては、CREATE、UPDATE、DELETE、LIST、GET の 5 つの操作が定義されています。この操作タイプの改良により、ユーザーはリソース操作レベルでの特定のインターフェイス定義を気にすることなく、操作の理解と構成を簡素化できます。

確実なアクセス環境検証：ACL 2.0では、アクセスを要求する環境において、クライアントの要求元のIPソースの検証を追加し、リソース単位での制御を正確に行うことができます。 IP ソースは特定の IP アドレスまたは IP セグメントにすることができ、さまざまな粒度で IP アクセス制御に対応し、システムセキュリティに強固な防御線を追加できます。

認可プロセス

クライアントプロセス:

クライアントは RPC 要求を作成するときに、この呼び出しのインターフェイス入力パラメータを作成します。このインターフェイスは、アクセス許可の背後にある操作定義に対応します。
クライアントは、インターフェイスの入力パラメーターにこの訪問のリソース情報を設定し、ユーザーやリソースなどのパラメーターをサーバーに渡します。

サーバープロセス:

リクエストを受信した後、サーバーはまず認証がオンになっているかどうかを確認し、オンになっていない場合は検証せずに通過し、次のステップに進みます。
サーバーは、リクエスト内の認可関連パラメータを解析して組み立てます。これらのデータには、ユーザー情報、アクセスされたリソース、実行された操作、および要求された環境が含まれます。
ユーザー名を使用してローカルデータストレージ内のユーザー関連情報を照会します。ユーザーが存在しない場合はエラーが返され、次のステップに進みます。
現在のユーザーがスーパーユーザーであるかどうかを確認します。スーパーユーザーの場合、リクエストは権限チェックなしで直接渡されます。通常のユーザーの場合は、詳細な権限チェックの次のステップに進みます。
ユーザー名に基づいて関連する認可ポリシーのリストを取得し、今回要求されたリソース、操作、および環境を照合し、優先度に従って並べ替えます。
決定は、最も優先度の高い認可ポリシーに基づいて行われます。認可ポリシーが操作を許可する場合は、認可成功が返されます。操作が拒否されると、権限なしエラーが返されます。

認可パラメータの分析

ACL 2.0 では、認可関連のパラメータ (リソース、オペレーションなど) の解析が、オペレーションタイプとリクエスト頻度に基づいて最適化されます。

ハードコードされた分析

メッセージの送信や消費などのインターフェイスの場合、パラメータは比較的複雑で、リクエストの頻度は比較的高くなります。解析の利便性とパフォーマンス要件を考慮して、解析にはハードコーディングが使用されます。

アノテーション分析

多数の管理および制御インターフェースの場合、ハードコーディングの負荷は大きく、これらのインターフェースの呼び出し頻度は低く、パフォーマンス要件も高くないため、コーディング効率を向上させるためにアノテーションが分析に使用されます。

アクセス許可ポリシーの優先順位

アクセス許可ポリシーのマッチングに関しては、ファジーリソースマッチングモードをサポートしているため、同じリソースが複数のアクセス許可ポリシーに対応する可能性があります。したがって、どのアクセス許可ポリシーのセットが最終的に使用されるかを決定するには、優先順位のメカニズムが必要です。

次の認可ポリシーが設定されており、上記の優先リソースの一致状況が次のとおりであると仮定します。

認証と認可の戦略

セキュリティとパフォーマンスのトレードオフと考慮事項のため、RocketMQ ACL 2.0 では、認証と認可について 2 つの戦略、ステートレス認証と認可戦略 (ステートレス) とステートフル認証と認可戦略 (ステートフル) が提供されています。

ステートレス認証および認可戦略 (ステートレス) : この戦略では、各リクエストは独立した認証および認可プロセスを通過し、以前のセッションおよび状態情報には依存しません。この厳格なポリシーにより、より高いレベルのセキュリティ保証が保証されます。権限への変更は、待機することなく、よりリアルタイムに後続のリクエストに反映できます。ただし、この戦略は、システム CPU 使用率の増加や要求に時間がかかるなど、高スループットのシナリオでパフォーマンスに重大な負担を引き起こす可能性があります。

ステートフル認証および認可戦略 (ステートフル) : この戦略では、同じクライアント接続、同じリソース、および同じ操作の下で、最初のリクエストは完全に認証および認可され、後続のリクエストは繰り返し認証および認可されません。この方法は、パフォーマンスを効果的に低下させ、要求時間を短縮できるため、スループットが高いシナリオに特に適しています。ただし、この戦略ではセキュリティが侵害される可能性があり、アクセス許可の変更がリアルタイムで反映されない可能性があります。

これら 2 つの戦略のどちらかを選択する場合は、システムのセキュリティ要件とパフォーマンス要件を比較検討する必要があります。システムに高いセキュリティ要件があり、一定のパフォーマンス損失を許容できる場合は、ステートレスな認証および認可戦略の方が適切な選択となる可能性があります。逆に、システムが多数の同時リクエストを処理する必要があり、セキュリティ要件をある程度緩和できる場合は、ステートフルな認証および認可戦略の方が適している可能性があります。実際の展開中は、特定のビジネスシナリオとセキュリティ要件にも基づいて決定を下す必要があります。

プラグイン機構

将来の認証方法の継続的な開発に適応し、特定のシナリオに対するユーザーのカスタマイズされたニーズを満たすために、RocketMQ ACL 2.0 はさまざまな側面で柔軟性と拡張性を提供します。

認証および認可ポリシーの拡張: デフォルトでは、RocketMQ ACL 2.0 はステートレス認証および認可ポリシー (ステートレス) とステートフル認証および認可ポリシー (ステートフル) を提供し、ほとんどのユーザーのセキュリティおよびパフォーマンス要件を満たします。ただし、セキュリティとパフォーマンスのバランスを取るために、より良い戦略が将来的に模索される可能性があります。

認証および認可方法の拡張: 現在、市場には多くの成熟した実装があり、RocketMQ はプラグイン機能を介して実装されていますが、将来的にはさらに多くの実装が簡単に導入できるようになります。認証メカニズム。認可に関しては、RocketMQ は ABAC モデルに基づいた一連の主流の認可方法を実装し、幅広いユーザーのニーズに適応します。ただし、将来の開発に合わせてより多くのソリューションの適応を容易にするプラグイン機能も提供します。

認証および認可プロセスのオーケストレーション: 責任連鎖設計パターンに基づいて、RocketMQ ACL 2.0 はデフォルトの認証および認可プロセスを柔軟にオーケストレーションします。ユーザーは、これらの責任チェーンノードを拡張または書き換えて、特定のビジネスシナリオに合わせて認証および認可ロジックをカスタマイズできます。

ユーザーと権限のストレージの拡張: RocketMQ はデフォルトで RocksDB を使用して、ユーザーと権限のデータをブローカーノードにローカルに保存します。ただし、事前定義されたインターフェイスを実装することで、ユーザーはこのデータをサードパーティのサービスやストレージシステムに簡単に移行できるため、アーキテクチャ設計と運用効率が最適化されます。

監査ログ

監査ログは、認証と認可に関連するすべてのアクセス制御操作を記録および監視するために使用されます。アップグレードログを通じて、すべてのアクセス要求を追跡し、システムの信頼性とセキュリティを確保すると同時に、問題のトラブルシューティング、安全なアップグレードの実行、コンプライアンス要件の遵守にも役立ちます。

RocketMQ ACL 2.0 は、認証と認可に関連する監査ログをサポートします。形式は次のとおりです。

認証ログ

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

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

認可ログ

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

構成と使用方法

導入アーキテクチャ

導入アーキテクチャに関して、RocketMQ は、ストレージとコンピューティングの統合アーキテクチャと、ストレージとコンピューティングの分離アーキテクチャという 2 つの導入形式を提供します。

統合されたストレージとコンピューティングのアーキテクチャ

RocketMQ 統合ストレージおよびコンピューティングアーキテクチャでは、ブローカーコンポーネントがコンピューティングとストレージの両方の役割を引き受け、外部サービスを提供し、すべてのクライアントからのアクセス要求を受け取ります。したがって、Broker コンポーネントは認証と認可において重要な役割を果たします。さらに、ブローカーコンポーネントは、認証と認可に関連するメタデータのメンテナンスと保存も担当します。

ストレージと計算の分離アーキテクチャ

RocketMQ のストレージと計算の分離アーキテクチャでは、ストレージはブローカーコンポーネントによって処理され、計算はプロキシコンポーネントによって処理されます。すべての外部リクエストはプロキシによって処理されます。したがって、リクエストの認証と認可はプロキシコンポーネントによって行われます。ブローカーはメタデータのストレージを担当し、プロキシコンポーネントに必要な認証と認可のメタデータクエリと管理サービスを提供します。

クラスタ構成

認証構成

パラメータリスト

サーバー側で認証機能を有効にする場合、関連するパラメーターと使用例には主に次のものが含まれます。

ブローカーの構成

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

プロキシ構成

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

認可設定

パラメータリスト

サーバー側で認可機能を有効にする場合、関連するパラメーターと使用例には主に次のものが含まれます。

ブローカーの構成

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

プロキシ構成

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

使い方

コマンドラインの使用法

ユーザー管理

ACL ユーザーの管理に関して、関連するインターフェイスの定義と使用例は次のとおりです。

インターフェースの定義

使用例

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

ACLの管理

ACL 認可の管理に関して、関連するインターフェイスの定義と使用例は次のとおりです。

インターフェースの定義

使用例

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

クライアントの使用

ACL の使用に関しては、ACL 2.0 と ACL 1.0 は違いなく同じように使用されます。詳細については、公式のケースを参照してください。

メッセージ送信

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

メッセージの消費

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

拡張と移行

拡大

クラスターの実行中にブローカーを拡張する場合は、すべてのメタデータを新しいブローカーに同期する必要があります。ACL 2.0 は、この操作をサポートするために、対応するコピーユーザーおよびコピー認可インターフェイスを提供します。

インターフェースの定義

使用例

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

移行する

すでに ACL 1.0 を使用していて、ACL 2.0 にシームレスに移行したい場合は、次の設定を行うだけで、対応するソリューションも提供されます。

構成定義

ブローカーの構成ファイルで次の構成を有効にします。

migrateAuthFromV1Enabled = true

特記事項

上記の設定を有効にすると、ブローカーの起動時に実行が自動的にトリガーされます。この移行機能は、ACL 1.0 のユーザー許可情報を ACL 2.0 の対応するストレージ構造に書き込みます。

ACL 2.0 にまだ存在しないユーザーと権限は、システムによって自動的に追加されます。 ACL 2.0 で行われた変更が上書きされるのを避けるため、移行機能は既存のユーザーと権限を上書きしません。

ACL 1.0 の IP ホワイトリストは、アクセス制御チェックをバイパスするために使用され、ACL 2.0 の動作と一致しないため、ACL 2.0 には移行されません。関連する機能をすでに使用している場合は、移行する前に変換を完了してください。

計画と概要

計画

RocketMQ ACL の将来の計画は、次の 2 つの側面に反映される可能性があります。

豊富な認証および認可の拡張機能: 市場には豊富な認証および認可ソリューションがあり、他のストレージ製品やコンピューティング製品もさまざまな実装方法を採用しています。業界の発展傾向に追いつくために、RocketMQ ACL は将来的にも革新に努め、より広範で変化する顧客のニーズに対応していきます。同時に、セキュリティとパフォーマンスの理想的なバランスを達成するために、引き続き研究を深め、より優れた認証および認可戦略を開発していきます。
視覚的なユーザー権限の操作: 現在、ユーザーと権限はコマンドラインツールを使用して ACL でのみ設定できますが、これは十分に使いやすいものではありません。将来的には、RocketMQ ダッシュボード上に明確で使いやすい視覚的な管理インターフェイスを提供して、構成プロセスを簡素化し、管理の技術的な敷居を下げたいと考えています。一方、既存のダッシュボードにはまだACLアクセス制御システムが組み込まれておらず、将来的にはACLアクセス制御システムも組み込まれ、ダッシュボード上のさまざまなリソースを操作するためのアクセス権をユーザーに提供する予定です。

要約する

RocketMQ ACL 2.0 は、モデル設計、拡張性、セキュリティ、パフォーマンスの点でまったく新しいアップグレードを受けています。これは、権限設定プロセスを簡素化しながら、ユーザーに洗練されたアクセス制御を提供するように設計されています。どなたでも新しいバージョンを試して実稼働環境に適用することを歓迎します。 RocketMQ コミュニティの成長と技術的進歩を共同で促進するために、皆様のフィードバック、ディスカッション、コミュニティへの参加を楽しみにしています。 Apache RocketMQ China Developers DingTalk グループへの参加を歓迎します。 (グループ番号: 21982288)

関連リンク：

[1] RocketMQ 中国語学習サイトttps://rocketmq-learning.com

[2] クラウドメッセージキューRocketMQ https://www.aliyun.com/product/rocketmq