1. Home
2. Cloud
3. Cluster Linking

重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

Confluent Cloud における Cluster Linking のセキュリティ

Looking for Confluent Platform Cluster Linking docs? You are currently viewing Confluent Cloud documentation. If you are looking for Confluent Platform docs, check out Cluster Linking on Confluent Platform.

RBAC ロールと Kafka ACL のまとめ

クラスターリンクとミラートピックを作成および管理するには、送信先クラスターに ロースベースアクセス制御（RBAC） または Kafka ACL が必要です。

データとメタデータを読み取るには、送信元クラスターで、クラスターリンクそのものに特定の RBAC ロールまたは Kafka ACL が必要です。

RBAC ロールと Kafka ACL は相互に排他的ではありません。特定のユーザーやサービスアカウントは、それがセキュリティモデルにより適していれば RBAC ロールと Kafka ACL を混在させることができます。

プリンシパル	操作	クラスター	Kafka RBAC ロール	または	Kafka ACL
ユーザー、またはツール	クラスターリンクの作成 クラスターリンクの変更	送信先クラスター	CloudClusterAdmin、または EnvAdmin、または OrgAdmin	または	ALTER: クラスター
ユーザー、またはツール	ミラートピックの作成 ミラートピックの変更	送信先クラスター	CloudClusterAdmin、または EnvAdmin、または OrgAdmin	または	ALTER: クラスター、および ALTERCONFIGS: クラスター、および CREATE: トピック
クラスターリンク	ミラートピック	送信元クラスター	トピックに対する DeveloperRead、および トピックに対する DeveloperManage、または CloudClusterAdmin（非推奨）	または	READ: トピック、および DESCRIBE_CONFIGS: トピック
クラスターリンク	コンシューマーオフセットの同期	送信元クラスター	コンシューマーグループに対する DeveloperRead、または クラスターに対する Operator、または CloudClusterAdmin（非推奨）	または	DESCRIBE: トピック、および READ: ConsumerGroups、および DESCRIBE: ConsumerGroups
クラスターリンク	ACL の同期	送信元クラスター	クラスターに対する Operator、または クラスターに対する Operator、または CloudClusterAdmin（非推奨）	または	DESCRIBE: クラスター
クラスターリンク	Source-initiated cluster link to a Confluent Cloud cluster	送信先クラスター	CloudClusterAdmin	または	ALTER: クラスター

セキュリティモデル

Cluster Linking のセキュリティモデルでは、必要なアクセス許可と認証情報がライフサイクルのステップごとに分離されています。このパラダイムにより、多くのチームで、既に所有しているトピックに対してクラスターリンクの操作を使用することが可能になります。また、クラスターの所有者がクラスターリンクを介して別のチームや組織にデータを共有し、そのチームや組織に、共有可能な ミラー トピックへの READ アクセスだけを許可することもできます。

メリット

このモデルには次のようなメリットがあります。

• クラスターリンクとミラートピックを作成するために必要な アクセス制御リスト（ACL） を、送信先クラスターの所有者が管理できます。
• クラスターリンクとミラートピックで実行される操作については、「Confluent Cloud 監査ログ」を参照してください。
• ロールベースアクセス制御（RBAC） を使用して、送信先クラスターでユーザーまたはアプリケーションにアクセス許可を付与するロールを割り当てることができます。これらのロールについては、「ロールベースアクセス制御（RBAC） と Cluster Linking の使用」および「Confluent Cloud でのロールベースアクセス制御（RBAC）の使用」を参照してください。
• 送信元クラスターでは、クラスターリンクは独自の認証情報と ACL を使用します。他の Apache Kafka® コンシューマーと同じように、送信元クラスターへの READ アクセスを管理することができます。つまり、既存のセキュリティワークフローをクラスターリンクでも使用できます。
  • 送信元クラスターが Confluent Cloud クラスターの場合は、クラスターリンク用に サービスアカウント を作成するのが最良の方法です。クラスターリンクのサービスアカウントに、送信元クラスターの認証情報（API キーとシークレット）を発行します。
  • 送信元クラスターが Confluent Platform またはオープンソースの Apache Kafka クラスターの場合は、クラスターリンクで SASL/PLAIN または SASL/SCRAM を使用できます。Kerberos や OAuth を使用することはできません。
• クラスターリンク自体に必要となるのは、送信元クラスターでの読み取り ACL だけです。Confluent Cloud 上の送信先クラスターで必要となる ACL や認証情報はありません。このため、管理はシンプルです。
• チーム間でデータを共有する場合、送信元クラスターの所有者は、送信先クラスターにあるミラートピックへの READ アクセスをトピック単位で制限できます。

