7.3. OAuth 2.0 トークンベース認可の使用


Streams for Apache Kafka は、Red Hat build of Keycloak の Authorization Services による OAuth 2.0 トークンベースの認可の使用をサポートしています。これにより、セキュリティーポリシーと権限を一元的に管理できます。

Red Hat build of Keycloak で定義されたセキュリティーポリシーと権限により、Kafka リソースへのアクセスが許可されます。ユーザーとクライアントは、Kafka ブローカーで特定のアクションを実行するためのアクセスを許可するポリシーに対して照合されます。

Kafka では、デフォルトですべてのユーザーにブローカーへのフルアクセスが許可されています。ただし、アクセス制御リスト (ACL) に基づいて認可を設定するための AclAuthorizer プラグインと StandardAuthorizer プラグインも提供されています。これらのプラグインによって管理される ACL ルールは、username に基づいてリソースへのアクセスを許可または拒否するために使用され、Kafka クラスター自体に保存されます。

一方、Red Hat build of Keycloak を使用した OAuth 2.0 トークンベースの認可では、Kafka ブローカーへのアクセス制御を実装する方法に関して、はるかに高い柔軟性が得られます。さらに、Kafka ブローカーで OAuth 2.0 の認可および ACL が使用されるように設定することができます。

7.3.1. 例: OAuth 2.0 認可の有効化

この手順では、Red Hat build of Keycloak の Authorization Services を使用して、OAuth 2.0 認可を使用するように Kafka ブローカーを設定する方法を説明します。

Red Hat build of Keycloak サーバーの Authorization Services REST エンドポイントは、特定のユーザーに定義済みのセキュリティーポリシーを適用し、各リソースに付与された当該ユーザーの権限のリストを提供することで、Red Hat build of Keycloak によるトークンベースの認証を拡張します。ポリシーは、ロールとグループを使用してユーザーと権限を照合します。OAuth 2.0 認可は、Red Hat build of Keycloak Authorization Services から受信したユーザーのグラントのリストに基づいて、ローカルで権限を適用します。

Streams for Apache Kafka では、Red Hat build of Keycloak の オーソライザー (KeycloakAuthorizer) が提供されます。オーソライザーは、必要に応じて認可サーバーから付与された権限のリストを取得し、Kafka 上でローカルに認可を適用して、各クライアントリクエストに対して迅速な認可決定を行います。

作業を始める前に

特定のユーザーに必要なアクセス、または制限するアクセスについて検討してください。Red Hat build of Keycloak では、Red Hat build of Keycloak の グループロールクライアント、および ユーザー の組み合わせを使用してアクセスを設定できます。

通常、グループは組織の部門または地理的な場所を基にしてユーザーを照合するために使用されます。また、ロールは職務を基にしてユーザーを照合するために使用されます。

Red Hat build of Keycloak を使用すると、ユーザーおよびグループを LDAP で保存できますが、クライアントおよびロールは LDAP で保存できません。ユーザーデータへのアクセスとストレージを考慮して、認可ポリシーの設定方法を選択する必要がある場合があります。

注記

スーパーユーザー は、Kafka ブローカーに実装された認可にかかわらず、常に制限なく Kafka ブローカーにアクセスできます。

前提条件

  • Streams for Apache Kafka が、Red Hat build of Keycloak の トークンベースの認証 と OAuth 2.0 を使用するように設定されている。認可を設定するときに、同じ Red Hat build of Keycloak エンドポイントを使用する必要があります。
  • Red Hat build of Keycloak ドキュメント の説明のとおりに、Red Hat build of Keycloak の Authorization Services のポリシーと権限を管理する方法を理解している。

