4.7. 認可


Kafka ブローカーの認可は、authorizer プラグインを使用して実装されます。

本セクションでは、Kafka で提供される AclAuthorizer プラグインを使用する方法を説明します。

または、独自の認可プラグインを使用できます。たとえば、OAuth 2.0 トークンベースの認証 を使用している場合、OAuth 2.0 認可 を使用できます。

4.7.1. シンプルな ACL authorizer

AclAuthorizer を含む authorizer プラグインは authorizer.class.name プロパティーを使用して有効にします。

authorizer.class.name=kafka.security.auth.AclAuthorizer
Copy to Clipboard Toggle word wrap

選択した authorizer には完全修飾名が必要です。AclAuthorizer の場合、完全修飾名は kafka.security.auth.AclAuthorizer です。

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.propertiesallow.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
Copy to Clipboard Toggle word wrap

4.7.1.5. レプリカブローカーの認証

認可を有効にすると、これはすべてのリスナーおよびすべての接続に適用されます。これには、ブローカー間のデータのレプリケーションに使用される inter-broker の接続が含まれます。そのため、認可を有効にする場合は、inter-broker 接続に認証を使用し、ブローカーが使用するユーザーに十分な権限を付与してください。たとえば、ブローカー間の認証で kafka-broker ユーザーが使用される場合、スーパーユーザー設定にはユーザー名 super.users=User:kafka-broker が含まれている必要があります。

4.7.1.6. サポートされるリソース

Kafka ACL は、以下のタイプのリソースに適用できます。

  • Topics
  • コンシューマーグループ
  • クラスター
  • TransactionId
  • DelegationToken

4.7.1.7. サポートされる操作

AclAuthorizer はリソースでの操作を承認します。

以下の表で X の付いたフィールドは、各リソースでサポートされる操作を表します。

Expand
表4.1 リソースでサポートされる操作
 Topicsコンシューマーグループクラスター

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 など、二重ハイフンの標記が必要です。

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

add

Action

ACL ルールを追加します。

 

remove

Action

ACL ルールを削除します。

 

list

Action

ACL ルールをリスト表示します。

 

authorizer

Action

authorizer の完全修飾クラス名。

kafka.security.auth.AclAuthorizer

authorizer-properties

Configuration

初期化のために authorizer に渡されるキー/値のペア。

AclAuthorizer では、サンプル値は zookeeper.connect=zoo1.my-domain.com:2181 です。

 

bootstrap-server

リソース

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

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

command-config

リソース

管理クライアントに渡す設定プロパティーファイル。これは bootstrap-server パラメーターと共に使用されます。

 

cluster

リソース

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

 

topic

リソース

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

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

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

 

group

リソース

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

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

 

transactional-id

リソース

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

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

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

 

delegation-token

リソース

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

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

 

resource-pattern-type

Configuration

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

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

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

literal

allow-principal

プリンシパル

allow ACL ルールに追加されるプリンシパル。

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

 

deny-principal

プリンシパル

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

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

 

principal

プリンシパル

プリンシパルの ACL のリストを返すために list パラメーターと共に使用されるプリンシパル名。

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

 

allow-host

ホスト

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

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

--allow-principal が指定されている場合、デフォルトは * ですべてのホストを意味します。

deny-host

ホスト

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

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

--deny-principal が指定されている場合、デフォルトは * ですべてのホストを意味します。

操作 (operation)

操作

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

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

すべて

producer

ショートカット

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

 

consumer

ショートカット

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

 

idempotent

ショートカット

--producer パラメーターとの併用時に冪等性を有効にするショートカット。これにより、メッセージがパーティションに 1 度だけ配信されるようになります。

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

 

force

ショートカット

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

 

4.7.2. 認可の有効化

この手順では、Kafka ブローカーでの認可用に AclAuthorizer プラグインを有効にする方法を説明します。

前提条件

手順

  1. AclAuthorizer を使用するように、Kafka 設定ファイル /opt/kafka/config/server.properties を編集します。

    authorizer.class.name=kafka.security.auth.AclAuthorizer
    Copy to Clipboard Toggle word wrap
  2. Kafka ブローカーを (再) 起動します。

関連情報

4.7.3. ACL ルールの追加

AclAuthorizer は、ユーザーが実行できる/できない操作を記述するルールのセットを定義するアクセス制御リスト (ACL) を使用します。

この手順では、Kafka ブローカーで AclAuthorizer プラグインを使用する場合に、ACL ルールを追加する方法を説明します。

ルールは kafka-acls.sh ユーティリティーを使用して追加され、ZooKeeper に保存されます。

前提条件

手順

  1. --add オプションを指定して kafka-acls.sh を実行します。

    例:

    • MyConsumerGroup コンシューマーグループを使用して、user1 および user2myTopic からの読み取りを許可します。

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2
      
      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2
      
      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
      Copy to Clipboard Toggle word wrap
    • user1 が IP アドレスホスト 127.0.0.1 から myTopic を読むためのアクセスを拒否します。

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
      Copy to Clipboard Toggle word wrap
    • MyConsumerGroupmyTopic のコンシューマーとして user1 を追加します。

      bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --add --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
      Copy to Clipboard Toggle word wrap

関連情報

4.7.4. ACL ルールのリスト表示

この手順では、Kafka ブローカーで AclAuthorizer プラグインを使用する場合に、既存の ACL ルールをリスト表示する方法を説明します。

ルールは、kafka-acls.sh ユーティリティーを使用してリストされます。

前提条件

手順

  • --list オプションを指定して kafka-acls.sh を実行します。

    以下に例を示します。

    $ bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --list --topic myTopic
    
    Current ACLs for resource `Topic:myTopic`:
    
    User:user1 has Allow permission for operations: Read from hosts: *
    User:user2 has Allow permission for operations: Read from hosts: *
    User:user2 has Deny permission for operations: Read from hosts: 127.0.0.1
    User:user1 has Allow permission for operations: Describe from hosts: *
    User:user2 has Allow permission for operations: Describe from hosts: *
    User:user2 has Deny permission for operations: Describe from hosts: 127.0.0.1
    Copy to Clipboard Toggle word wrap

関連情報

4.7.5. ACL ルールの削除

この手順では、Kafka ブローカーで AclAuthorizer プラグインを使用する場合に、ACL ルールを削除する方法を説明します。

ルールは kafka-acls.sh ユーティリティーを使用して削除されます。

前提条件

手順

  • --remove オプションを指定して kafka-acls.sh を実行します。

    例:

  • MyConsumerGroup コンシューマーグループを使用して、user1 および user2myTopic からの読み取りを許可する ACL を削除します。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --topic myTopic --allow-principal User:user1 --allow-principal User:user2
    
    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --topic myTopic --allow-principal User:user1 --allow-principal User:user2
    
    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Read --operation Describe --group MyConsumerGroup --allow-principal User:user1 --allow-principal User:user2
    Copy to Clipboard Toggle word wrap
  • MyConsumerGroupmyTopic のコンシューマーとして user1 を追加する ACL を削除します。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --consumer --topic myTopic --group MyConsumerGroup --allow-principal User:user1
    Copy to Clipboard Toggle word wrap
  • user1 が IP アドレスホスト 127.0.0.1 から myTopic を読むためのアクセスを拒否する ACL を削除します。

    bin/kafka-acls.sh --authorizer-properties zookeeper.connect=zoo1.my-domain.com:2181 --remove --operation Describe --operation Read --topic myTopic --group MyConsumerGroup --deny-principal User:user1 --deny-host 127.0.0.1
    Copy to Clipboard Toggle word wrap

関連情報

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat