Confluent Operator での認証と暗号化の構成¶

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

Operator でサポートされている暗号化と認証の方式は以下のとおりです。

プレーンテキスト（暗号化なし）、SASL PLAIN 認証（デフォルト）
TLS 暗号化ネットワークトラフィック、SASL PLAIN 認証
TLS 暗号化トラフィック、認証なし
TLS 暗号化トラフィック、mTLS 認証

参考

推奨される 2 つのセキュアな本稼働環境セットアップを実現するデプロイテンプレートを用意しました。これらのテンプレートを入手してご利用の環境と証明書情報に追加し、デプロイに使用することができます。

Confluent Platform クラスターにおけるセキュリティは、Apache Kafka® ブローカー用に構成されたセキュリティによって管理されます。Confluent Platform クラスターのセキュリティを構成するには、Kafka ブローカークラスターのセキュリティを構成し、それが機能することを確認したうえで、他の Confluent Platform コンポーネントのセキュリティを重層化します。以下のリストに、クラスターにセキュリティを追加する場合の標準的な順序を示します。

Kafka ブローカーのセキュリティを構成し、アクセスできることを確認します。
該当する Confluent Platform コンポーネントのセキュリティを構成し、アクセスできることを確認します。
外部クライアントのセキュリティを構成し、アクセスできることを確認します。

高レベルでは、Kafka の暗号化と認証は構成ファイル（$VALUES_FILE）の以下の設定で管理されます。

kafka:
  tls:
    enabled:        # Specifies the encryption method
    authentication:
      type:         # Specifies the authentication method
Copy

Operator でサポートされている Kafka の暗号化と認証の設定を以下にまとめます。

TLS 暗号化、認証なし
```
kafka:
  tls:
    enabled: true
```
Copy

TLS 暗号化、mTLS 認証

kafka:
  tls:
    enabled: true
    authentication:
      type: tls
Copy

TLS 暗号化、SASL PLAIN 認証

kafka:
  tls:
    enabled: true
    authentication:
      type: plain
Copy

暗号化なし、SASL PLAIN 認証

kafka:
  tls:
    enabled: false
    authentication:
      type: plain
Copy

重要

Kafka の証明書の追加またはアップデートを行うには、Kafka ポッドを再起動するか、Kafka クラスターをローリングして、Kafka クラスターを再起動する必要があります。

このガイドの例では、以下が想定されています。

$VALUES_FILE は「グローバル構成ファイルの作成」でセットアップする構成ファイルのことです。
Operator ドキュメントで簡潔で明快な例を提示できるよう、すべての構成パラメーターが構成ファイル（ $VALUES_FILE ）に指定されます。ただし、本稼働環境でのデプロイにおいて、Helm を使用して機密データを扱う場合には、--set または --set-file オプションを使用します。以下に例を示します。
```
helm upgrade --install kafka \
 --set kafka.services.mds.ldap.authentication.simple.principal="cn=mds\,dc=test\,dc=com" \
 --set kafka.services.mds.ldap.authentication.simple.credentials=”Developer!” \
 --set kafka.enabled=true
```
Copy
operator は Confluent Platform のデプロイ先となる名前空間です。
コマンドはすべて、Confluent Operator のダウンロード先ディレクトリにある helm ディレクトリで実行されます。

暗号化¶

Operator では、Confluent Platform 用にプレーンテキスト（暗号化なし）と TLS 暗号化がサポートされています。デフォルトはプレーンテキストです。

TLS を使用するネットワーク暗号化¶

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

証明書とキー¶

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

テスト用の自己署名証明書の生成¶

セキュリティ構成を確認するには、以下の手順に従ってテスト用の自己署名証明書を作成します。本稼働環境へのデプロイには、専用の証明書を生成する必要があります。

ルートキーを作成します。
```
openssl genrsa -out rootCA.key 2048
```
Copy

ルート証明書を作成します。

openssl req -x509  -new -nodes \
-key rootCA.key \
-days 3650 \
-out rootCA.pem \
-subj "/C=US/ST=CA/L=MVT/O=TestOrg/OU=Cloud/CN=TestCA"
Copy

サーバープライベートキーを作成します。
```
openssl genrsa -out server.key 2048
```
Copy

サーバー証明書用に CSR を生成します。