手順

  1. Red Hat build of Keycloak 管理コンソールにアクセスするか、Red Hat build of Keycloak 管理 CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka 用の OAuth 2.0 クライアントの Authorization Services を有効にします。
  2. 認可サービスを使用して、クライアントのリソース、認可スコープ、ポリシー、およびパーミッションを定義します。
  3. ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
  4. Red Hat build of Keycloak 認可を使用するように Kafka ブローカーを設定します。

    以下を Kafka server.properties 設定ファイルに追加し、Kafka に authorizer をインストールします。

    authorizer.class.name=io.strimzi.kafka.oauth.server.authorizer.KeycloakAuthorizer
    principal.builder.class=io.strimzi.kafka.oauth.server.OAuthKafkaPrincipalBuilder
  5. Kafka ブローカーの設定を追加して、認可サーバーおよび Authorization Services にアクセスします。

    ここでは、server.properties への追加プロパティーとして追加される設定例を示しますが、大文字で始める、または大文字の命名規則を使用して、環境変数として定義することもできます。

    strimzi.authorization.token.endpoint.uri="https://<auth_server_address>/auth/realms/REALM-NAME/protocol/openid-connect/token" 
    1
    
    strimzi.authorization.client.id="kafka" 
    2
    1
    Red Hat build of Keycloak への OAuth 2.0 トークンエンドポイント URL。実稼働環境の場合は、常に https:// urls を使用してください。
    2
    Authorization Services が有効な Red Hat build of Keycloak の OAuth 2.0 クライアント定義のクライアント ID。通常、kafka が ID として使用されます。
  6. (オプション) 特定の Kafka クラスターの設定を追加します。

    以下に例を示します。

    strimzi.authorization.kafka.cluster.name="kafka-cluster" 
    1
    1
    特定の Kafka クラスターの名前。名前は権限をターゲットにするために使用されます。これにより、同じ Red Hat build of Keycloak レルム内で複数のクラスターを管理できるようになります。デフォルト値は kafka-cluster です。
  7. (オプション) シンプルな認可に委譲します。

    strimzi.authorization.delegate.to.kafka.acl="true" 
    1
    1
    ed Hat build of Keycloak の Authorization Services ポリシーによってアクセスが拒否された場合に、Kafka AclAuthorizer に認可を委譲します。デフォルトは false です。
  8. (オプション) TLS 接続の設定を認可サーバーに追加します。

    以下に例を示します。

    strimzi.authorization.ssl.truststore.location=<path_to_truststore> 
    1
    
    strimzi.authorization.ssl.truststore.password=<my_truststore_password> 
    2
    
    strimzi.authorization.ssl.truststore.type=JKS 
    3
    
    strimzi.authorization.ssl.secure.random.implementation=SHA1PRNG 
    4
    
    strimzi.authorization.ssl.endpoint.identification.algorithm=HTTPS 
    5
    1
    証明書が含まれるトラストストアへのパス。
    2
    トラストストアのパスワード。
    3
    トラストストアのタイプ。設定されていない場合は、デフォルトの Java キーストアタイプが使用されます。
    4
    乱数ジェネレーターの実装。設定されていない場合は、Java プラットフォーム SDK デフォルトが使用されます。
    5
    ホスト名の検証。空の文字列に設定すると、ホスト名の検証はオフになります。設定されていない場合、デフォルト値は HTTPS で、サーバー証明書のホスト名の検証を強制します。
  9. (オプション) 認可サーバーからの付与の更新を設定します。付与更新ジョブは、アクティブなトークンを列挙し、それぞれに最新の付与を要求することで機能します。

    以下に例を示します。

    strimzi.authorization.grants.refresh.period.seconds="120" 
    1
    
    strimzi.authorization.grants.refresh.pool.size="10" 
    2
    
    strimzi.authorization.grants.max.idle.time.seconds="300" 
    3
    
    strimzi.authorization.grants.gc.period.seconds="300" 
    4
    
    strimzi.authorization.reuse.grants="false" 
    5
    1
    認可サーバーからの付与のリストが更新される頻度を指定します (デフォルトでは 1 分に 1 回)。デバッグの目的で付与の更新をオフにするには、"0" に設定します。
    2
    付与更新ジョブで使用されるスレッドプールのサイズ (並列度) を指定します。デフォルト値は "5" です。
    3
    キャッシュ内のアイドル許可を削除できるようになるまでの時間 (秒単位)。デフォルト値は 300 です。
    4
    キャッシュから古い許可を削除するジョブの連続実行間の時間 (秒単位)。デフォルト値は 300 です。
    5
    新しいセッションに対して最新の許可を取得するかどうかを制御します。無効にすると、Red Hat build of Keycloak から許可が取得され、ユーザー用にキャッシュされます。デフォルト値は true です。
  10. (オプション) 認可サーバーとの通信時のネットワークタイムアウトを設定します。

    以下に例を示します。

    strimzi.authorization.connect.timeout.seconds="60" 
    1
    
    strimzi.authorization.read.timeout.seconds="60" 
    2
    
    strimzi.authorization.http.retries="2" 
    3
    1
    Red Hat build of Keycloak トークンエンドポイントに接続するときの接続タイムアウト (秒単位)。デフォルト値は 60 です。
    2
    Red Hat build of Keycloak トークンエンドポイントに接続するときの読み取りタイムアウト (秒単位)。デフォルト値は 60 です。
    3
    認可サーバーへの失敗した HTTP リクエストを (一時停止せずに) 再試行する最大回数。デフォルト値は 0 で、再試行は実行されないことを意味します。このオプションを効果的に使用するには、strimzi.authorization.connect.timeout.seconds オプションと strimzi.authorization.read.timeout.seconds オプションのタイムアウト時間を短縮することを検討してください。ただし、再試行により現在のワーカースレッドが他のリクエストで利用できなくなる可能性があり、停止中のリクエストが多すぎると Kafka が応答しなくなる可能性があることに注意してください。
  11. (オプション) トークンの検証と認可のために OAuth 2.0 メトリクスを有効にします。

    oauth.enable.metrics="true" 
    1
    1
    OAuth メトリクスを有効にするか無効にするかを制御します。デフォルト値は false です。
  12. (オプション) リクエストから Accept ヘッダーを削除します。

    oauth.include.accept.header="false" 
    1
    1
    ヘッダーを含めることで認可サーバーとの通信時に問題が発生する場合は、false に設定します。デフォルト値は true です。
  13. クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定された権限を確認し、必要なアクセス権があり、許可されていないアクセス権がないことを確認します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る