実行中のクラスターでの RBAC の有効化

注釈

このセクションは、セキュリティを有効にしたクラスターがあるという前提に基づいています。PLAINTEXT クラスターから移行する場合、セキュリティを有効にする方法の詳細については、「実行中クラスターへのセキュリティの追加」を参照してください。

ローリング再起動を使用すると、クラスターを使用しているアプリケーションを中断することなく、実行中のクラスターで RBAC を有効にできます。これは段階的に実行します。別の新しい メタデータ クラスターを構成する場合は、「Metadata Service (MDS) の構成」の手順に従って、メタデータクラスターを起動してから他のクラスターを移行します。次の手順を使用し、既存のクラスターの 1 つを変換して Metadata Service (MDS) を実行することもできます。

  1. ブローカーにリスナーが 1 つしかない場合は、ブローカー間通信用に別のポートを開き、ローリング再起動を実行します。
  2. 手順 1 でリスナーが追加された場合は、ブローカー間通信用の新しいリスナーを使用して、別のローリング再起動を実行します。
  3. ブローカーで現在オーソライザーを使用していない場合は、ブローカープリンシパルとすべてのアプリケーションのユーザープリンシパルを対象とした ACL を作成します。この手順では、ブローカーを再始動せずに ACL を追加できます。
  4. RBAC と MDS を有効にします。Confluent Platform コンポーネントを使用する場合は、トークンベースの認証用に追加のポートを開きます。アップデートされた構成でローリング再起動を実行します。

メタデータクラスター内のすべてのブローカーが起動したら、他のクラスターおよび他の Confluent Platform コンポーネントで RBAC を有効化できます。これらのアップデートは任意の順序で実行できますが、各コンポーネントで RBAC を有効にする前に、関連する RBAC ロールバインディングを構成する必要があります。ブローカーでは、既存の ACL を引き続き使用できます。

  1. ローリング再起動を使用して、他のクラスター内のブローカー用に RBAC を構成します。ブローカーでまだオーソライザーが使用されていない場合は、クラスターを再始動する前に、ブローカーリソースの ACL またはロールバインディングをクラスターごとに作成します。既存の ACL は引き続き使用されます。
  2. 他のコンポーネントのリソースの RBAC ロールバインディングを構成します。
  3. すべての Confluent Platform コンポーネントで RBAC を有効にします。

セキュリティプロトコルの構成の詳細については、プロトコルに関する以下のセクションを参照してください。

実行中のクラスターでの RBAC と Metadata Service (MDS) の有効化

たとえば、SASL/SCRAM-SHA-256 を使用して単一のリスナーをもつクラスターを実行している場合に、このクラスターで RBAC と MDS を有効にするには、以下の手順に従うことで、クラスターを使用するアプリケーションを中断せずに、段階的にアップデートを実行できます。このセクションの例では、次のリスナー構成を使用してブローカーが実行されていることを前提としています。

listeners=SASL_PLAINTEXT://:9092
advertised.listeners=SASL_PLAINTEXT://localhost:9092
security.inter.broker.protocol=SASL_PLAINTEXT
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.sasl_plaintext.scram-sha-256.sasl.jaas.config= \
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" password="kafka-secret";

ブローカー間通信用に別のリスナーを開く

MDS を実行するブローカーでは、(ロールベースアクセス制御に依存している可能性のある)他のクライアントリスナーと共有されていない、ブローカー間通信用のリスナーが別途必要になります。既に独立したリスナーでブローカー間通信が構成されている場合は、この手順をスキップできます。それ以外の場合は、既存のリスナーと同じ構成で別のリスナーを作成します。この手順では、既存のリスナーとともに、ブローカー間リスナーとしてリスナーを追加します。以下の例では、わかりやすくするために既存のリスナーの名前を変更しています。

listeners=EXTERNAL://:9092,INTERNAL://:9093
advertised.listeners=EXTERNAL://localhost:9092,INTERNAL://localhost:9093
listener.security.protocol.map=EXTERNAL:SASL_PLAINTEXT,INTERNAL:SASL_PLAINTEXT
inter.broker.listener.name=EXTERNAL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256
listener.name.external.sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.internal.sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.external.scram-sha-256.sasl.jaas.config= \
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" password="kafka-secret";
listener.name.internal.scram-sha-256.sasl.jaas.config= \
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" password="kafka-secret";

注釈