送信元クラスターと送信先クラスター間でデータを送信するとき、Cluster Linking は、トランスポート層セキュリティ（TLS）を使用して伝送中のデータを暗号化します。

また、Cluster Linking は、クライアント ACL のすべてまたは構成可能なサブセットを、送信元クラスターから送信先クラスターに同期するように構成することもできます。

構成要素

Cluster Linking の構成要素は次のとおりです。

• クラスターリンク。送信元クラスターを送信先クラスターに接続します。
• ミラートピック。送信先クラスターに存在し、送信元トピックに生成されたすべてのメッセージのコピーを受け取ります。
• 送信元トピック。送信元クラスターに存在する通常のトピックで、ミラートピックのデータのソースとなります。

Cluster Linking のライフサイクルとアクセス許可

Cluster Linking のライフサイクルでは、フェーズごとに異なるアクセス許可が必要です。各フェーズは次のようになります。

• ユーザーまたはクライアントアプリケーションが、クラスターリンクを作成します。
• ユーザーまたはクライアントアプリケーションが、クラスターリンクを使用してミラートピックを作成します。
• クラスターリンクが、送信元クラスターからトピックデータ、コンシューマーオフセット、および ACL を読み取ります。
• クラスターリンクが、送信先クラスターにトピックデータ、コンシューマーオフセット、および ACL を書き込みます。
• ユーザーまたはクライアントアプリケーションが、ミラートピックを変更、昇格、または削除します。
• ユーザーまたはクライアントアプリケーションが、クラスターリンクを変更または削除します。

クラスターリンクの作成または変更

クラスターリンクを作成または変更するには、ユーザーが サービスアカウント または Confluent Cloud ユーザーアカウント によって認証され、指定のリソースで ロールベースのアクセス許可 が認可されている必要があります。

ユーザーが Confluent Cloud ユーザーアカウントによって認証される場合、クラスターリンクの作成、列挙、表示、変更が認可されるためには、送信先クラスターで ClusterAdmin、EnvAdmin、または OrgAdmin の RBAC ロールが割り当てられている必要があります。

ユーザーまたはクライアントアプリケーションがサービスアカウントによって認証される場合は、そのサービスアカウントに、送信先クラスターでの ALTER を許可する ACL が必要です。送信先クラスターに存在するクラスターリンクの一覧を表示するには、サービスアカウントに、送信先クラスターでの DESCRIBE を許可する ACL が必要です。

クラスターリンクを作成するときは、送信元クラスターへの認証に必要な情報を提供する必要があります。そのためのアクセス許可については以下で説明します。

ミラートピックの作成または変更

クラスターリンクを作成または変更するには、ユーザーがサービスアカウントまたは Confluent Cloud ユーザーアカウントで認証され、認可されている必要があります。

ユーザーが Confluent Cloud ユーザーアカウントによって認証される場合、ミラートピックの作成や変更が認可されるためには、送信先クラスターで ClusterAdmin、EnvAdmin、または OrgAdmin の RBAC ロールが割り当てられている必要があります。

ユーザーまたはクライアントアプリケーションがサービスアカウントによって認証される場合は、送信先クラスターで、そのサービスアカウントに次の ACL が付与されている必要があります。

• 送信先クラスターの変更（ALTER）を許可する ACL。
• 送信先クラスターの構成の変更（ALTERCONFIGS）を許可する ACL。
• ミラートピックの作成（CREATE）を許可する ACL。この ACL では、すべてのトピックの作成を許可することも、トピック名で限定することもできます。

ミラートピックの一覧表示と詳細表示に必要な ACL

list mirrors は、クラスターまたはクラスターリンクのミラートピックを一覧表示するコマンドです。このコマンドを呼び出すには、Cluster Linking 用の Confluent Cloud API を通じて `REST`: `GET /kafka/v3/clusters/<cluster-id>/links/<link-name>/mirrors` を実行するか、統合 Confluent CLI から confluent kafka mirror list を実行します。

describe mirror は、特定のミラートピックに関する情報を取得するコマンドです。このコマンドを呼び出すには、Confluent Cloud API を通じて `REST`: `GET /kafka/v3/clusters/<cluster-id>/links/<link-name>/mirrors/<mirror-topic>` を実行するか、Confluent CLI から confluent kafka mirror describe <mirror-topic> を実行します。

ミラートピックの一覧表示と詳細表示には、次のいずれかの ACL が必要です。

• クラスターリソースの DESCRIBE ACL。クラスター上のすべてのトピックに対して、一覧表示と詳細表示の両方を実行できます。
• 特定のトピックの DESCRIBE ACL。特定のトピックについてのみ、一覧表示と詳細表示の両方を実行できます。

