一元的な 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 に移行するには、次の手順に従います。

server.properties ファイルで、すべてのブローカーに対して confluent.authorizer.access.rule.providers=CONFLUENT, ZK_ACL が構成されていることを確認します（「前提条件」を参照）。
任意の 1 つのブローカーに confluent.authorizer.migrate.acls.from.zk=true を指定します（ACL を移行する MDS クラスターおよび Kafka クラスターが同じ場合は、MDS ライター以外のブローカーを選択します。MDS ライターブローカーは writerMemberId で識別できます。これは最新の metadata-service.log ログファイルに含まれています）。MDS 以外のブローカーが、ZooKeeper ACL の移行を実行するブローカーになります。次の手順で必要になるため、ブローカーの broker.id をメモしておきます。
手順 2 で選択したブローカーのローリング再起動を実行します。再起動すると、このブローカーは ZooKeeper ベースの ACL を MDS にコピーするとともに、移行中の ACL の更新をすべてリッスンします。この手順を完了したら、Kafka ベースの ACL を追加できます。これがすべてのブローカーに適用され、MDS に保存されます。
移行が完了したら（kafka.authorizer.log で完了を確認できます）、MDS に ACL が一元化されていることを検証します。
```
confluent iam acl list --kafka-cluster-id <kafka-cluster-id>
```
すべてのブローカーに対して confluent.authorizer.access.rule.providers=CONFLUENT を指定します。
手順 2 のブローカーに対して confluent.authorizer.migrate.acls.from.zk=false を指定します。
手順 2 のブローカーも含めて、クラスター内のすべてのブローカーのローリング再起動を実行します。手順 2 のブローカーは最後に再起動する必要があります。これにより、移行中に生じた ACL の更新を確実に反映できます。

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

一元的な ACL の使用¶

このセクションの例では、confluent iam rbac role-binding create を使用して ACL の作成、削除、リスト表示を行います。サポートされるオプションの詳細を確認するには、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 のみである点に注意してください。