openssl req -new -key server.key \
 -out server.csr \
 -subj "/C=US/ST=CA/L=MVT/O=TestOrg/OU=Cloud/CN=*.operator.svc.cluster.local"
Copy

証明書に署名します。

openssl x509 -req \
 -in server.csr \
 -extensions server_ext \
 -CA rootCA.pem \
 -CAkey rootCA.key \
 -CAcreateserial \
 -out server.crt \
 -days 365 \
 -extfile \
 <(echo "[server_ext]"; echo "extendedKeyUsage=serverAuth,clientAuth"; echo "subjectAltName=DNS:*.operator.svc.cluster.local")
Copy

上記の手順で以下のファイルが作成されるので、cacerts、fullchain、privkey について、構成ファイル（ $VALUES_FILE ）の tls セクションの対応するキーにマップします。

cacerts は rootCA.pem に含まれています。
fullchain （フルチェーン）は server.crt に含まれています。
privkey （プライベートキー）は server.key に含まれています。

証明書の SAN 属性¶

Kafka ブローカーによって使用される証明書を作成する場合は、サブジェクトの別名（SAN: Subject Alternative Name）属性を構成します。SAN を使用すると、複数のホスト名を単一の証明書で指定できます。

Kafka クラスターに Kubernetes の外部からアクセスできるように SAN 属性を構成する方法が 2 つあります。

証明書の SAN にワイルドカードドメインを使用することが組織から許可されている場合は、証明書を生成する際に以下の SAN 属性を使用します。
- 外部のブートストラップおよびブローカーのアドレス用の SAN 属性:
```
*.<kafka-domain>
```
  Copy
- 内部アドレス用の SAN 属性:
```
*.<component-name>.<namespace>.svc.cluster.local
```
  Copy
  <component-name> は、構成ファイル（ $VALUES_FILE ）のコンポーネントセクションの name: に設定される値のセットです。
ワイルドカードを使用できない場合は、SAN 属性を複数指定する必要があります。その場合は、Kafka ブローカープレフィックス、ブートストラッププレフィックス、ブローカー数に基づく以下の SAN 属性を使用します。
- 外部のブートストラップおよびブローカーのアドレス用の SAN 属性:
```
<bootstrap-prefix>.<kafka-domain>

<broker-prefix>0.<kafka-domain>
<broker-prefix>1.<kafka-domain>
...
<broker-prefix><N-1>.<kafka-domain>
```
  Copy
  たとえば、以下のような構成だとします。
  - Kafka ドメインは confluent-platform.example.com 。
  - ブローカープレフィックスは b （Kafka の構成時にブローカープレフィックスを明示的に設定しなかった場合のデフォルト）。
  - ブートストラッププレフィックスは kafka （デフォルト）。
  - operator 名前空間にデプロイする Kafka ブローカーは 3 つ。
  外部アドレス証明書の生成では、以下の SAN を使用します。
```
b0.confluent-platform.example.com
b1.confluent-platform.example.com
b2.confluent-platform.example.com
kafka.confluent-platform.example.com
```
  Copy
- 内部の Kafka ブートストラップのアドレスと各ブローカーの具体的な内部アドレス用の SAN 属性:
```
<kafka-component-name>.<kafka-namespace>.svc.cluster.local

<kafka-component-name>-0.<kafka-component-name>.<kafka-namespace>.svc.cluster.local
<kafka-component-name>-1.<kafka-component-name>.<kafka-namespace>.svc.cluster.local
...
<kafka-component-name>-<N-1>.<kafka-component-name>.<kafka-namespace>.svc.cluster.local
```
  Copy
  <kafka-component-name> は、構成ファイル（ $VALUES_FILE ）の kafka コンポーネントセクションの name: に設定される値です。
  
  たとえば、以下のような構成だとします。
  - Kafka コンポーネント名は kafka （デフォルト）。
  - operator 名前空間にデプロイする Kafka ブローカーは 3 つ。
  内部アドレス証明書の生成では、以下の SAN を使用します。
```
kafka.operator.svc.cluster.local
kafka-0.kafka.operator.svc.cluster.local
kafka-1.kafka.operator.svc.cluster.local
kafka-2.kafka.operator.svc.cluster.local
```
  Copy
