第11章 TLS 証明書の管理


AMQ Streamsは、KafkaコンポーネントとAMQ Streamsコンポーネント間の暗号化通信用のTLSをサポートしています。

通信は常に以下のコンポーネント間で暗号化されます。

  • Kafka と ZooKeeper 間の通信
  • Kafka ブローカー間の通信
  • ZooKeeper ノード間の通信
  • AMQ Streams operator の Kafka ブローカーおよび ZooKeeper ノードとの通信

Kafka クライアントと Kafka ブローカーとの間の通信は、クラスターが設定された方法に応じて暗号化されます。Kafka および AMQ Streams コンポーネントでは、TLS 証明書も認証に使用されます。

Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または TLS 認証を有効にする場合、他の TLS 証明書も設定されます。

認証局(CA)証明書は、コンポーネントとクライアントのID検証にクラスター Operator によって生成されます。クラスター Operator によって生成されたCAを使用しない場合は 独自のクラスターおよびクライアントCA証明書をインストールできます

TLS暗号化が有効になっているTLSリスナーまたは外部リスナーにKafkaリスナー証明書 を指定することもできます。Kafka リスナー証明書を使用して、既存のセキュリティインフラストラクチャを組み込みます。

注記

クラスター Operator では、独自に指定した証明書には更新されません。

図11.1 TLS によってセキュリティーが保護された通信のアークテクチャー例

11.1. 認証局

暗号化のサポートには、AMQ Streams コンポーネントごとに固有の秘密鍵と公開鍵証明書が必要です。すべてのコンポーネント証明書は、クラスター CA と呼ばれる内部認証局 (CA) により署名されます。

同様に、TLS クライアント認証を使用して AMQ Streams に接続する各 Kafka クライアントアプリケーションは、秘密鍵と証明書を提供する必要があります。クライアント CA という第 2 の内部 CA を使用して、Kafka クライアントの証明書に署名します。

11.1.1. CA 証明書

クラスター CA とクライアント CA の両方には、自己署名の公開鍵証明書があります。

Kafka ブローカーは、クラスター CA またはクライアント CA のいずれかが署名した証明書を信頼するように設定されます。クライアントによる接続が不要なコンポーネント (ZooKeeper など) のみが、クラスター CA によって署名された証明書を信頼します。外部リスナーの TLS 暗号化が無効でない限り、クライアントアプリケーションはクラスター CA により署名された証明書を必ず信頼する必要があります。これは、相互 TLS 認証 を実行するクライアントアプリケーションにも当てはまります。

デフォルトで、AMQ Streams はクラスター CA またはクライアント CA によって発行された CA 証明書を自動で生成および更新します。これらの CA 証明書の管理は、Kafka.spec.clusterCa および Kafka.spec.clientsCa オブジェクトで設定できます。ユーザーが用意した証明書は更新されません。

クラスター CA またはクライアント CA に、独自の CA 証明書を提供できます。詳細は、「独自の CA 証明書のインストール」 を参照してください。独自の証明書を提供する場合は、証明書の更新が必要なときに手作業で更新する必要があります。

11.1.2. 独自の CA 証明書のインストール

この手順では、Cluster Operator で生成される CA 証明書と鍵を使用する代わりに、独自の CA 証明書と秘密鍵をインストールする方法について説明します。

Cluster Operator は以下のシークレットを自動的に生成し、更新します。

CLUSTER-NAME-cluster-ca
クラスター CA の秘密鍵が含まれるクラスターシークレット。
CLUSTER-NAME-cluster-ca-cert
クラスター CA 証明書が含まれるクラスターシークレット。証明書には、Kafka ブローカーの ID を検証する公開鍵が含まれます。
CLUSTER-NAME-clients-ca
クライアント CA の秘密鍵が含まれるクライアントシークレット。
CLUSTER-NAME-clients-ca-cert
クライアント CA 証明書が含まれるクライアントシークレットです。証明書には、Kafka ブローカーにアクセスするクライアントの ID を検証する公開鍵が含まれます。

AMQ Streams はデフォルトでこれらのシークレットを使用します。

この手順では、独自のクラスターまたはクライアント CA 証明書を使用するシークレットを置き換える手順を説明します。

前提条件

  • 稼働中の Cluster Operator。
  • Kafka クラスターがデプロイされていない必要があります。
  • クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。

    • ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。

      1. クラスターまたはクライアント CA
      2. 1 つ以上の中間 CA
      3. ルート CA
    • チェーン内のすべての CA は、X509v3 基本制約拡張を使用して設定する必要があります。Basic Constraints は、証明書チェーンのパスの長さを制限します。
  • 証明書を変換するための OpenSSL TLS 管理ツール。

作業を開始する前に

