1. Home
  2. Confluent for Kubernetes
  3. Confluent Platform の構成
  4. Confluent for Kubernetes でのセキュリティの構成

Confluent for Kubernetes でのネットワーク暗号化の構成

このドキュメントでは、Confluent for Kubernetes （CFK）でネットワーク暗号化を構成する方法について説明します。Confluent Platform におけるセキュリティの概念については、「セキュリティ」を参照してください。

CFK では、Confluent コンポーネントによるネットワーク通信を保護するために、業界標準の暗号化プロトコルの 1 つであるトランスポート層セキュリティ（TLS: Transport Layer Security）がサポートされています。

TLS では、信頼できる接続の確立にキーと証明書を利用します。このセクションでは、Confluent Platform の TLS 暗号化の構成を準備するに当たってのキーと証明書の管理方法について説明します。

TLS 暗号化を有効にするために、CFK がサポートするメカニズムは次のとおりです。

証明書の自動生成

特定の認証機関を使用して CFK がサーバー証明書を自動生成します。

Confluent サービスへのすべてのアクセスおよび通信が Kubernetes ネットワーク内で行われる場合は、証明書の自動生成の使用を推奨します。

ユーザー指定の証明書

プライベートキー、パブリックキー、認証機関をユーザーが指定します。

外部から Kubernetes ドメインの Confluent サービスへのアクセスを有効にする必要がある場合は、ユーザー指定の証明書の使用を推奨します。

TLS 証明書の自動生成の構成

注釈

証明書の自動生成を使用した場合、Kubernetes ネットワークの内部トラフィックは暗号化されます。

ルート認証機関を、ca-pair-sslcerts という名前の Kubernetes シークレットとして指定します。認証機関のパブリックキーとプライベートキーを次の形式で指定します。

kubectl create secret tls ca-pair-sslcerts \
  --cert=/path/to/ca.pem \
  --key=/path/to/ca-key.pem

自動生成された証明書を使用するように各コンポーネントを構成します。

spec:
  tls:
    autoGeneratedCerts: true

必要なサーバー証明書が CFK によって作成され、Confluent コンポーネントが使用できるよう Kubernetes シークレットとして格納されます。

kubectl get secrets
NAME                             TYPE
...
zookeeper-generated-jks          kubernetes.io/tls
kafka-generated-jks              kubernetes.io/tls
...

生成されたサーバー証明書は、365 日後に有効期限が切れます。

証明書の自動生成を使用するチュートリアルシナリオについては、クイックスタートチュートリアル を参照してください。

TLS 証明書のユーザー指定の構成

TLS 証明書がユーザーによって指定されると、CFK は、指定されたファイルを受け取り、それに従って Confluent コンポーネントを構成します。

コンポーネントごとに、次の TLS 証明書情報を指定する必要があります。

  • あらゆる Confluent コンポーネントクラスターのサーバー証明書を発行するために使用される機関など、コンポーネントが信頼すべき認証機関。

    これらは、ピアツーピア通信（Kafka ブローカー間の通信など）と、コンポーネント間の通信（Connect ワーカーから Kafka への通信など）が機能するために必要です。

  • コンポーネントのサーバー証明書（パブリックキー）

  • コンポーネントのサーバーのプライベートキー

この TLS 証明書情報は、次の 2 つの形式のいずれかでユーザーが指定できます。

SAN の定義

サーバー証明書の SAN（Subject Alternative Name）リストが適切に定義され、Confluent コンポーネントがアクセスされるすべてのホスト名が記載されている必要があります。

  • 内部通信のネットワーク暗号化で TLS が有効にされている場合は、内部ネットワーク（<component>.<namespace>.svc.cluster.local）を SAN リストに追加します。
  • 外部ネットワーク通信を有効にする場合は、外部ドメイン名を SAN リストに追加します。

以下に、コンポーネントの証明書の SAN に追加する必要のある各 Confluent コンポーネントの、内部 SAN および外部 SAN を示します。これらの例では、デフォルトのコンポーネントプレフィックスを使用しています。

Kafka

  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local

    • たとえば、kafka.confluent.svc.cluster.local となります。

  • 内部アクセスの SAN: kafka-<x>.<customResourceName>.<namespace>.svc.cluster.local

    <x> はブローカーの順番を示し、0 から（ブローカー数 - 1）までの値になります。

    • たとえば、kafka-0.kafka.confluent.svc.cluster.local となります。
    • 範囲のドメイン指定にはワイルドカードが使用できます。たとえば、*.kafka.confluent.svc.cluster.local のように指定できます。

  • 外部ブートストラップドメインの SAN: <bootstrap_prefix>.my-external-domain

    • たとえば、kafka-bootstrap.acme.com となります。

  • 外部ブローカーの SAN: <broker_prefix><x>.my-external-domain

    • たとえば、b0.acme.com となります。
    • 範囲のドメイン指定にはワイルドカードが使用できます。たとえば、*.acme.com のように指定できます。
MDS

  • 内部アクセスの SAN: kafka-<x>.<customResourceName>.<namespace>.svc.cluster.local

    <x> はブローカーの順番を示し、0 から（ブローカー数 - 1）までの値になります。

    • たとえば、kafka-0.kafka.confluent.svc.cluster.local となります。

  • 外部ドメインの SAN: <mds_prefix>.my-external-domain

    • たとえば、mds.my-external-domain となります。