- 他のコンポーネントの内部アドレス用の SAN 属性:
```
<component-name>.<namespace>.svc.cluster.local
```
  Copy
  <component-name> は、構成ファイル（ $VALUES_FILE ）のコンポーネントセクションの name: に設定される値のセットです。
Kafka クラスターを拡張する場合は、クラスターの追加ブローカー用として証明書に DNS SAN が必要になります。新しいブローカーの追加前に証明書を新たに生成し直さずに済ませるには、証明書に DNS SAN を当初のブローカー数よりも多く指定しておくことを検討します。たとえば、ブローカー 3 つから始める計画において、6 つに拡張する必要性が生じうる場合は、証明書に最初から DNS SAN を 6 つ（以上）含めておくと、拡張の必要性が実際に生じても証明書を新たに作成せずに済みます。

JMX および Jolokia エンドポイントの TLS 暗号化を有効にした場合は、TLS 暗号化で使用する JMX および Jolokia 構成を参照して、JMX の詳細な SAN 要件を調べます。

構成ファイル外の認証情報の管理¶

セキュリティ強化のため、プライベートキーなどの認証情報は構成ファイル（ $VALUES_FILE ）の外部に保存できます。また、証明書データは大きくてかさばることがあり、このデータを既に別ファイルで保持している場合は、データをコピーして $VALUES_FILE に貼り付けて YAML 構文を扱うことは、できれば避けたい作業です。

このようなファイルのコンテンツは、構成ファイル（ $VALUES_FILE ）に直接指定するのではなく、Helm コマンドの発行時に渡すことができます。以下に例を示します。

helm upgrade --install kafka ./confluent-operator \
  --values $VALUES_FILE \
  --namespace operator \
  --set kafka.enabled=true \
  --set kafka.tls.enabled=true \
  --set kafka.metricReporter.tls.enabled=true \
  --set-file kafka.tls.cacerts=/tmp/ca-bundle.pem \
  --set-file kafka.tls.fullchain=/tmp/server-cert.pem \
  --set-file kafka.tls.privkey=/tmp/server-key.pem
Copy

TLS 暗号化用の Kafka 構成¶

構成ファイル（$VALUES_FILE）の kafka セクションで TLS 暗号化を有効にして構成します。以下のスニペットに例を示します。

kafka:
  tls:
    enabled: true            ----- [1]
    interbrokerTLS: true     ----- [2]
    internalTLS: true        ----- [3]

    fullchain: |-            ----- [4]
      ---BEGIN CERTIFICATE---
      ... omitted
      ---END CERTIFICATE---
    privkey: |-              ----- [5]
      ---BEGIN RSA PRIVATE KEY---
      ... omitted
      ---END RSA PRIVATE KEY---

  configOverrides:
    server:
      - listener.name.internal.ssl.principal.mapping.rules=    --- [6]
      - listener.name.replication.ssl.principal.mapping.rules= --- [7]
Copy

以下を設定してください。

[1] enabled: true と設定して、TLS 暗号化を有効にします。
[2] interbrokerTLS: true と設定して、ブローカー間通信や Kafka と Replicator との通信での TLS 暗号化を有効にします。この設定が反映されるためには、[1] が true に設定されている必要があります。

interBrokerTLS: true の設定は、新規インストールの場合にのみサポートされます。既存のデプロイをアップグレードしてブローカー間 TLS を有効にすることはサポートされていません。

[1] と [2] が true に設定されている場合は、Kafka 証明書に内部アドレスが含まれている必要があります。

interbrokerTLS: true の場合、[7] で configOverrides を使用して、ブローカー間リスナープリンシパルのマッピングルールを Kafka サーバー構成に追加します。
[3] internalTLS: true と設定して、コンポーネント間通信の TLS 暗号化を有効にします。この設定が反映されるためには、[1] が true に設定されている必要があります。

internalTLS: true の場合は、[6] で configOverrides を使用して内部リスナープリンシパルのマッピングルールを Kafka サーバー構成に追加します。
[4] フルチェーン証明書を指定します。fullchain には、ルート CA、すべての中間 CA、ブローカーの証明書をこの順序で指定します。

外部、内部、ブローカー間のリスナーがこの同じ証明書を使用します。