クラスターオペレーターは、CLUSTER-NAME-cluster-ca-cert シークレット用に以下のファイルを生成します。

  • ca.crt クラスター証明書(PEM 形式)
  • PKCS #12 形式の ca.p12 クラスター証明書
  • PKCS #12 ファイルにアクセスするための ca.password

一部のアプリケーションは PEM 証明書を使用できず、PKCS #12 証明書のみに対応します。独自のクラスター証明書を PKCS #12 形式で追加することもできます。

PKCS #12 形式のクラスター証明書がない場合は、OpenSSL TLS 管理ツールを使用して ca.crt ファイルからこれを生成します。

証明書生成コマンドの例

openssl pkcs12 -export -in ca.crt --nokeys -out ca.p12 -password pass:P12-PASSWORD -caname ca.crt
Copy to Clipboard Toggle word wrap

P12-PASSWORD は、自身のパスワードに置き換えます。

CLUSTER-NAME-clients-ca-certシークレットにも同様の操作を行うことができます。このシークレットには、デフォルトでPEMおよびPKCS #12形式の証明書も含まれています。

手順

  1. Cluster Operator によって生成される CA 証明書を置き換えます。

    1. 既存のシークレットを削除します。

      oc delete secret CA-CERTIFICATE-SECRET
      Copy to Clipboard Toggle word wrap

      CA-CERTIFICATE-SECRETは,Secret の名称です。

      • CLUSTER-NAME-cluster-ca-cert: クラスタCA証明書
      • CLUSTER-NAME-clients-ca-cert: クライアントのCA証明書

      CLUSTER-NAME は、Kafka クラスターの名前に置き換えます。

      「Not Exists」エラーを無視します。

    2. 新規シークレットを作成します。

      PEM 形式の証明書を使用したクライアントシークレットの作成

      oc create secret generic CLUSTER-NAME-clients-ca-cert --from-file=ca.crt=ca.crt
      Copy to Clipboard Toggle word wrap

      PEM および PKCS #12 形式の証明書を使用したクラスターシークレットの作成

      oc create secret generic CLUSTER-NAME-cluster-ca-cert \
        --from-file=ca.crt=ca.crt \
        --from-file=ca.p12=ca.p12 \
        --from-literal=ca.password=P12-PASSWORD
      Copy to Clipboard Toggle word wrap

  2. Cluster Operator によって生成される秘密鍵を置き換えます。

    1. 既存のシークレットを削除します。

      oc delete secret CA-KEY-SECRET
      Copy to Clipboard Toggle word wrap

      CA-KEY-SECRET は CA キーの名前です。

      • CLUSTER-NAME-cluster-ca(クラスタCAキー)
      • CLUSTER-NAME-clients-ca(クラスタCAキー)
    2. 新規シークレットを作成します。

      oc create secret generic CA-KEY-SECRET --from-file=ca.key=ca.key
      Copy to Clipboard Toggle word wrap
  3. シークレットにラベルを付けます。

    oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
    Copy to Clipboard Toggle word wrap
    oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
    Copy to Clipboard Toggle word wrap
    • ラベル strimzi.io/kind=Kafka は Kafka カスタムリソースを識別します。
    • ラベル strimzi.io/cluster=CLUSTER-NAME は Kafka クラスターを識別します。
  4. シークレットにアノテーションを付けます。

    oc annotate secret CA-CERTIFICATE-SECRET strimzi.io/ca-cert-generation=CA-CERTIFICATE-GENERATION
    Copy to Clipboard Toggle word wrap
    oc annotate secret CA-KEY-SECRET strimzi.io/ca-key-generation=CA-KEY-GENERATION
    Copy to Clipboard Toggle word wrap
    • strimzi.io/ca-cert-generation=CA-CERTIFICATE-GENERATION のアノテーションでは、新しい CA 証明書の生成を定義します。
    • strimzi.io/ca-key-generation=CA-KEY-GENERATION のアノテーションは、新しい CA キーの生成を定義します。

      クラスター Operator で自動生成されたCA証明書を置き換える場合は、既存のアノテーションに1つ足した値を使用して、CAキーの置き換え手順を実行します。クラスター Operator で自動生成されたCA証明書がない場合は、0 を開始点として独自の CA 証明書を増分値で (strimzi.io/ca-cert-generation=0) 指定していきます。証明書を更新するときは、値を 1 つ増やして設定します。

  5. クラスターの Kafka リソースを作成し、生成された CA を 使用しない ように Kafka.spec.clusterCa または Kafka.spec.clientsCa オブジェクトを設定します。

    独自指定の証明書を使用するようにクラスター CA を設定する Kafka リソースの例 (抜粋)

    kind: Kafka
    version: kafka.strimzi.io/v1beta2
    spec:
      # ...
      clusterCa:
        generateCertificateAuthority: false
    Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat