4.7. 承認
Kafka ブローカーの承認は、オーソライザープラグインを使用して実装されます。
本セクションでは、Kafka で提供される AclAuthorizer
プラグインを使用する方法を説明します。
または、独自の承認プラグインを使用できます。たとえば、OAuth 2.0 トークンベースの認証 を使用している場合、OAuth 2.0 承認 を使用できます。
4.7.1. シンプルな ACL オーソライザー
AclAuthorizer
を含むオーソライザープラグインは、authorizer.class.name
プロパティーにより有効になります。
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
選択されたオーソライザーの完全修飾名が必要です。AclAuthorizer
の場合、完全修飾名は kafka.security.auth.SimpleAclAuthorizer
です。
4.7.1.1. ACL ルール
AclAuthorizer
は、ACL ルールを使用して Kafka ブローカーへのアクセスを管理します。
ACL ルールは以下の形式で定義されます。
プリンシパル P は、ホスト H から Kafka リソース R に対する操作 O が許可/禁止される。
たとえば、以下のようにルールを設定します。
ユーザー John は、ホスト 127.0.0.1 からトピック コメント を 表示する ことができる。
ホストは、John が接続しているマシンの IP アドレスです。
ほとんどの場合、ユーザーはプロデューサーまたはコンシューマーアプリケーションです。
Consumer01 は、ホスト 127.0.0.1 からコンシューマーグループ アカウント に 書き込む ことができる。
ACL ルールが存在しない場合
特定のリソースに ACL ルールが存在しない場合は、すべてのアクションが拒否されます。この動作は、Kafka 設定ファイル /opt/kafka/config/server.properties
で allow.everyone.if.no.acl.found
プロパティーを true
に設定すると変更できます。
4.7.1.2. プリンシパル
プリンシパル はユーザーのアイデンティティーを表します。ID の形式は、クライアントが Kafka に接続するために使用する認証メカニズムによって異なります。
-
User:ANONYMOUS
: 認証なしで接続する場合。 User:<username>
: PLAIN や SCRAM などの単純な認証メカニズムを使用して接続する場合。例:
User:admin
またはUser:user1
User:<DistinguishedName>
: TLS クライアント認証を使用して接続する場合。例:
User:CN=user1,O=MyCompany,L=Prague,C=CZ
-
User:<Kerberos username>
: Kerberos を使用して接続する場合。
DistinguishedName はクライアント証明書からの識別名です。
Kerberos ユーザー名 は Kerberos プリンシパルの主要部分で、Kerberos を使用して接続するときにデフォルトで使用されます。sasl.kerberos.principal.to.local.rules
プロパティーを使用して、Kerberos プリンシパルから Kafka プリンシパルを構築する方法を設定できます。
4.7.1.3. ユーザーの認証
承認を使用するには、認証を有効にし、クライアントにより使用される必要があります。そうでないと、すべての接続のプリンシパルは User:ANONYMOUS
になります。
認証方法の詳細は、「暗号化と認証」を参照してください。
4.7.1.4. スーパーユーザー
スーパーユーザーは、ACL ルールに関係なくすべてのアクションを実行できます。
スーパーユーザーは、super.users
プロパティーを使用して Kafka 設定ファイルで定義されます。
以下に例を示します。
super.users=User:admin,User:operator
4.7.1.5. レプリカブローカーの認証
承認を有効にすると、これはすべてのリスナーおよびすべての接続に適用されます。これには、ブローカー間のデータのレプリケーションに使用されるブローカー間の接続が含まれます。そのため、承認が有効になっている場合は、ブローカー間の接続に認証を使用し、ブローカーが使用するユーザーに十分な権限を付与してください。たとえば、ブローカー間の認証で kafka-broker
ユーザーが使用される場合、スーパーユーザー設定にはユーザー名 super.users=User:kafka-broker
が含まれている必要があります。
4.7.1.6. サポートされるリソース
Kafka ACL は、以下のようなタイプのリソースに適用できます。
- トピック
- コンシューマーグループ
- クラスター
- TransactionId
- DelegationToken
4.7.1.7. サポートされる操作
AclAuthorizer
はリソースでの操作を承認します。
以下の表で X
の付いたフィールドは、各リソースでサポートされる操作を表します。
トピック | コンシューマーグループ | クラスター | |
---|---|---|---|
Read | X | X | |
Write | X | ||
Create | X | ||
Delete | X | ||
Alter | X | ||
Describe | X | X | X |
ClusterAction | X | ||
All | X | X | X |
4.7.1.8. ACL 管理オプション
ACL ルールは、Kafka ディストリビューションパッケージの一部として提供される bin/kafka-acls.sh
ユーティリティーを使用して管理されます。
kafka-acls.sh
パラメーターオプションを使用して、ACL ルールを追加、一覧表示、および削除したり、その他の機能を実行したりします。
パラメーターには、--add
など、二重ハイフンの標記が必要です。
オプション | 型 | 説明 | デフォルト |
---|---|---|---|
| アクション | ACL ルールを追加します。 | |
| アクション | ACL ルールを削除します。 | |
| アクション | ACL ルールを一覧表示します。 | |
| アクション | オーソライザーの完全修飾クラス名。 |
|
| 設定 | 初期化のためにオーソライザーに渡されるキー/値のペア。
| |
| リソース | Kafka クラスターに接続するためのホスト/ポートのペア。 |
このオプションまたは |
| リソース |
管理クライアントに渡す設定プロパティーファイル。これは | |
| リソース | クラスターを ACL リソースとして指定します。 | |
| リソース | トピック名を ACL リソースとして指定します。
ワイルドカードとして使用されるアスタリスク (
1 つのコマンドに複数の | |
| リソース | コンシューマーグループ名を ACL リソースとして指定します。
1 つのコマンドに複数の | |
| リソース | トランザクション ID を ACL リソースとして指定します。 トランザクション配信は、プロデューサーによって複数のパーティションに送信されたすべてのメッセージが正常に配信されるか、いずれも配信されない必要があることを意味します。
ワイルドカードとして使用されるアスタリスク ( | |
| リソース | 委譲トークンを ACL リソースとして指定します。
ワイルドカードとして使用されるアスタリスク ( | |
| 設定 |
|
|
| プリンシパル | 許可 ACL ルールに追加されるプリンシパル。
1 つのコマンドに複数の | |
| プリンシパル | 拒否 ACL ルールに追加されるプリンシパル。
1 つのコマンドに複数の | |
| プリンシパル |
プリンシパルの ACL の一覧を返すために
1 つのコマンドに複数の | |
| ホスト |
ホスト名または CIDR 範囲はサポートされていません。 |
|
| ホスト |
ホスト名または CIDR 範囲はサポートされていません。 |
|
| 操作 | 操作を許可または拒否します。
1 つのコマンドに複数の | All |
| ショートカット | メッセージプロデューサーが必要とするすべての操作を許可または拒否するショートカット (トピックでの WRITE および DESCRIBE、クラスターでの CREATE)。 | |
| ショートカット | メッセージコンシューマーが必要とするすべての操作を許可または拒否するショートカット (トピックでの READ および DESCRIBE、コンシューマーグループでの READ)。 | |
| ショートカット |
特定のトランザクション ID に基づいてメッセージを送信するようにプロデューサーが承認されている場合、冪等性は自動的に有効になります。 | |
| ショートカット | すべてのクエリーを受け入れ、プロンプトは表示されないショートカット。 |