用意する証明書には、外部のブートストラップおよびブローカーのアドレス、内部の Kafka ブートストラップのアドレス、各ブローカーの具体的な内部アドレスで使用される DNS SAN が指定されている必要があります。証明書での SAN の構成については、「証明書の SAN 属性」を参照してください。
[5] 証明書のプライベートキーを指定します。privkey には、ブローカー証明書に関連付けられているプライベートキーが指定されます。

[6] internalTLS: true の場合は、以下の内部リスナープリンシパルのマッピングルールを追加します。

kafka:
  configOverrides:
    server:
      - "listener.name.internal.ssl.principal.mapping.rules=RULE:^CN=([a-zA-Z0-9.]*).*$/$1/L, DEFAULT"
Copy

[7] interbrokerTLS: true の場合は、以下の内部リスナープリンシパルのマッピングルールを追加します。

kafka:
  configOverrides:
    server:
      - "listener.name.replication.ssl.principal.mapping.rules=RULE:^CN=([a-zA-Z0-9.]*).*$/$1/L, DEFAULT"
Copy

TLS 暗号化用のコンポーネント構成¶

このセクションでは、他の Confluent Platform コンポーネントを、（a）TLS 暗号化を使用するよう構成された Kafka と正常に通信するように、および（b）コンポーネント自体が TLS 暗号化トラフィックを処理するように、セットアップする方法について説明します。

以下は一般的なガイドラインであり、セキュリティの依存関係を網羅しているわけではありません。コンポーネントの依存関係の詳細については、<operator-home>/helm/confluent-operator/charts フォルダーにあるコンポーネントの values.yaml ファイルを参照してください。

構成ファイル（ $VALUES_FILE ）でコンポーネントを以下のように構成します。

<component>:
  tls:
    enabled: true                     ----- [1]
    internalTLS: true                 ----- [2]

      cacerts: |-                     ----- [3]
        ---BEGIN CERTIFICATE---
        ... omitted
        ---END CERTIFICATE-----
      fullchain: |-                   ----- [4]
        ---BEGIN CERTIFICATE---
        ... omitted
        ---END CERTIFICATE---
      privkey: |-                     ----- [5]
        -----BEGIN RSA PRIVATE KEY--
        ... omitted
        -----END RSA PRIVATE KEY----
Copy

[1] 外部通信の暗号化モード。外部リスナーで TLS 暗号化トラフィックを処理するには、enabled: true と設定します。
[2] 内部通信の暗号化モード。内部リスナーで TLS 暗号化トラフィックを処理するには、internalTLS: true と設定します。この設定が反映されるためには、[1] が true に設定されている必要があります。
[3] Kafka ブローカーから提示された証明書がコンポーネントから信頼されるための、1 つまたは複数の連鎖する証明機関（CA）。
[4] コンポーネントで TLS 暗号化トラフィックの処理に使用される、証明書のフルチェーン。fullchain には、ルート CA、すべての中間 CA、ブローカーの証明書をこの順序で指定します。

Replicator、Connect、Schema Registry などのコンポーネントは、内部トラフィック用の TLS を使用して構成できます。したがって、同じクラスター内での Replicator 対 Replicator のようなレプリカ間トラフィックを、外部リスナー用として使用されているものと同じ証明書で暗号化できます。
[5] ブローカー証明書に関連付けられているプライベートキーを指定します。

TLS 暗号化で使用する JMX および Jolokia 構成¶

Confluent Operator では、各 Confluent Platform コンポーネントの JMX および Jolokia エンドポイント用に TLS 暗号化がサポートされています。

TLS は、JMX 用ではポート 7203 に、Jolokia 用ではポート 7777 にセットアップされます。

JMX および Jolokia エンドポイントの TLS 暗号化を有効にするには、構成ファイル（ $VALUES_FILE ）の必要な各コンポーネントについて以下を設定します。

<component>:
  tls:
    jmxTLS: true           ----- [1]
    fullchain:             ----- [2]
    privkey:               ----- [3]
Copy

[1] JMX および Jolokia エンドポイントの TLS 暗号化を有効にするには、jmxTLS: true と設定します。

jmxTLS: true の設定はグリーンフィールドインストールでのみサポートされており、アップグレードではサポートされません。

