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 を取得する方法については、「クラスターの識別子について」を参照してください。

  1. 次の Confluent CLI コマンドを入力して、$CONNECT_USER という名前のサンプルの service principal に、Connect クラスターに対する SecurityAdmin のロールを付与します。サンプルのクラスター ID である Connect 用の $CONNECT_CLUSTER および Kafka 用の $KAFKA_CLUSTER は、このコマンドおよびこれ以降のすべてのコマンド例で使用します。

    confluent iam rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role SecurityAdmin \
    --kafka-cluster-id $KAFKA_CLUSTER \
    --connect-cluster-id $CONNECT_CLUSTER
    
  2. 次のコマンドを入力して、Connect ワーカーが他のワーカーとの調整に使用するグループに対する ResourceOwner ロールを $CONNECT_USER に付与します。

    confluent iam rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role ResourceOwner \
    --resource Group:$CONNECT_CLUSTER \
    --kafka-cluster-id $KAFKA_CLUSTER
    
  3. 次のコマンドを入力して、構成、ステータス、オフセット情報を保存するために Connect が使用する内部の Kafka トピックに対する ResourceOwner ロールを $CONNECT_USER に付与します。この例では、内部構成トピック $CONFIGS_TOPIC、内部オフセットトピック $OFFSETS_TOPIC、およびステータストピック $STATUS_TOPIC が使用されています。

    注釈

    構成トピックの config.storage.topicoffset.storage.topicstatus.storage.topic には、内部構成、オフセット構成、ステータス構成のデータが保存されます。これらは、Confluent Platform では、デフォルトで connect-configsconnect-offsetsconnect-status に設定されます。

    confluent iam rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role ResourceOwner \
    --resource Topic:$CONFIGS_TOPIC \
    --kafka-cluster-id $KAFKA_CLUSTER
    
    confluent iam rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role ResourceOwner \
    --resource Topic:$OFFSETS_TOPIC \
    --kafka-cluster-id $KAFKA_CLUSTER
    
    confluent iam rbac role-binding 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 つの手順を実行する必要があります。

  1. 次のコマンドを入力して、シークレットレジストリノードが他のノードとの調整に使用するグループに対する ResourceOwner ロールを $CONNECT_USER に付与します。この例では、シークレットレジストリのグループ ID $SECRET_REGISTRY_GROUP が使用されています。$SECRET_REGISTRY_GROUP の実際の値が、Connect ワーカーのプロパティの config.providers.secret.param.secret.registry.group.id の値と一致している必要があることに注意してください。この値が Connect ワーカーのプロパティで指定されていない場合、デフォルトで secret-registry が使用されます。

    confluent iam rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role ResourceOwner \
    --resource Group:$SECRET_REGISTRY_GROUP \
    --kafka-cluster-id $KAFKA_CLUSTER
    
  2. 次のコマンドを入力して、シークレットの保存に使用される 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 rbac role-binding create \
    --principal User:$CONNECT_USER \
    --role ResourceOwner \
    --resource Topic:$SECRETS_TOPIC \
    --kafka-cluster-id $KAFKA_CLUSTER