一元的な ACL を使用した認可

注釈

Apache Kafka® には、そのままで使える、プラグ可能なオーソライザーが実装されており、すべての ACL を格納するために Apache ZooKeeper™ が使用されます。MDS で role-based access control (RBAC) を使用していない場合は、ACL(ZooKeeper ベースの ACL とも呼ばれます)を使用した認可の詳細について、「ACL を使用した認可」を参照してください。

Confluent Platform の RBAC 対応の Kafka クラスターを使用している場合は、一元的な共有 MDS を使用して、複数の Kafka クラスターの ACL を管理できます。これにより、RBAC ロールバインディングを管理および保存する場合と同じ方法で ACL を構成および保存できます。

一元的な(MDS ベースの)ACL の使用を計画していて、移行するまで ZooKeeper ベースの ACL を引き続き使用する場合は、移行するまでの間、ACL の管理用に AdminClient API の使用を継続できます。

前提条件

一元的 MDS で ACL を作成して使用する前に、次の要件を満たす必要があります。

  • ZooKeeper ベースの ACL を使用していない 新しいクラスター で RBAC を構成する必要があります( confluent.authorizer.access.rule.providers=CONFLUENT を使用)。MDS ブローカープリンシパルを super.users または broker.users として構成する必要があります。

    注釈

    broker.users オプションは、ブローカー間のリスナーですべてのリソースへのアクセスを許可されているユーザーのプリンシパルを示すセミコロン区切りのリストです。super.users とは異なり、broker.users では、ブローカー間リスナーからのリクエストのみが許可されます。このオプションの主な用途は、一元的な ACL を使用して認可を構成しているときに MDS クラスターをブートストラップすることです。この構成の詳細については、「Confluent Server Authorizer の構成」を参照してください。

  • ZooKeeper ベースの ACL を使用している 既存のクラスター で RBAC を既に構成済みの場合は、ZooKeeper ベースの ACL を MDS の一元的なストレージに移行する必要があります。

ZooKeeper ベースの ACL を MDS に移行する

まず、実行中のクラスターで RBAC を有効にし、MDS ブローカーのプリンシパルを super.users または broker.users として構成する必要があります。

RBAC を有効にすると、Kafka クラスター内のブローカーは、ZooKeeper と MDS の両方から ACL を読み取ることができます。ACL の一貫性が失われることのないように、この移行が完了するまで MDS ベースの ACL を追加しないでください。

既存の ZooKeeper ベースの ACL を MDS に移行するには、次の手順に従います。

  1. server.properties ファイルで、すべてのブローカーに対して confluent.authorizer.access.rule.providers=CONFLUENT, ZK_ACL が構成されていることを確認します(「前提条件」を参照)。

  2. 任意の 1 つのブローカーに confluent.authorizer.migrate.acls.from.zk=true を指定します(ACL を移行する MDS クラスターおよび Kafka クラスターが同じ場合は、MDS ライター以外のブローカーを選択します。MDS ライターブローカーは writerMemberId で識別できます。これは最新の metadata-service.log ログファイルに含まれています)。MDS 以外のブローカーが、ZooKeeper ACL の移行を実行するブローカーになります。次の手順で必要になるため、ブローカーの broker.id をメモしておきます。

  3. 手順 2 で選択したブローカーの ローリング再起動 を実行します。再起動すると、このブローカーは ZooKeeper ベースの ACL を MDS にコピーするとともに、移行中の ACL の更新をすべてリッスンします。この手順を完了したら、Kafka ベースの ACL を追加できます。これがすべてのブローカーに適用され、MDS に保存されます。

  4. 移行が完了したら(kafka.authorizer.log で完了を確認できます)、MDS に ACL が一元化されていることを検証します。

    confluent iam acl list --kafka-cluster-id <kafka-cluster-id>
    
  5. すべてのブローカーに対して confluent.authorizer.access.rule.providers=CONFLUENT を指定します。

  6. 手順 2 のブローカーに対して confluent.authorizer.migrate.acls.from.zk=false を指定します。

  7. 手順 2 のブローカーも含めて、クラスター内のすべてのブローカーのローリング再起動を実行します。手順 2 のブローカーは最後に再起動する必要があります。これにより、移行中に生じた ACL の更新を確実に反映できます。

    この時点以降、AdminClient を使用して ZooKeeper をアップデートすることはできなくなります。また、ZooKeeper に直接追加された ACL はすべて無視されます。