jmxTLS: true を設定した場合は、Kafka 証明書の SAN 属性に以下を含めます。
```
*.<kafka-component-name>.<kafka-namespace>
```
Copy
使用している SAN でワイルドカード（*）が許可されない場合は、以下を含めます。
```
<kafka-component-name>.<kafka-namespace>

<kafka-component-name>-0.<kafka-component-name>.<kafka-namespace>
<kafka-component-name>-1.<kafka-component-name>.<kafka-namespace>
...
<kafka-component-name>-<N-1>.<kafka-component-name>.<kafka-namespace>
```
Copy
[2] TLS 証明書のフルチェーンを設定します。
[3] 証明書のプライベートキーを指定します。

JMX および Jolokia エンドポイントのセキュリティ保護に使用される TLS 証明書は、コンポーネントで一般に使用されることになるものと同じです。JMX および Jolokia エンドポイント専用に別個の fullchain および privkey 設定はありません。

認証¶

Operator では、Confluent Platform 用として SASL PLAIN および mTLS 認証方式がサポートされています。デフォルトは SASL PLAIN です。

SASL PLAIN を使用した認証¶

PLAIN SASL 認証が構成されている場合は、Kafka ブローカーを使用した認証用に、1 組のユーザー名とパスワードが外部クライアントや内部 Confluent Platform コンポーネントから提示されます。

SASL PLAIN 認証用の Kafka の構成¶

Operator を使用して Confluent Platform を管理する場合、SASL PLAIN はデフォルトの認証方式であり、SASL PLAIN を明示的に有効にする必要はありません。構成をはっきり文書化するために、SASL PLAIN を明示的に有効にする場合は、設定を構成ファイル（ $VALUES_FILE ）の kafka セクションで有効にします。以下に例を示します。

kafka:
  tls:
    authentication:
      type: plain
Copy

グローバル Confluent Platform ユーザーの追加¶

Kafka 用のブローカー間ユーザーを追加します。他の Confluent Platform コンポーネントでも、Kafka に対する認証でこのユーザーが使用されます。

構成ファイル（$VALUES_FILE）の sasl セクションにユーザー名とパスワードを指定します。次に例を示します。

global:
  sasl:
    plain:
      username: <username>
      password: <password>
Copy

上記の機密データは、構成ファイル（ $VALUES_FILE ）に直接ではなく、Helm コマンドラインフラグを使用して指定できます。たとえば、コマンドラインからパスワードを指定するには以下のようにします。

helm upgrade --install kafka ./confluent-operator \
  --values $VALUES_FILE \
  --namespace operator \
  --set kafka.enabled=true \
  --set global.sasl.plain.password=<my-password>
Copy

カスタム SASL ユーザーの追加¶

SASL ユーザーを追加するには、構成ファイル（ $VALUES_FILE ）の kafka セクションでユーザーを追加します。以下に例を示します。

kafka:
  sasl:
    plain:
      - <user1>=<password1>
      - <user2>=<password2>
      - <user3>=<password3>
Copy

この設定は動的であり、実行中の Kafka クラスターを再起動することなくユーザーを追加できます。

SASL PLAIN 認証のコンポーネント構成¶

Kafka での認証に SASL PLAIN が使用されるよう他の Confluent Platform コンポーネントをセットアップするには、構成ファイル（$VALUES_FILE）で type: plain と設定して Kafka 認証タイプを plain にします。

<component>:
  dependencies:
    kafka:
      tls:
        authentication:
          type: plain
Copy

mTLS を使用した認証¶

mTLS 認証用の Kafka の構成¶

構成ファイル（ $VALUES_FILE ）の kafka セクションで相互 TLS（mTLS）認証を有効にして構成します。mTLS 認証を有効にするには、TLS 暗号化も有効にする必要があります。以下のスニペットでは、mTLS 認証を有効にしています。

kafka:
  tls:
    enabled: true            ----- [1]
    authentication:
      type: tls              ----- [2]
    cacerts: |-              ----- [3]
      -----BEGIN CERTIFICATE-----
      ... omitted
      -----END CERTIFICATE-------
    fullchain: |-            ----- [4]
      -----BEGIN CERTIFICATE-----
      ... omitted
      -----END CERTIFICATE-------
    privkey: |-              ----- [5]
      -----BEGIN RSA PRIVATE KEY-
      ... omitted
      -----END RSA PRIVATE KEY---
Copy

