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: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 があります。

認証方法の詳細については、「 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 を持つフィールドは、各リソースでサポートされる操作をマークします。

表4.1 リソースでサポートされる操作

 トピックコンシューマーグループクラスター

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 倍の規則が必要です。

オプション説明デフォルト

add

動作

ACL ルールを追加します。

 

remove

動作

ACL ルールを削除します。

 

list

動作

ACL ルールの一覧を表示します。

 

authorizer

動作

オーソライザーの完全修飾クラス名。

kafka.security.auth.SimpleAclAuthorizer

authorizer-properties

設定

初期化のためにオーソライザーに渡されるキー/値のペア。

AclAuthorizer の場合、値の例は zookeeper.connect=zoo1.my-domain.com:2181 です。

 

bootstrap-server

リソース

Kafka クラスターに接続するためのホスト/ポートのペア。

両方ではなく、このオプションまたは authorizer オプションを使用します。

command-config

リソース

bootstrap-server パラメーターとともに使用される Admin Client に渡す設定プロパティーファイル。

 

cluster

リソース

クラスターを ACL リソースとして指定します。

 

topic

リソース

トピック名を ACL リソースとして指定します。

ワイルドカードとして使用されるアスタリスク(*)は すべてのトピック に変換されます。

1 つのコマンドで、複数の --topic オプションを指定することができます。

 

group

リソース

コンシューマーグループ名を ACL リソースとして指定します。

1 つのコマンドで、複数の --group オプションを指定することができます。

 

transactional-id

リソース

ACL リソースとしてトランザクション ID を指定します。

トランザクション配信は、プロデューサーによって複数のパーティションに送信されたすべてのメッセージを正常に配信したり、何も指定しないことを意味します。

ワイルドカードとして使用されるアスタリスク(*)は すべての ID に変換されます

 

delegation-token

リソース

委譲トークンを ACL リソースとして指定します。

ワイルドカードとして使用されるアスタリスク(*)は すべてのトークン に変換されます。

 

resource-pattern-type

設定

add パラメーターまたは list または remove パラメーターのリソースパターンのフィルター値を指定します。

literal または prefixed をリソース名のリソースパターンタイプとして使用します。

any または match をリソースパターンのフィルターの値、または特定のパターンタイプフィルターとして使用します。

literal

allow-principal

principal

許可 ACL ルールに追加されたプリンシパル。

1 つのコマンドで、複数の --allow-principal オプションを指定することができます。

 

deny-principal

principal

プリンシパルが拒否 ACL ルールに追加される。

1 つのコマンドで、複数の --deny-principal オプションを指定することができます。

 

principal

principal

プリンシパルの ACL 一覧を返す際に list パラメーターで使用されるプリンシパル名。

1 つのコマンドで、複数の --principal オプションを指定することができます。

 

allow-host

ホスト

--allow-principal に一覧表示されているプリンシパルへのアクセスを許可する IP アドレス。

ホスト名または CIDR 範囲はサポートされません。

--allow-principal を指定すると、デフォルトは * で「すべてのホスト」を意味します。

deny-host

ホスト

--deny-principal に一覧表示されているプリンシパルへのアクセスを拒否する IP アドレス。

ホスト名または CIDR 範囲はサポートされません。

--deny-principal を指定すると、デフォルトは * で「すべてのホスト」を意味します。

operation

演算子

操作を許可または拒否します。

1 つのコマンドで、複数の Multiple --operation オプションを 1 つのコマンドで指定できます。

すべて

producer

ショートカット

メッセージプロデューサーが必要とするすべての操作を許可または拒否するショートカット(トピック上の WRITE および DESCRIBE、クラスターの CREATE)。

 

consumer

ショートカット

メッセージコンシューマーが必要とするすべての操作を許可または拒否するショートカット(トピックの READ および DESCRIBE、コンシューマーグループの READ)。

 

idempotent

ショートカット

--producer パラメーターと使用する場合にべき等を有効にするショートカットで、メッセージはパーティションに 1 度だけ配信されます。

Idepmotence は、プロデューサーが特定のトランザクション ID に基づいてメッセージを送信できると、自動的に有効になります。

 

force

ショートカット

すべてのクエリーを受け入れ、プロンプトを表示しないショートカット。