一元的な ACL の使用

Examples in this section use confluent iam rolebinding create to create, delete or list ACLs. For detailed information about the supported options, run confluent iam acl --help.

ACL フォーマットとユーザー名のカスタマイズの詳細については、「ACL を使用した認可」を参照してください。

制限

一元的な ACL でサポートされる ACL は、クラスターごとに最大 1000 個です。

一元的な ACL の作成

この例では ACL を作成して、プリンシパル User:Bob に対し、指定された Kafka クラスターのトピック test-topic で、IP 198.51.100.0 からの読み取り操作を許可します。このためには、次のコマンドを実行します。

confluent iam acl create --allow --principal User:Bob --operation READ --host 198.51.100.0 --topic test-topic  --kafka-cluster-id  <kafka-cluster-id>

confluent iam acl では IPv6 アドレスがサポートされますが、IP 範囲とサブネットがサポートされないことに注意してください。

デフォルトでは、リソースにアクセスするための操作を許可する明示的な ACL を保持していないすべてのプリンシパルは拒否されます。まれなケースですが、一部を除くすべてのプリンシパルへのアクセスを許可する ACL が必要な場合は、--deny オプションを使用できます。たとえば、次のコマンドを使用すると、指定された Kafka クラスターの test-topic からの読み取りをすべてのユーザーに許可し、同じ Kafka クラスターで User:BadBob のみを拒否することができます。

confluent iam acl create --allow --principal User:'*' --operation READ --topic test-topic --kafka-cluster-id <kafka-cluster-id>
confluent iam acl create --deny --principal User:BadBob --operation READ --topic test-topic  --kafka-cluster-id <kafka-cluster-id>

上のように複数の ACL がユーザーに適用される場合、--allow オプションは常に --deny オプションによってオーバーライドされることに注意してください。

上の例では、リソースパターンオプションとして --topic [topic-name] を指定することで、トピックに対する ACL を作成しています。同様に、--cluster-scope を指定してクラスターに対する ACL を作成し、--group:[group-name] を指定してグループに対する ACL を作成できます。すべてのグループにアクセス許可を付与する場合は、次のコマンドのように --group='*' を指定します。

confluent iam acl create --allow --principal User:'*' --operation READ --topic test --group='*' --kafka-cluster-id <kafka-cluster-id>

プレフィックスを指定したリソースパターンで ACL を追加することもできます。たとえば、コマンドに --topic abc---prefix を含めると、名前が abc- で始まるすべてのリソースに対するアクセス許可を操作できます。次の例は、指定された Kafka クラスターにあり名前が test- で始まるトピックに、Jane というユーザーがアクセスするための ACL を追加する方法を示しています。このためには、次のようにオプションを指定して CLI を実行します。

confluent iam acl create --allow --principal User:Jane --prefix  --topic test- --kafka-cluster-id <kafka-cluster-id>

一元的な ACL の削除

上に示した最初の例で追加した ACL を削除するには、次のコマンドを実行します。

confluent iam acl delete --allow --principal User:Bob --operation READ --host 198.51.100.0 --topic test-topic  --kafka-cluster-id  <kafka-cluster-id>

プレフィックスを指定したパターンを使用して作成した ACL を削除する場合は、次のコマンドを実行します。

confluent iam acl create --allow --principal User:Jane --prefix  --topic test-topic --kafka-cluster-id <kafka-cluster-id>

一元的な ACL のリスト表示

confluent iam acl list コマンドとクラスター ID を使用すると、特定の Kafka クラスターの ACL をリスト表示できます。たとえば、指定された Kafka クラスターでプレフィックス test- を使用する test-topic の ACL をすべてリスト表示するには、次のコマンドを実行します。

confluent iam acl list --topic test-topic --prefix --kafka-cluster-id <kafka-cluster-id>

これによって返されるのは、指定どおりのプレフィックスパターンに追加された ACL のみである点に注意してください。