ZooKeeper

  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local

  • 内部アクセスの SAN: zookeeper-<x>.<customResourceName>.<namespace>.svc.cluster.local

    <x> は ZooKeeper サーバーの順番を示し、0 から（サーバー数 - 1）までの値になります。

    • たとえば、zookeeper-0.zookeeper.confluent.svc.cluster.local となります。

  • 外部アクセスドメインはありません

Schema Registry

  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local

  • 内部アクセスの SAN: schemaregistry-<x>.<customResourceName>.<namespace>. svc.cluster.local

    <x> は Schema Registry サーバーの順番を示し、0 から（サーバー数 - 1）までの値になります。

    • たとえば、schemaregistry-0.schemaregistry.confluent.svc.cluster.local となります。

  • 外部ドメインの SAN: <schemaregistry_prefix>.my-external-domain

REST Proxy

  • 内部アクセスの SAN: kafkarestproxy-<x>.<customResourceName>.<namespace>. svc.cluster.local

    <x> は REST Proxy サーバーの順番を示し、0 から（サーバー数 - 1）までの値になります。

    • たとえば、kafkarestproxy-0.kafkarestproxy.confluent.svc.cluster.local となります。

  • 外部ドメインの SAN: <kafkarestproxy_prefix>.my-external-domain

Connect

  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local

  • 内部の SAN: connect-<x>.<customResourceName>.<namespace>.svc.cluster.local

    <x> は Connect サーバーの順番を示し、0 から（サーバー数 - 1）までの値になります。

    • たとえば、connect-0.connect.confluent.svc.cluster.local となります。

  • 外部ドメインの SAN: <connect_prefix>.my-external-domain

ksqlDB

  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local

  • 内部アクセスの SAN: ksqldb-<x>.<customResourceName>.<namespace>.svc.cluster.local

    <x> は ksqlDB サーバーの順番を示し、0 から（サーバー数 - 1）までの値になります。

    • たとえば、ksqldb-0.ksqldb.confluent.svc.cluster.local となります。

  • 外部ドメインの SAN: <ksqldb_prefix>.my-external-domain

Control Center
  • 内部のブートストラップアクセスの SAN: <customResourceName>.<namespace>.svc.cluster.local
  • 内部アクセスの SAN: controlcenter-0.<customResourceName>.<namespace>.svc.cluster.local
    • たとえば、controlcenter-0.controlcenter.confluent.svc.cluster.local となります。
  • 外部ドメインの SAN: <controlcenter_prefix>.my-external-domain

適切な SAN 構成で証明書を作成する例については、『Create your own certificates』のチュートリアル を参照してください。

PEM 形式の TLS キーおよび証明書の提供

次のファイルを用意します。

  • ca.pem: 信頼する認証機関の、PEM エンコード形式のリストが含まれています。次の例のように、単純に上から下へと並べて、証明書のリストを作成します。

    -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

  • server.pem: PEM エンコード形式のサーバー証明書チェーン全体が含まれています。

  • server-key.pem: PEM エンコードされた、サーバー証明書のプライベートキーが含まれています。

次のキーで Kubernetes シークレットを作成します。

kubectl create secret generic kafka-tls \
--from-file=fullchain.pem=server.pem \
--from-file=cacerts.pem=ca.pem \
--from-file=privkey.pem=server-key.pem

また、次のキーで Kubernetes シークレットを作成する方法もあります。

kubectl create secret generic kafka-tls \
--from-file=tls.crt=server.pem \
--from-file=ca.crt=ca.pem \
--from-file=tls.key=server-key.pem

注: tls.crt、ca.crt、および tls.key キーは、証明書の管理に広く使われているオープンソースツール cert-manager によって作成されるシークレットに一般的に存在します。利便性のために、CFK は、この命名規則をサポートしていますが、想定されるファイルの内容と、Confluent Platform 内でのその使用方法は、*.pem キーを使用する場合と、*.crt および *.key キーを使用する場合のどちらでも同じです。

最後に、シークレットを使用するために、コンポーネントの CR を構成します。

spec:
  tls:
    secretRef: kafka-tls

Java キーストア形式の TLS キーおよび証明書の提供

次のファイルを指定します。

  • keystore.jks: コンポーネントのサーバーキーを含む、PKCS12 形式のキーストア。

  • truststore.jks: PKCS12 形式のトラストストアで、信頼する証明書を含んでいます。

  • jksPassword.txt: JKS のパスワードです。

    jksPassword=<password_for_jks> を使用して jksPassword.txt ファイルを作成します。

    echo -n "jksPassword=<password_for_jks>" > jksPassword.txt

次のキーで Kubernetes シークレットを作成します。

kubectl create secret generic kafka-tls \
--from-file=keystore.jks=keystore.jks \
--from-file=truststore.jks=truststore.jks \
--from-file=jksPassword.txt=jksPassword.txt

コンポーネントの CR で次のように構成します。

spec:
  tls:
    secretRef: kafka-tls