[1] enabled: true と設定して、TLS 暗号化を有効にします。
[2] type: tls と設定して、mTLS 認証を有効にします。
[3] クライアントから提示された証明書を認証するために Kafka ブローカーで使用されるすべての CA からなる CA 証明書を指定します。
[4] ルート CA、すべての中間 CA、Kafka ブローカーの証明書がこの順序で含まれるフルチェーン証明書を指定します。
[5] Kafka ブローカー証明書に関連付けられているプライベートキーを指定します。

mTLS 認証のためのコンポーネント構成¶

Kafka に対する認証で mTLS が使用されるよう他の Confluent Platform コンポーネントをセットアップするには、構成ファイル（ $VALUES_FILE ）でコンポーネントを以下のように構成します。

以下は一般的なガイドラインであり、セキュリティの依存関係を網羅しているわけではありません。コンポーネントの依存関係の詳細については、<operator-home>/helm/confleunt-operator/charts フォルダーにあるコンポーネントの values.yaml ファイルを参照してください。

<component>:
  dependencies:
    kafka:
      tls:
        enabled: true               ----- [1]
        authentication:
          type: tls                 ----- [2]
      bootstrapEndpoint:            ----- [3]
  tls:
    cacerts: |-                     ----- [4]
      -----BEGIN CERTIFICATE-------
      ... omitted
      -----END CERTIFICATE---------
    fullchain: |-                   ----- [5]
      -----BEGIN CERTIFICATE-------
      ... omitted
      -----END CERTIFICATE---------
    privkey: |-                     ----- [6]
      -----BEGIN RSA PRIVATE KEY---
      ... omitted
      -----END RSA PRIVATE KEY-----
Copy

[1] 外部通信の暗号化モード。mTLS 認証には enabled: true が必要です。
[2] 認証方式。mTLS 認証を使用するために type: tls と設定します。
[3] 以下の説明に従って、Kafka クラスターの送信先エンドポイントを設定します。
- コンポーネントと Operator でデプロイされた Kafka との通信が Kafka の内部リスナー経由の場合:
  - Kafka クラスターがこのコンポーネントと同じ名前空間にデプロイされる場合 : <kafka-component-name> :9071
  - Kafka クラスターがこのコンポーネントとは異なる名前空間にデプロイされる場合 : <kafka-component-name>.<kafka-namespace>.svc.cluster.local:9071
  <kafka-component-name> は、構成ファイル（ $VALUES_FILE ）の kafka コンポーネントセクションの name に設定される値です。
- コンポーネントと Operator でデプロイされた Kafka との通信が Kafka の外部リスナー経由の場合:
  - ロードバランサーを使用する場合 : <bootstrap-prefix>.<domain> :9092
    
    これらの値は、kafka セクションの loadBalancer:bootstrapPrefix と loadBalancer:domain に設定されます。bootstrapPrefix か設定されていない場合は、kafka のデフォルト値が使用されます。
  - NodePort を使用する場合 : <host> :<port-offset>
    
    これらの値は、kafka セクションの nodePort:host と nodePort:portOffset に設定されます。
  - 静的なホストベースルーティングを使用する場合 : <bootstrap-prefix>.<domain> :9092
    
    これらの値は、kafka セクションの staticForHostBasedRouting:bootstrapPrefix と staticForHostBasedRouting:domain に設定されます。bootstrapPrefix か設定されていない場合は、kafka のデフォルト値が使用されます。
  - 静的なポートベースルーティングを使用する場合 : <host> :<port-offset>
    
    これらの値は、kafka セクションの staticForPortBasedRouting:host と staticForPortBasedRouting:portOffset に設定されます。
- コンポーネントとこの Operator によってデプロイされていない Kafka クラスターとの通信を実現するには、行き先エンドポイントをそのクラスターのブートストラップ URL に設定する必要があります。
[4] Kafka ブローカーから提示された証明書がコンポーネントから信頼されるよう、CA 証明書を指定します。ここには、クライアントから提示された証明書を認証するために Kafka ブローカーで使用されるすべての CA を指定します。
[5] コンポーネントの認証に使用する証明書のフルチェーン。fullchain には、ルート CA、すべての中間 CA、ブローカーの証明書をこの順序で指定します。
[6] [5] の証明書用のプライベートキーを指定します。

たとえば、内部および外部通信の暗号化に mTLS が使用される Kafka ブローカーを構成した場合、Replicator のセキュリティセクションの構成パラメーターは以下のようになります。