既存のクラスターを変更して RBAC を有効にする場合、または RBAC の認可メカニズムを変更する場合は、リスナー名は小文字にする必要があります。前の例の listener.name.<lowercase-listener-name>.sasl.enabled.mechanisms=SCRAM-SHA-256 は、このルールに従った形式です。

ローリング再起動を使用して、すべてのブローカーを段階的にアップデートします。

ブローカー間通信用の新しいリスナーへの切り替え

新しい内部リスナーがすべてのブローカーに追加された後、もう一度段階的なアップデートを実行して、ブローカー間通信を新しいリスナーに切り替えます。

inter.broker.listener.name=INTERNAL
listener.name.external.scram-sha-256.sasl.jaas.config= \
 org.apache.kafka.common.security.scram.ScramLoginModule required;

ACL の作成

ブローカーにオーソライザーが構成されていない場合は、ブローカープリンシパルと、クラスターを使用する他のアプリケーションで使用されるプリンシパルを対象として、まず ACL を構成する必要があります。そうしないと、RBAC が有効になったときにアクセスが拒否されます。既に SimpleAclAuthorizer または LDAP Authorizer を使用している場合は、既存の ACL が適用されるため、追加の ACL は必要ありません。オーソライザーを使用していないブローカーの場合は、「ACL を使用した認可」で説明されているように kafka-acls コマンドを使用して、ZooKeeper でブローカーリソース用の ACL を直接作成できます。この手順でブローカーを再始動する必要はありません。

RBAC と Metadata Service (MDS) の有効化

ブローカーを RBAC に対応させる準備は整いました。各ブローカーについて構成のアップデートを実行し、ローリング再起動を使用してすべてのブローカーを段階的にアップデートします。

Confluent Server Authorizer を使用できるようにブローカーを構成します。既存の ACL を確実に適用するには、ACL プロバイダーを RBAC とともに保持する必要があります。他のクラスターのロールバインディングを作成できるように、メタデータクラスター内のブローカー用に super.users で 1 つ以上のプリンシパルを構成します。この例では、ユーザー admin に、任意のクラスターのロールバインディングを作成するためのアクセス権限が付与されています。

authorizer.class.name=io.confluent.kafka.security.authorizer.ConfluentServerAuthorizer
confluent.authorizer.access.rule.providers=ZK_ACL,CONFLUENT
super.users=User:admin

Metadata Service (MDS) の構成」の指示に従って、MDS 用のキーペアを作成します。ブローカーで MDS を構成します。キーファイルへのパスは、セットアップに応じてアップデートする必要があります。

confluent.metadata.server.listeners=http://0.0.0.0:8090
confluent.metadata.server.advertised.listeners=http://localhost:8090
confluent.metadata.server.authentication.method=BEARER
confluent.metadata.server.token.key.path=<path-to-token-key-pair.pem>

他の Confluent Platform コンポーネントを使用する場合は、新しいリスナーを作成して、MDS を使用したトークンベースの認証を有効にします。

listeners=EXTERNAL://:9092,INTERNAL://:9093,TOKEN://:9094
advertised.listeners=EXTERNAL://localhost:9092,INTERNAL://localhost:9093,TOKEN://localhost:9094
listener.security.protocol.map=EXTERNAL:SASL_PLAINTEXT,INTERNAL:SASL_PLAINTEXT,TOKEN:SASL_PLAINTEXT
listener.name.token.sasl.enabled.mechanisms=OAUTHBEARER
listener.name.token.oauthbearer.sasl.jaas.config= \
  org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  publicKeyPath="/path/to/publickey.pem";
listener.name.token.oauthbearer.sasl.login.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerServerLoginCallbackHandler
listener.name.token.oauthbearer.sasl.server.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerValidatorCallbackHandler

いずれかのクラスターで LDAP グループベースの認可 を使用している場合は、MDS を実行するブローカー用に LDAP を構成 する必要があります。すべての LDAP 構成で、プレフィックス ldap.authorizer.ldap. に置き換えます。以下に例を示します。

ldap.java.naming.provider.url=ldap://LDAPSERVER.EXAMPLE.COM:3268/DC=EXAMPLE,DC=COM

他の Confluent Platform コンポーネントで RBAC を有効にする場合は、LDAP サーバーと一致する LDAP 構成で MDS を実行するブローカーを構成して、LDAP を使用した一元的な認証を有効にする必要があります。詳細については、「LDAP 認証の構成」を参照してください。

メタデータクラスターのブローカーが 3 つ未満の場合は、メタデータトピックのレプリケーション係数を調整します。以下に例を示します。

confluent.metadata.topic.replication.factor=2
confluent.license.replication.factor=2

