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 ルールは、以下の形式で定義されます。
principal P is allowed/ denied operation O on Kafka resource R from host H
たとえば、ユーザーが以下を行うようにルールを設定できます。
John は、ホスト 127.0.0.1からトピックの コメント を 表示 できます。
host は、John が接続しているマシンの IP アドレスです。
多くの場合、ユーザーはプロデューサーまたはコンシューマーアプリケーションです。
consumer01 は、ホスト 127.0.0.1 から コンシューマーグループアカウントに 書き込む ことができる。
ACL ルールが存在しない場合
指定のリソースに ACL ルールが存在しない場合は、すべてのアクションが拒否されます。この動作は、Kafka 設定ファイルの allow.everyone.if.no.acl.found プロパティーを true に設定すると変更できます。/opt/kafka/config/server.properties
4.7.1.2. principals
プリンシパル はユーザーのアイデンティティーを表します。ID の形式は、クライアントが Kafka に接続するための認証メカニズムによって異なります。
-
User:ANONYMOUS認証なしで接続する場合。 User:<username>PLAIN や SCRAM などの簡単な認証メカニズムを使用して接続する場合。例：
User:adminまたはUser:user1User:<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 があります。
認証方法の詳細については、「 Encryption and authentication 」を参照してください。
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 | ||
| すべて | X | X | X |
4.7.1.8. ACL 管理オプション
ACL ルールは、Kafka ディストリビューションパッケージの一部として提供される bin/kafka-acls.sh ユーティリティーを使用して管理されます。
kafka-acls.sh パラメーターオプションを使用して ACL ルールを追加、一覧表示、および削除し、その他の機能を実行します。
パラメーターには、--add のように 2 倍の規則が必要です。
| オプション | 型 | 説明 | デフォルト |
|---|---|---|---|
|
| 動作 | ACL ルールを追加します。 | |
|
| 動作 | ACL ルールを削除します。 | |
|
| 動作 | ACL ルールの一覧を表示します。 | |
|
| 動作 | オーソライザーの完全修飾クラス名。 |
|
|
| 設定 | 初期化のためにオーソライザーに渡されるキー/値のペア。
| |
|
| リソース | Kafka クラスターに接続するためのホスト/ポートのペア。 |
両方ではなく、このオプションまたは |
|
| リソース |
| |
|
| リソース | クラスターを ACL リソースとして指定します。 | |
|
| リソース | トピック名を ACL リソースとして指定します。
ワイルドカードとして使用されるアスタリスク(
1 つのコマンドで、複数の | |
|
| リソース | コンシューマーグループ名を ACL リソースとして指定します。
1 つのコマンドで、複数の | |
|
| リソース | ACL リソースとしてトランザクション ID を指定します。 トランザクション配信は、プロデューサーによって複数のパーティションに送信されたすべてのメッセージを正常に配信したり、何も指定しないことを意味します。
ワイルドカードとして使用されるアスタリスク( | |
|
| リソース | 委譲トークンを ACL リソースとして指定します。
ワイルドカードとして使用されるアスタリスク( | |
|
| 設定 |
|
|
|
| principal | 許可 ACL ルールに追加されたプリンシパル。
1 つのコマンドで、複数の | |
|
| principal | プリンシパルが拒否 ACL ルールに追加される。
1 つのコマンドで、複数の | |
|
| principal |
プリンシパルの ACL 一覧を返す際に
1 つのコマンドで、複数の | |
|
| ホスト |
ホスト名または CIDR 範囲はサポートされません。 |
|
|
| ホスト |
ホスト名または CIDR 範囲はサポートされません。 |
|
|
| 演算子 | 操作を許可または拒否します。
1 つのコマンドで、複数の Multiple | すべて |
|
| ショートカット | メッセージプロデューサーが必要とするすべての操作を許可または拒否するショートカット（トピック上の WRITE および DESCRIBE、クラスターの CREATE）。 | |
|
| ショートカット | メッセージコンシューマーが必要とするすべての操作を許可または拒否するショートカット（トピックの READ および DESCRIBE、コンシューマーグループの READ）。 | |
|
| ショートカット |
Idepmotence は、プロデューサーが特定のトランザクション ID に基づいてメッセージを送信できると、自動的に有効になります。 | |
|
| ショートカット | すべてのクエリーを受け入れ、プロンプトを表示しないショートカット。 |