replicator:
  name: replicator
  tls:
    cacerts: |-
    -----BEGIN CERTIFICATE-----
    ... omitted
    -----END CERTIFICATE-----
    fullchain: |-
    -----BEGIN CERTIFICATE-----
    ... omitted
    -----END CERTIFICATE-----
    privkey: |-
    -----BEGIN RSA PRIVATE KEY-----
    ... omitted
    -----END RSA PRIVATE KEY-----
  dependencies:
    kafka:
      tls:
        enabled: true
        internal: true
        authentication:
          type: "tls"
      bootstrapEndpoint: kafka.operator.svc.cluster.local:9092
Copy

mTLS 認証のための JMX および Jolokoa 構成¶

Confluent Operator では、各 Confluent Platform コンポーネントの JMX および Jolokia エンドポイント用に mTLS 認証の有効化がサポートされています。

注意 : 現時点で、Operator では JMX および Jolokia エンドポイント用の SASL PLAIN 認証はサポートされていません。

mTLS JMX は、JMX 用ではポート 7203 に、Jolokia 用ではポート 7777 にセットアップされます。

JMX および Jolokia 用に mTLS 認証を有効にするには、構成ファイル（$VALUES_FILE）の必要な各コンポーネントについて以下を設定します。

<component>:
  tls:
    jmxTLS: true           ----- [1]
    jmxAuthentication:
      type: tls            ----- [2]
    cacerts:               ----- [3]
    fullchain:             ----- [4]
    privkey:               ----- [5]
Copy

[1] JMX および Jolokia エンドポイントの TLS 暗号化を有効にするには、jmxTLS: true と設定します。

jmxTLS: true の設定はグリーンフィールドインストールでのみサポートされており、アップグレードではサポートされません。
[2] type: tls と設定して、JMX および Jolokia エンドポイント用に mTLS 認証を有効にします。
[3] CA 証明書を指定して、クライアントが mTLS を使用した認証で信頼されるようにします。
[4] TLS 証明書のフルチェーンを設定します。
[5] 証明書のプライベートキーを指定します。

CA 証明書、フルチェーン、プライベートキー値は、JMX および Jolokia エンドポイントのコンポーネント間通信と外部通信の両方のセキュリティ保護に使用されます。

認証と暗号化のためのクライアント構成¶

クライアントのセキュリティ構成は、Kafka のセキュリティ設定に応じて異なります。

Kafka のセキュリティ構成情報は、Kafka クラスターから以下のコマンドを使用して取得できます（サンプル名 kafka が名前空間 operator 上で実行中と想定）。

内部クライアント（Kubernetes クラスター内で実行）の場合:
```
kubectl get kafka kafka -ojsonpath='{.status.internalClient}' -n operator
```
Copy
外部クライアント（Kubernetes クラスター外で実行）の場合:
```
kubectl get kafka kafka -ojsonpath='{.status.externalClient}' -n operator
```
Copy

クライアントを構成するには、以下を参照してください。

Kafka クラスターで TLS 暗号化が使用されている場合は、「SSL による暗号化」の説明に従ってクライアントを構成します。
Kafka クラスターで mTLS 暗号化および認証が使用されている場合は、「SSL による暗号化と認証」の説明に従ってクライアントを構成します。
Kafka クラスターで SASL PLAIN 認証による TLS 暗号化が使用されている場合は、「SASL による暗号化と認証」の説明に従ってクライアントを構成します。

Confluent Control Center の暗号化と認証¶

Control Center でサポートされている暗号化および認証方式は以下のとおりです。

暗号化: ポート 9021 での REST endpoint over HTTPS
認証: 基本または LDAP
警告
- Operator とともにデプロイされている場合、Confluent Control Center は基本認証を使用して Schema Registry に接続することはできません。
- Confluent Control Center は、基本認証を使用した Connect と ksqlDB への接続をサポートしません。

選択する認証方式に基づいて、構成ファイル（$VALUES_FILE）でその方式の関連設定を構成します。

controlcenter:
  auth:
    basic:
      enabled: false
      ##
      ## map with key as user and value as password and role
      property: {}
      # property:
      #  admin: Developer1,Administrators
      #  disallowed: no_access
    ldap:
      enabled: false
      nameOfGroupSearch: c3users
      property: {}
Copy