クラスターリンクが送信元クラスターから読み取るためのアクセス許可

クラスターリンクは、そのクラスターリンク上にあるすべてのミラートピックについて、対応する送信元トピックからトピックデータを読み取ります。さらに、コンシューマーオフセットまたは ACL を同期するように構成されている場合は、送信元クラスターからも読み取ります。この読み取りを可能にするには、クラスターリンクを送信元クラスターで認証し、必要なアクションの実行に対する認可を受ける必要があります。

注釈

Confluent Cloud の ACL の同期は、同じ Confluent Cloud 組織にある 2 つの Confluent Cloud クラスターの間でのみ実行可能です。詳細については、「ACL の同期」を参照してください。

Confluent Cloud 送信元クラスターでのクラスターリンクの認証と認可

送信元クラスターが Confluent Cloud クラスターの場合は、クラスターリンクに以下が必要です。

• クラスターリンクを表す サービスアカウント
• 送信元クラスターで使用する API キーとシークレット

セキュリティ上のベストプラクティスとして、各クラスターリンクを表すサービスアカウントを作成することをお勧めします。以下に例を示します。

confluent iam service-account create <name> --description "For my first cluster link"

サービスアカウントは、クラスターリンクが適切なデータを読み取ることができるように、送信元クラスターの ACL に関連付けられます。

次に、送信元クラスターでサービスアカウントの API キーとシークレットを作成します。以下に例を示します。

confluent api-key create --resource <source-cluster-id> --service-account <service-account-id>

クラスターリンクの作成時には、この API キーとシークレットを指定します。これらは、クラスターリンクが送信元クラスターに認証するときに使用されます。

クラスターリンクには、共有サービスアカウントまたはユーザーの Confluent Cloud アカウントからの API キーを渡すこともできます。ただしこれは、送信元クラスターに機密データが含まれている場合や本稼働環境での使用には推奨されません。

データとメタデータの読み取りが認可されるためには、送信元クラスターで、クラスターリンクのサービスアカウントに以下の ACL が付与されている必要があります。

• ミラーリングするすべてのトピック（"送信元トピック"）に対して、READ および DESCRIBE_CONFIGS の許可が必要です。これにより、クラスターリンクで、送信元トピックからミラートピックにトピックデータをミラーリングすることが可能になります。* を渡すと、すべてのトピックの読み取りがリンクに許可されます。または、名前がプレフィックスに一致する特定のトピックや、特定のトピック名を対象にすることもできます。以下の CLI コマンドの例では、すべてのトピックに対する READ アクセスをクラスターリンクに付与します。

  confluent kafka acl create --allow --service-account <service-account-id> --operation READ --operation DESCRIBE_CONFIGS --topic "*" --cluster <source-cluster-id>
  

• ACL を同期するには（省略可能）、クラスターリンクに、送信元クラスターに対する DESCRIBE のアクセス許可が必要です。これらのアクセス許可を指定する方法の例を以下に示します。

  confluent kafka acl create --allow --service-account <service-account-id> --operation DESCRIBE --cluster-scope --cluster <source-cluster-id>
  

• コンシューマーグループのオフセットを同期するには（省略可能）、クラスターリンクに、送信元トピックに対する DESCRIBE と、送信元クラスターのコンシューマーグループに対する READ および DESCRIBE のアクセス許可が必要です。これらのアクセス許可を指定する方法の例を以下に示します。それぞれのアクセス許可は別々のコマンドで指定する必要があります。

  confluent kafka acl create --allow --service-account <service-account-id> --operation DESCRIBE --topic "*" --cluster <source-cluster-id>
  

  confluent kafka acl create --allow --service-account <service-account-id> --operation READ --operation DESCRIBE --consumer-group "*" --cluster <source-cluster-id>
  

• If both prefixing and auto-create mirror topics are enabled, DESCRIBE:CLUSTER is required on the source cluster.

送信元クラスターでクラスターリンクに必要な ACL の要約

機能	送信元クラスターで必要な ACL
送信元トピックからミラートピックへのデータのミラーリング	送信元トピックに対する READ および DESCRIBE_CONFIGS
送信元クラスターから送信先クラスターへの ACL の同期	送信元クラスターでの DESCRIBE
送信元トピックからミラートピックへのコンシューマーグループのオフセットの同期	送信元トピックに対する DESCRIBE と、送信元クラスターでのコンシューマーグループに対する READ および DESCRIBE
Enable both prefixing and auto-create mirror topics	送信元クラスターでの DESCRIBE

