5.4. OAuth 2.0 トークンベース認証の使用
AMQ Streams は、OAUTHBEARER および PLAIN メカニズムを使用して、OAuth 2.0 認証 の使用をサポートします。
OAuth 2.0 は、アプリケーション間で標準的なトークンベースの認証および承認を有効にし、中央の承認サーバーを使用してリソースに制限されたアクセス権限を付与するトークンを発行します。
OAuth 2.0 認証を設定した後に OAuth 2.0 承認 を設定できます。
Kafka ブローカーおよびクライアントの両方が OAuth 2.0 を使用するように設定する必要があります。OAuth 2.0 認証は、simple
または OPA ベースの Kafka authorization と併用することもできます。
OAuth 2.0 のトークンベースの認証を使用すると、アプリケーションクライアントはアカウントのクレデンシャルを公開せずにアプリケーションサーバー (リソースサーバー と呼ばれる) のリソースにアクセスできます。
アプリケーションクライアントは、アクセストークンを認証の手段として渡します。アプリケーションサーバーはこれを使用して、付与するアクセス権限のレベルを決定することもできます。承認サーバーは、アクセスの付与とアクセスに関する問い合わせを処理します。
AMQ Streams のコンテキストでは以下が行われます。
- Kafka ブローカーは OAuth 2.0 リソースサーバーとして動作します。
- Kafka クライアントは OAuth 2.0 アプリケーションクライアントとして動作します。
Kafka クライアントは Kafka ブローカーに対して認証を行います。ブローカーおよびクライアントは、必要に応じて OAuth 2.0 承認サーバーと通信し、アクセストークンを取得または検証します。
AMQ Streams のデプロイメントでは、OAuth 2.0 インテグレーションは以下を提供します。
- Kafka ブローカーのサーバー側 OAuth 2.0 サポート。
- Kafka MirrorMaker、Kafka Connect、および Kafka Bridge のクライアント側 OAuth 2.0 サポート。
5.4.1. OAuth 2.0 認証メカニズム リンクのコピーリンクがクリップボードにコピーされました!
AMQ Streams は、OAuth 2.0 認証で OAUTHBEARER および PLAIN メカニズムをサポートします。どちらのメカニズムも、Kafka クライアントが Kafka ブローカーで認証されたセッションを確立できるようにします。クライアント、承認サーバー、および Kafka ブローカー間の認証フローは、メカニズムごとに異なります。
可能な限り、OAUTHBEARER を使用するようにクライアントを設定することが推奨されます。OAUTHBEARER では、クライアントクレデンシャルは Kafka ブローカーと共有されることがないため、PLAIN よりも高レベルのセキュリティーが提供されます。OAUTHBEARER をサポートしない Kafka クライアントの場合のみ、PLAIN の使用を検討してください。
クライアントの接続に OAuth 2.0 認証を使用するように Kafka ブローカーリスナーを設定します。必要な場合は、同じ oauth
リスナーで OAUTHBEARER および PLAIN メカニズムを使用できます。各メカニズムをサポートするプロパティーは、oauth
リスナー設定で明示的に指定する必要があります。
OAUTHBEARER の概要
OAUTHBEARER は、Kafka ブローカーの oauth
リスナー設定で自動的に有効になります。enableOauthBearer
プロパティーを true
に設定できますが、これは必須ではありません。
# ... authentication: type: oauth # ... enableOauthBearer: true
# ...
authentication:
type: oauth
# ...
enableOauthBearer: true
また、多くの Kafka クライアントツールでは、プロトコルレベルで OAUTHBEARER の基本サポートを提供するライブラリーを使用します。AMQ Streams では、アプリケーションの開発をサポートするために、アップストリームの Kafka Client Java ライブラリーに OAuth コールバックハンドラー が提供されます (ただし、他のライブラリーは対象外)。そのため、独自のコールバックハンドラーを作成する必要はありません。アプリケーションクライアントはコールバックハンドラーを使用してアクセストークンを提供できます。Go などの他言語で書かれたクライアントは、カスタムコードを使用して承認サーバーに接続し、アクセストークンを取得する必要があります。
OAUTHBEARER を使用する場合、クライアントはクレデンシャルを交換するために Kafka ブローカーでセッションを開始します。ここで、クレデンシャルはコールバックハンドラーによって提供されるベアラートークンの形式を取ります。コールバックを使用して、以下の 3 つの方法のいずれかでトークンの提供を設定できます。
- クライアント ID および Secret (OAuth 2.0 クライアントクレデンシャルメカニズム を使用)
- 設定時に手動で取得された有効期限の長いアクセストークン
- 設定時に手動で取得された有効期限の長い更新トークン
OAUTHBEARER 認証は、プロトコルレベルで OAUTHBEARER メカニズムをサポートする Kafka クライアントでのみ使用できます。
PLAIN の概要
PLAIN を使用するには、Kafka ブローカーの oauth
リスナー設定で有効にする必要があります。
以下の例では、デフォルトで有効になっている OAUTHBEARER に加え、PLAIN も有効になっています。PLAIN のみを使用する場合は、enableOauthBearer
を false
に設定して OAUTHBEARER を無効にすることができます。
PLAIN は、すべての Kafka クライアントツールによって使用される簡単な認証メカニズムです。PLAIN を OAuth 2.0 認証で使用できるようにするために、AMQ Streams では OAuth 2.0 over PLAIN サーバー側のコールバックが提供されます。
PLAIN の AMQ Streams 実装では、クライアントのクレデンシャルは ZooKeeper に保存されません。代わりに、OAUTHBEARER 認証が使用される場合と同様に、クライアントのクレデンシャルは準拠した承認サーバーの背後で一元的に処理されます。
OAuth 2.0 over PLAIN コールバックを併用する場合、以下のいずれかの方法を使用して Kafka クライアントは Kafka ブローカーで認証されます。
- クライアント ID およびシークレット (OAuth 2.0 クライアントクレデンシャルメカニズムを使用)
- 設定時に手動で取得された有効期限の長いアクセストークン
どちらの方法でも、クライアントは Kafka ブローカーにクレデンシャルを渡すために、PLAIN username
および password
プロパティーを提供する必要があります。クライアントはこれらのプロパティーを使用してクライアント ID およびシークレット、または、ユーザー名およびアクセストークンを渡します。
クライアント ID およびシークレットは、アクセストークンの取得に使用されます。
アクセストークンは、password
プロパティーの値として渡されます。$accessToken:
プレフィックスの有無に関わらずアクセストークンを渡します。
-
リスナー設定でトークンエンドポイント(
tokenEndpointUri
)を設定する場合は、プレフィックスが必要です。 -
リスナー設定でトークンエンドポイント(
tokenEndpointUri
)を設定しない場合は、プレフィックスは必要ありません。Kafka ブローカーは、パスワードを raw アクセストークンとして解釈します。
アクセストークンとして password
が設定されている場合、username
はKafka ブローカーがアクセストークンから取得するプリンシパル名と同じものを設定する必要があります。userNameClaim
、fallbackUserNameClaim
、fallbackUsernamePrefix
、および userInfoEndpointUri
プロパティーを使用すると、リスナーにユーザー名抽出オプションを指定できます。ユーザー名の抽出プロセスも、承認サーバーによって異なります。特に、クライアント ID をアカウント名にマッピングする方法により異なります。