第3章 テクノロジープレビュー

トークンベースの認証に OAuth 2.0 を使用している場合、Keycloak を使用して、クライアントの Kafka ブローカーへのアクセスを制限する承認ルールを設定できるようになりました。

OAuth 2.0 トークンベースの承認であるこのテクノロジープレビューは、Red Hat Single Sign-On 7.3 ではサポートされません。この機能を試す場合は、Keycloak 8.0.2 を承認サーバーとする開発環境での使用はテストされています。

AMQ Streams は、Keycloak の Authorization Services による OAuth 2.0 トークンベースの承認をサポートします。これにより、セキュリティーポリシーとパーミッションの一元的な管理が可能になります。

Keycloak で定義されたセキュリティーポリシーおよびパーミッションは、Kafka ブローカーのリソースへのアクセスを付与するために使用されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。

「OAuth 2.0 トークンベース承認の使用」を参照してください。

Service Registry は、データストリーミングのサービススキーマの集中型ストアとして使用できます。Kafka では、Service Registry を使用して Apache Avro または JSON スキーマを格納できます。

Service Registry は、REST API および Java REST クライアントを提供し、サーバー側のエンドポイントを介してクライアントアプリケーションからスキーマを登録およびクエリーします。

Service Registry を使用すると、クライアントアプリケーションの設定からスキーマ管理のプロセスが分離されます。クライアントコードに URL を指定して、アプリケーションがレジストリーからスキーマを使用できるようにします。

たとえば、メッセージをシリアライズおよびデシリアライズするスキーマをレジストリーに保存できます。保存後、スキーマを使用するアプリケーションから参照され、アプリケーションが送受信するメッセージがこれらのスキーマと互換性を維持するようにします。

Kafka クライアントアプリケーションは実行時にスキーマを Service Registry からプッシュまたはプルできます。

「Service Registry を使用したスキーマの管理」を参照してください。

AMQ Streams で MirrorMaker 2.0 を使用できるようになりました。

MirrorMaker 2.0 は Kafka Connect フレームワークをベースとし、コネクターによってクラスター間のデータ転送が管理されます。

MirrorMaker 2.0 は以下を使用します。

MirrorMaker 2.0 では、クラスターでデータをレプリケートする全く新しい方法が導入されました。MirrorMaker 2.0 の使用を選択した場合、現在、レガシーサポートがないため、リソースを手作業で新しい形式に変換する必要があります。

「AMQ Streams の MirrorMaker 2.0 との使用」を参照してください。

OpenShift クラスターが制限されたネットワークで非接続クラスター として使用されている場合、AMQ Streams の 非接続インストール を実行できます。

非接続インストールでは、必要なイメージを取得し、それらをローカルでコンテナーレジストリーにプッシュします。Operator Lifecycle Manager (OLM) を使用している場合、OperatorHub によって使用されるデフォルトのソースを無効にし、ローカルミラーを作成してローカルソースから AMQ Streams をインストールすることになります。

「ネットワークが制限された環境での Operator Lifecycle Manager の使用」を参照してください。