クラスターリンクへの API キーとシークレットの提供

テストまたは開発の目的では、簡易的な方法として、Confluent CLI で API キーとシークレットを使用してクラスターリンクを作成することができます。

confluent kafka link create <link_name> --source-api-key <api-key> --source-api-secret <api-secret>

この CLI による簡易的な方法は、ターミナルの履歴から API キーとシークレットが取得される可能性があるため、本稼働環境のクラスターリンクには推奨されません。

代わりに、次の 3 つのプロパティをクラスターリンクの構成に渡します。

sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='<api-key>' password='<api-secret>';
security.protocol=SASL_SSL
sasl.mechanism=PLAIN

CLI を使用してクラスターリンクを作成する場合は、これらの 3 行を（リンクに構成するその他のプロパティとともに）構成ファイルに記述し、そのファイル名を --config-file フラグでコマンドに渡すことができます。以下に例を示します。

confluent kafka link create <link_name> --config-file <path/to/file.config> ...

REST API 呼び出しを介してコマンドを作成する場合は、次のように 3 つのプロパティを構成の配列に追加できます。

{
  "source_cluster_id": "<source cluster's ID>",
  "configs": [
    {
      "name": "security.protocol",
      "value": "SASL_SSL"
    },
    {
      "name": "sasl.mechanism",
      "value": "PLAIN"
    },
    {
      "name": "sasl.jaas.config",
      "value": "org.apache.kafka.common.security.plain.PlainLoginModule required username='<api-key>' password='<api-secret>';"
    },
    ...
  ],
  ...
}

注釈

リンクに格納されたセキュリティ認証情報は暗号化され、ユーザーが取得することはできません。クラスターリンクを照会して API キーまたはシークレットを取得する方法はありません。

クラスターリンクのセキュリティ認証情報の変更またはローテーション

クラスターリンクのセキュリティ認証情報を変更（または "ローテーション"）する必要がある場合は、リンクの sasl.jaas.config プロパティを新しい API キーとシークレットでアップデートします。たとえば、new-creds.config という新しいファイルを作成し、アップデートした API キーとシークレットを次のように指定します。

# new-creds.config has this:
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username='<api-key>' password='<api-secret>';

次に、以下のコマンドを実行して、クラスターリンクで new-creds.config の新しい認証情報を使用するように指定します。

confluent kafka link update <link-name> --config-file new-creds.config

注意

送信元クラスターでデータを読み取るための認可がクラスターリンクから失われると、ミラーリングされたトピックは永続的なエラー状態になります。

送信元データを読み取るためのクラスターリンクの ACL が取り消されると、そのミラートピックは永続的に FAILED ステートになります。ミラートピックは送信元クラスターからデータをミラーリングしなくなり、後でクラスターリンクの認可が復元されたとしても、ミラーリングは再開されません。FAILED ステートのミラートピックへのミラーリングを復元するには、トピックを削除して再作成する必要があります。

送信先クラスターへの書き込み

Confluent Cloud では、送信先クラスターにデータを書き込むためにクラスターリンクに必要とされる追加のアクセス許可はありません。送信先クラスターに配置されているため、適切なアクセス許可が既に設定されています。

Transport Layer Security (TLS)

2 つの Confluent Cloud クラスター間を接続するクラスターリンクの場合、伝送中のデータは一方向の TLS V1.2 を使用して暗号化されます（Java コミュニティでは一方向 SSL と呼ばれます）。

Confluent Platform または Apache Kafka クラスターから Confluent Cloud クラスターへのクラスターリンクの場合、伝送中のデータは一方向の TLS を使用する必要があります（Java コミュニティでは一方向 SSL と呼ばれます）。デフォルトは、両方のクラスターで有効になっている最新バージョンの TLS です。Apache Kafka では、TLS 1.2 および 1.3 がデフォルトで有効になります。

古いバージョンの SSL を有効にすることもできますが、セキュリティに関する既知の脆弱性があるため推奨されません。

Mutual TLS (mTLS)

Cluster Linking can use mTLS (two-way verification) for some, but not all, data exchanges:

• Confluent Cloud to Confluent Cloud does not use mTLS; it uses TLS and SASL as described above in Transport Layer Security (TLS).
• Data coming into Confluent Cloud from OSS Kafka can be configured to use mTLS
• Data coming into Confluent Cloud from Confluent Platform can be configured to use either mTLS or source-initiated cluster links with TLS+SASL. mTLS cannot be used with source-initiated cluster links.

To learn more about PEM files and possible configurations, see the Apache Kafka KIP that introduced PEM file support.

