Connect クラスター用の RBAC の構成¶
RBAC が有効な環境では、Connect クラスター用の service principal を作成する必要があります。Connect クラスターが Kafka クラスターやその他のリソースにアクセスできるように、service principal 内でロールバインディングを作成します。
- 前提条件:
- この手順を実行するユーザーには、Connect クラスターおよび Kafka クラスターで Connect service principal 用のロールバインディングを作成するためのアクセス許可が必要です。
- Kafka クラスターがインストールされ、実行されている、インストール済みの RBAC が有効な Confluent Platform 環境。
- Confluent CLI がインストールされていること。
- 組織用のプリンシパルの作成と変更を行うための認可。
以下の手順では、Kafka Connect 用の service principal を構成する方法を説明します。service principal の作成方法は、それぞれの組織と運用環境(オンプレミス、プライベートクラウド、パブリッククラウド)によって異なります。この手順ではその点については説明していません。
注釈
実際のクラスター ID を取得する方法については、「クラスターの識別子について」を参照してください。
次の Confluent CLI コマンドを入力して、
$CONNECT_USER
という名前のサンプルの service principal に、Connect クラスターに対するSecurityAdmin
のロールを付与します。サンプルのクラスター ID である Connect 用の$CONNECT_CLUSTER
および Kafka 用の$KAFKA_CLUSTER
は、このコマンドおよびこれ以降のすべてのコマンド例で使用します。confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role SecurityAdmin \ --kafka-cluster-id $KAFKA_CLUSTER \ --connect-cluster-id $CONNECT_CLUSTER
次のコマンドを入力して、Connect ワーカーが他のワーカーとの調整に使用するグループに対する
ResourceOwner
ロールを$CONNECT_USER
に付与します。confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:$CONNECT_CLUSTER \ --kafka-cluster-id $KAFKA_CLUSTER
次のコマンドを入力して、構成、ステータス、オフセット情報を保存するために Connect が使用する内部の Kafka トピックに対する
ResourceOwner
ロールを$CONNECT_USER
に付与します。この例では、内部構成トピック$CONFIGS_TOPIC
、内部オフセットトピック$OFFSETS_TOPIC
、およびステータストピック$STATUS_TOPIC
が使用されています。注釈
構成トピックの
config.storage.topic
、offset.storage.topic
、status.storage.topic
には、内部構成、オフセット構成、ステータス構成のデータが保存されます。これらは、Confluent Platform では、デフォルトでconnect-configs
、connect-offsets
、connect-status
に設定されます。confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$CONFIGS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER
confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$OFFSETS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER
confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$STATUS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER
重要
By default the Kafka worker uses the same settings and the same principal for reading and writing to the
_confluent-command
license topic that it uses to read and write to internal topics. For more information about Connect licensing, see Licensing Connectors.
Connect シークレットレジストリ を構成した場合は、さらに 2 つの手順を実行する必要があります。
次のコマンドを入力して、シークレットレジストリノードが他のノードとの調整に使用するグループに対する
ResourceOwner
ロールを$CONNECT_USER
に付与します。この例では、シークレットレジストリのグループ ID$SECRET_REGISTRY_GROUP
が使用されています。$SECRET_REGISTRY_GROUP
の実際の値が、Connect ワーカーのプロパティのconfig.providers.secret.param.secret.registry.group.id
の値と一致している必要があることに注意してください。この値が Connect ワーカーのプロパティで指定されていない場合、デフォルトでsecret-registry
が使用されます。confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Group:$SECRET_REGISTRY_GROUP \ --kafka-cluster-id $KAFKA_CLUSTER
次のコマンドを入力して、シークレットの保存に使用される Kafka トピックに対する
ResourceOwner
ロールを$CONNECT_USER
に付与します。この例では、Kafka シークレットトピック$SECRETS_TOPIC
が使用されています。$SECRETS_TOPIC
の実際の値が、Connect ワーカーのプロパティのconfig.providers.secret.param.kafkastore.topic
の値と一致している必要があることに注意してください。この値が Connect ワーカーのプロパティで指定されていない場合、デフォルトで_confluent-secrets
が使用されます。警告
バージョン 5.4 では、シークレットトピックのデフォルト値が
_secrets
から_confluent-secrets
に変更されています。シークレットレジストリクラスターでkafkastore.topic
プロパティが指定されていない場合は、既存のシークレットが損なわれないようにするため、5.4 にアップグレードする前に、明示的に_secrets
を設定します。confluent iam rolebinding create \ --principal User:$CONNECT_USER \ --role ResourceOwner \ --resource Topic:$SECRETS_TOPIC \ --kafka-cluster-id $KAFKA_CLUSTER