6.8. OAuth 2.0 トークンベース承認の使用
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.8.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.8.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.8.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 のポリシーおよびパーミッションを管理する方法を理解している必要がある。
手順
- Red Hat Single Sign-On の Admin Console にアクセスするか、Red Hat Single Sign-On の Admin CLI を使用して、OAuth 2.0 認証の設定時に作成した Kafka ブローカークライアントの Authorization Services を有効にします。
- 認可サービスを使用して、クライアントのリソース、認可スコープ、ポリシー、およびパーミッションを定義します。
- ロールとグループをユーザーとクライアントに割り当てて、パーミッションをユーザーとクライアントにバインドします。
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
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
(オプション) 特定の Kafka クラスターの設定を追加します。
以下に例を示します。
strimzi.authorization.kafka.cluster.name="kafka-cluster" 1
- 1
- 特定の Kafka クラスターの名前。名前はパーミッションをターゲットにするために使用され、同じ Red Hat シングルサインオンレルム内で複数のクラスターを管理できるようにします。デフォルト値は
kafka-cluster
です。
(オプション) シンプルな認可に委譲します。
strimzi.authorization.delegate.to.kafka.acl="true" 1
- 1
- Red Hat Single Sign-On の Authorization Services ポリシーによってアクセスが拒否された場合に、Kafka
AclAuthorizer
に認可を委譲します。デフォルトはfalse
です。
(オプション) 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
(オプション) 認可サーバーからの付与の更新を設定します。付与更新ジョブは、アクティブなトークンを列挙し、それぞれに最新の付与を要求することで機能します。
以下に例を示します。
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
です。
(オプション) 認可サーバーとの通信時のネットワークタイムアウトを設定します。
以下に例を示します。
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 ブローカーが応答しなくなる可能性があることに注意してください。
(オプション) トークンの検証と認可のために OAuth 2.0 メトリクスを有効にします。
oauth.enable.metrics="true" 1
- 1
- OAuth メトリクスを有効にするか無効にするかを制御します。デフォルト値は
false
です。
(オプション) リクエストから
Accept
ヘッダーを削除します。oauth.include.accept.header="false" 1
- 1
- ヘッダーを含めることで認可サーバーとの通信時に問題が発生する場合は、
false
に設定します。デフォルト値はtrue
です。
- クライアントまたは特定のロールを持つユーザーとして Kafka ブローカーにアクセスして、設定したパーミッションを検証し、必要なアクセス権限があり、付与されるべきでないアクセス権限がないことを確認します。