When you need to rotate your certificates, you can update the cluster link with new keystore and truststore information. As an example, the following configuration properties would be added to the cluster link’s configuration:

security.protocol=SSL
ssl.keystore.type=PEM
ssl.keystore.certificate.chain=-----BEGIN CERTIFICATE-----\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
...
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXx\
-----END CERTIFICATE-----
ssl.keystore.key=-----BEGIN ENCRYPTED PRIVATE KEY-----\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
...
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxX\
-----END ENCRYPTED PRIVATE KEY-----
ssl.key.password=<REDACTED>
ssl.truststore.type=PEM
ssl.truststore.certificates=-----BEGIN CERTIFICATE-----\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
...
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX\
xXxXxXxXxXxXx\
-----END CERTIFICATE-----

Public Internet Exposure

Unless otherwise noted, Cluster Linking between two clusters on Confluent Cloud uses public IP addresses and public DNS. However, this does not necessarily mean that the cluster linked data goes over the public internet:

• Traffic between two clusters that are both on Amazon Web Services (AWS) always stays on AWS and never goes to the public internet. Per the AWS documentation: "When using public IP addresses, all communication between instances and services hosted in AWS use AWS's private network."
• Traffic between two clusters that are both on Microsoft Azure always stays on Azure and never goes to the public internet. Per the Azure documentation: "If the destination address is for one of Azure's services, Azure routes the traffic directly to the service over Azure's backbone network, rather than routing the traffic to the Internet. Traffic between Azure services doesn't traverse the Internet."
• All traffic is encrypted in transit. See Transport Layer Security (TLS).
• Cluster Linking between clusters on two different cloud service providers or with a location not on a cloud service provider may cause traffic to route through the public internet.

注釈

Traffic between a non Confluent Cloud cluster and a Confluent Cloud cluster might not use public IP addresses and/or public DNS.

実践的な例

さまざまな Cluster Linking デプロイでセキュリティをモデル化する実践的な例については、次のユースケースチュートリアルを参照してください。

• データ共有
• ディザスターリカバリとフェイルオーバー

監査ログ

ユーザーまたはアプリケーションがクラスターリンクやミラートピックを作成または削除しようとするたびに、Confluent Cloud 監査ログ に認証イベントと認可イベントが作成されます。これにより、Confluent Cloud 全体にわたる Cluster Linking のアクセスとアクティビティをモニタリングできます。

ロールベースアクセス制御（RBAC） と Cluster Linking の使用

以下に、Confluent Cloud RBAC による Cluster Linking の使用法の簡単なデモに続いて、さまざまなリソースに必要なロールのサマリーを示します。

デモ

この短いビデオでは、RBAC を有効にした複数のクラスター間でクラスターリンクをセットアップする方法と、異なる所有者のクラスター間でトピックデータを使用可能にする方法を説明しています。

この例では、Webstore クラスターの所有者が Logistics クラスター所有者にプレフィックスが public であるすべてのトピック（注文、クリック回数、製品データなど）に対するロールベースアクセスを付与しています。

Logistics 所有者は Logistics クラスターの Webstore トピックを、それらをネイティブであるかのようにミラーリングし、それを外部のストリーミングデータで視覚化できます。

Confluent Cloud RBAC ロール

Confluent Cloud でセキュアな Cluster Linking を有効にするには、このセクションで説明したように、RBAC ロールをプリンシパルに付与するか、または 特定の ACL を付与する（前出の 参照）必要があります。

クラスターリンクを作成するには、以下の RBAC ロールが少なくとも 1 つ必要です。

• クラスターに対する ResourceOwner
• クラスターに対する CloudClusterAdmin
• クラスターの環境に対する EnvironmentAdmin
• クラスターの組織に対する OrganizationAdmin

Cluster Link サービスアカウントには、以下の Confluent Cloud RBAC ロールセットが少なくとも 1 つ必要です。

• （推奨）ミラーリングする送信元クラスタートピックに対する DeveloperRead と DeveloperManage
• （本稼働環境には非推奨）: クラスターリンクを作成するための上記ロールのいずれか

ちなみに

Cluster Link では送信先クラスターでのロールを必要としません。上記のロールは送信元クラスターのみに適用されます。

ACL とコンシューマーオフセットの同期

ACL を同期するには、クラスターリンクに以下のロールが必要です。

• クラスターに対する Operator

コンシューマーオフセットを同期するには、クラスターリンクに以下のいずれかのロールが必要です。

• クラスターに対する Operator、または
• コンシューマーグループに対する DeveloperRead

おすすめの関連情報

• アカウントとアクセス権の管理
• サービスアカウント
• ACL のコンセプト