他のクラスター用の RBAC の構成

メタデータクラスター内のすべてのブローカーを起動したら、他のすべてのクラスター内のブローカー用に RBAC を有効化できます。RBAC が有効になったときにアクセスが拒否されないように、ブローカーを再始動する前に必要に応じて ACL を作成 してください。既存のアプリケーションを中断せずに RBAC を有効にするには、ローリング再起動を使用してすべてのブローカーを段階的にアップデートします。

authorizer.class.name=io.confluent.kafka.security.authorizer.ConfluentServerAuthorizer
confluent.authorizer.access.rule.providers=ZK_ACL,CONFLUENT
confluent.metadata.bootstrap.servers=localhost:9093
confluent.metadata.security.protocol=SASL_PLAINTEXT
confluent.metadata.sasl.mechanism=SCRAM-SHA-256
confluent.metadata.sasl.jaas.config= \
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" password="kafka-secret";

他の Confluent Platform コンポーネントを使用する場合は、新しいリスナーを作成して、これらのコンポーネントからの接続に使用するトークンベースの認証を有効にします。既存のリスナーを保持し、新しいトークンベースのリスナーを追加します。この例では、現在ポート 9092 にリスナーが 1 つあると想定しています。

listeners=EXTERNAL://:9092,TOKEN://:9094
advertised.listeners=EXTERNAL://localhost:9092,TOKEN://localhost:9094
listener.security.protocol.map=EXTERNAL:SASL_PLAINTEXT,TOKEN:SASL_PLAINTEXT
inter.broker.listener.name=EXTERNAL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256

listener.name.external.sasl.enabled.mechanisms=SCRAM-SHA-256
listener.name.external.scram-sha-256.sasl.jaas.config= \
  org.apache.kafka.common.security.scram.ScramLoginModule required \
  username="kafka" password="kafka-secret";

listener.name.token.sasl.enabled.mechanisms=OAUTHBEARER
listener.name.token.oauthbearer.sasl.jaas.config= \
  org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required \
  publicKeyPath="/path/to/publickey.pem";
listener.name.token.oauthbearer.sasl.login.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerServerLoginCallbackHandler
listener.name.token.oauthbearer.sasl.server.callback.handler.class=io.confluent.kafka.server.plugins.auth.token.TokenBearerValidatorCallbackHandler

注釈

既存のクラスターを変更して RBAC を有効にする場合、または RBAC の認可メカニズムを変更する場合は、リスナー名は小文字にする必要があります。前の例の listener.name.<lowercase-listener-name>.sasl.enabled.mechanisms=SCRAM-SHA-256 は、このルールに従った形式です。

RBAC バインディングの構成

すべてのクラスター内のブローカーでは引き続き ACL が使用されるため、RBAC を使用するためのアップグレード中およびアップグレード後にもクラスターへのセキュアなアクセスを確保できます。メタデータクラスターを準備できたら、ロールバインディングを作成して ACL を置き換えた後、必要に応じて ACL を削除できます。MDS を実行するブローカーのプリンシパルについては、ACL を使用してアクセスを許可するか、super.users として構成する必要があります。

重要

グループロールバインディングに指定するユーザー ID では大文字と小文字が区別され、AD レコードでの指定と一致する必要があります。スーパーユーザーとしてログインするときは、ログイン ID の大文字と小文字も区別され、ロールバインディング内のユーザー ID の指定と一致する必要があることにも注意してください。

CLI を使用すると、ブローカーリソースおよびその他の Confluent Platform コンポーネントリソースのロールバインディングを作成できます。MDS クラスターの super.users で構成したいずれかのプリンシパルの認証情報を使用して、クラスターごとに 1 つ以上の UserAdmin ロールバインディングを作成します。クラスターの UserAdmin ロールが付与されているユーザーは、MDS スーパーユーザーに依存することなく、そのクラスターのロールバインディングを管理できます。MDS を実行するブローカーで静的に構成する super.users は、新しいクラスターのブートストラップを行うための少数のプリンシパルに制限する必要があります。

Confluent Platform の他のコンポーネントで RBAC を有効にする前に、コンポーネントの再起動時にアクセスが拒否されないように、コンポーネントに関連するロールバインディングを構成しておく必要があります。

RBAC を使用する Confluent Platform コンポーネントの再起動

これで、すべての Confluent Platform コンポーネントに対して RBAC を有効にできます。順番は任意です。コンポーネントで RBAC を有効にするには、各コンポーネントに関する以下のセクションを参照してください。