6.6. OAuth 2.0 トークンベース承認の使用


トークンベースの認証に OAuth 2.0 と Red Hat Single Sign-On を使用している場合、Red Hat Single Sign-On を使用して認可ルールを設定し、Kafka ブローカーへのクライアントのアクセスを制限することもできます。認証はユーザーのアイデンティティーを確立します。認可は、そのユーザーのアクセスレベルを決定します。

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

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

Kafka では、デフォルトですべてのユーザーにブローカーへのフルアクセスが許可されており、アクセスコントロールリスト (ACL) に基づいて認可を設定するための AclAuthorizer プラグインと StandardAuthorizer プラグインも提供されています。これらのプラグインによって管理される ACL ルールは、username に基づいてリソースへのアクセスを許可または拒否するために使用され、このようなルールは Kafka クラスター自体の中に保存されます。ただし、Red Hat Single Sign-On を使用した OAuth 2.0 トークンベースの認可では、より柔軟にアクセス制御を Kafka ブローカーに実装できます。さらに、Kafka ブローカーで OAuth 2.0 の認可および ACL が使用されるように設定することができます。

6.6.1. OAuth 2.0 の認可メカニズム

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

6.6.1.1. Kafka ブローカーのカスタム authorizer

Streams for Apache Kafka では、Red Hat Single Sign-On の オーソライザー (KeycloakAuthorizer) が提供されます。Red Hat Single Sign-On によって提供される Authorization Services で Red Hat Single Sign-On REST エンドポイントを使用できるようにするには、Kafka ブローカーでカスタム authorizer を設定します。

authorizer は必要に応じて付与された権限のリストを認可サーバーから取得し、ローカルで Kafka ブローカーに認可を強制するため、クライアントの要求ごとに迅速な認可決定が行われます。

6.6.2. OAuth 2.0 認可サポートの設定

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

作業を開始する前に

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

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

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

注記

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

前提条件

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

手順

  1. Red Hat Single Sign-On の Admin Console にアクセスするか、Red Hat Single Sign-On の Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
  2. 認可サービスを使用して、クライアントのリソース、認可スコープ、ポリシー、およびパーミッションを定義します。
  3. ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
  4. Red Hat Single Sign-On 認可を使用するように 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 Single Sign-On への OAuth 2.0 トークンエンドポイントの URL。実稼働環境の場合は、常に https:// urls を使用してください。
    2
    Authorization Services が有効な Red Hat Single Sign-On の OAuth 2.0 クライアント定義のクライアント ID。通常、kafka が ID として使用されます。
  6. (オプション) 特定の Kafka クラスターの設定を追加します。

    以下に例を示します。

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

    strimzi.authorization.delegate.to.kafka.acl="true" 1
    1
    Red Hat Single Sign-On の 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 Single Sign-On から取得され、ユーザーのためにキャッシュされます。デフォルト値は 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 Single Sign-On トークンエンドポイントに接続するときの接続タイムアウト (秒単位)。デフォルト値は 60 です。
    2
    Red Hat Single Sign-On トークンエンドポイントに接続するときの読み取りタイムアウト (秒単位)。デフォルト値は 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 をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.