Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

15.2. Operator によって生成されたシークレット

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

シークレットは、Kafka や KafkaUser などのカスタムリソースがデプロイされるときに作成されます。AMQ Streams はこれらのシークレットを使用して、Kafka クラスター、クライアント、およびユーザーの秘密鍵と公開鍵の証明書を格納します。Secrets は、Kafka ブローカー間およびブローカーとクライアント間で TLS で暗号化された接続を確立するために使用されます。これらは mTLS 認証にも使用されます。

クラスターとクライアントのシークレットは常に、公開鍵と、秘密鍵のペアとなっています。

クラスターシークレット
クラスターシークレットには、Kafka ブローカー証明書に署名するためのクラスター CAが含まれています。接続するクライアントは、証明書を使用して、Kafka クラスターとの TLS 暗号化接続を確立します。証明書はブローカーのアイデンティティを確認します。
クライアントシークレット
クライアントシークレットには、ユーザーが独自のクライアント証明書に署名するためのクライアント CAが含まれています。これにより、Kafka クラスターに対する相互認証が可能になります。ブローカーは、証明書を使用してクライアントのアイデンティティを検証します。
ユーザーシークレット
ユーザーシークレットには、秘密鍵と証明書が含まれています。シークレットは、新しいユーザーの作成時にクライアント CA で作成され、署名されます。キーと証明書は、クラスターへのアクセス時にユーザーの認証および承認に使用されます。
注記

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

15.2.1. PEM または PKCS #12 形式の鍵と証明書を使用した TLS 認証
リンクのコピー

AMQ Streams によって作成されたシークレットは、PEM (Privacy Enhanced Mail) および PKCS #12 (Public-Key Cryptography Standards) 形式の秘密鍵と証明書を提供します。PEM および PKCS #12 は、SSL プロトコルを使用した TLS 通信用に OpenSSL で生成されたキー形式です。

Kafka クラスターおよびユーザー用に生成されたシークレットに含まれる認証情報を使用する相互 TLS (mTLS) 認証を設定できます。

mTLS をセットアップするには、まず次のことを行う必要があります。

Kafka クラスターをデプロイすると、クラスターを検証するために公開鍵を使用して <cluster_name>-cluster-ca-cert シークレットが作成されます。公開鍵を使用して、クライアントのトラストストアを設定します。

KafkaUser を作成すると、ユーザー (クライアント) を検証するためのキーと証明書を使用して <kafka_user_name> シークレットが作成されます。これらの資格証明を使用して、クライアントのキーストアを設定します。

mTLS を使用するように Kafka クラスターとクライアントをセットアップしたら、シークレットから認証情報を抽出し、それらをクライアント設定に追加します。

PEM キーと証明書

PEM の場合、クライアント設定に以下を追加します。

Truststore
  • <cluster_name>-cluster-ca-cert シークレットからの ca.crt。これは、クラスターの CA 証明書です。
キーストア
  • ユーザーの公開証明書である <kafka_user_name> シークレットからの user.crt。
  • ユーザーの秘密鍵である <kafka_user_name> シークレットの user.key。
PKCS #12 キーと証明書

PKCS #12 の場合、クライアント設定に以下を追加します。

Truststore
  • <cluster_name>-cluster-ca-cert シークレットからの ca.p12。これは、クラスターの CA 証明書です。
  • <cluster_name>-cluster-ca-cert シークレットの ca.password。これは、パブリッククラスター CA 証明書にアクセスするためのパスワードです。
キーストア
  • <kafka_user_name> シークレットからの user.p12。これは、ユーザーの公開鍵証明書です。
  • <kafka_user_name> シークレットの user.password。これは、Kafka ユーザーの公開鍵証明書にアクセスするためのパスワードです。

PKCS #12 は Java でサポートされているため、証明書の値を Java クライアント設定に直接追加できます。セキュアな保管場所から証明書を参照することもできます。PEM ファイルを使用する場合、証明書を単一行形式でクライアント設定に直接追加する必要があります。Kafka クラスターとクライアント間の TLS 接続の確立に適した形式を選択します。PEM に慣れていない場合は、PKCS #12 を使用してください。

注記

すべてのキーのサイズは 2048 ビットで、デフォルトでは、最初の生成から 365 日間有効です。有効期間は変更できます。

15.2.2. Cluster Operator で生成されたシークレット
リンクのコピー

Cluster Operator は、以下の証明書を生成します。これらの証明書は、OpenShift クラスターにシークレットとして保存されます。AMQ Streams はデフォルトでこれらのシークレットを使用します。

クラスター CA とクライアント CA には、秘密鍵と公開鍵に別々のシークレットがあります。

<cluster_name>-cluster-ca
クラスター CA の秘密鍵が含まれています。AMQ Streams および Kafka コンポーネントは、秘密鍵を使用してサーバー証明書に署名します。
<cluster_name>-cluster-ca-cert
クラスター CA の公開鍵が含まれています。Kafka クライアントは、公開鍵を使用して、TLS サーバー認証で接続している Kafka ブローカーの ID を確認します。
<cluster_name>-clients-ca
クライアント CA の秘密鍵が含まれています。Kafka クライアントは、秘密鍵を使用して、Kafka ブローカーに接続するときに mTLS 認証用の新しいユーザー証明書に署名します。
<cluster_name>-clients-ca-cert
クライアント CA の公開鍵が含まれています。mTLS 認証が使用されている場合、Kafka ブローカーは公開鍵を使用して、Kafka ブローカーにアクセスするクライアントの ID を確認します。

AMQ Streams コンポーネント間の通信のシークレットには、クラスター CA で署名された秘密鍵と公開鍵証明書が含まれています。

<cluster_name>-kafka-brokers
Kafka ブローカーの秘密鍵と公開鍵が含まれています。
<cluster_name>-zookeeper-nodes
ZooKeeper ノードの秘密鍵と公開鍵が含まれています。
<cluster_name>-cluster-operator-certs
Cluster Operator と Kafka または ZooKeeper 間の通信を暗号化するための秘密鍵と公開鍵が含まれています。
<cluster_name>-entity-topic-operator-certs
トピック Operator と Kafka または ZooKeeper 間の通信を暗号化するための秘密鍵と公開鍵が含まれています。
<cluster_name>-entity-user-operator-certs
ユーザー Operator と Kafka または ZooKeeper 間の通信を暗号化するための秘密鍵と公開鍵が含まれています。
<cluster_name>-cruise-control-certs
Cruise Control と Kafka または ZooKeeper の間の通信を暗号化するための秘密鍵と公開鍵が含まれています。
<cluster_name>-kafka-exporter-certs
Kafka Exporter と Kafka または ZooKeeper 間の通信を暗号化するための秘密鍵と公開鍵が含まれています。
注記

独自のサーバー証明書と秘密鍵を提供 して、クラスター CA によって署名された証明書ではなく、Kafka リスナー証明書 を使用して Kafka ブローカーに接続できます。

15.2.3. クラスター CA シークレット
リンクのコピー

クラスター CA シークレットは、Kafka クラスターの Cluster Operator によって管理されます。

<cluster_name>-cluster-ca-cert シークレットのみがクライアントに必要です。他のすべてのクラスターシークレットは AMQ Streams コンポーネントによってアクセスされます。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。

注記

TLS を介した Kafka ブローカーへの接続時に Kafka ブローカー証明書を検証するため、<cluster_name>-cluster-ca-cert の CA 証明書は Kafka クライアントアプリケーションによって信頼される必要があります。

Expand
表15.1 <cluster_name>-cluster-ca シークレットのフィールド
フィールド説明

ca.key

クラスター CA の現在の秘密鍵。

Expand
表15.2 <cluster_name>-cluster-ca-cert シークレットのフィールド
フィールド説明

ca.p12

証明書とキーを格納するための PKCS #12 ストア。

ca.password

PKCS #12 ストアを保護するためのパスワード。

ca.crt

クラスター CA の現在の証明書。

Expand
表15.3 <cluster_name>-kafka-brokers シークレットのフィールド
フィールド説明

<cluster_name>-kafka-<num>.p12

証明書とキーを格納するための PKCS #12 ストア。

<cluster_name>-kafka-<num>.password

PKCS #12 ストアを保護するためのパスワード。

<cluster_name>-kafka-<num>.crt

Kafka ブローカー Pod <num> の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

<cluster_name>-kafka-<num>.key

Kafka ブローカー Pod <num> の秘密鍵。

Expand
表15.4 <cluster_name>-zookeeper-nodes シークレットのフィールド
フィールド説明

<cluster_name>-zookeeper-<num>.p12

証明書とキーを格納するための PKCS #12 ストア。

<cluster_name>-zookeeper-<num>.password

PKCS #12 ストアを保護するためのパスワード。

<cluster_name>-zookeeper-<num>.crt

ZooKeeper ノード <num> の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

<cluster_name>-zookeeper-<num>.key

ZooKeeper Pod <num> の秘密鍵。

Expand
表15.5 <cluster_name>-cluster-operator-certs シークレットのフィールド
フィールド説明

cluster-operator.p12

証明書とキーを格納するための PKCS #12 ストア。

cluster-operator.password

PKCS #12 ストアを保護するためのパスワード。

cluster-operator.crt

Cluster Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

cluster-operator.key

Cluster Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。

Expand
表15.6 <cluster_name>-entity-topic-operator-certs シークレットのフィールド
フィールド説明

entity-operator.p12

証明書とキーを格納するための PKCS #12 ストア。

entity-operator.password

PKCS #12 ストアを保護するためのパスワード。

entity-operator.crt

トピック Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

entity-operator.key

トピック Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。

Expand
表15.7 <cluster_name>-entity-user-operator-certs シークレットのフィールド
フィールド説明

entity-operator.p12

証明書とキーを格納するための PKCS #12 ストア。

entity-operator.password

PKCS #12 ストアを保護するためのパスワード。

entity-operator.crt

ユーザー Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

entity-operator.key

ユーザー Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。

Expand
表15.8 <cluster_name>-cruise-control-certs シークレットのフィールド
フィールド説明

cruise-control.p12

証明書とキーを格納するための PKCS #12 ストア。

cruise-control.password

PKCS #12 ストアを保護するためのパスワード。

cruise-control.crt

Cruise Control と Kafka または ZooKeeper との間の mTLS 通信の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

cruise-control.key

Cruise Control と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。

Expand
表15.9 <cluster_name>-kafka-exporter-certs シークレットのフィールド
フィールド説明

kafka-exporter.p12

証明書とキーを格納するための PKCS #12 ストア。

kafka-exporter.password

PKCS #12 ストアを保護するためのパスワード。

kafka-exporter.crt

Kafka Exporter と Kafka または ZooKeeper との間の mTLS 通信の証明書。<cluster_name>-cluster-ca で現行または以前のクラスター CA の秘密鍵により署名されます。

kafka-exporter.key

Kafka Exporter と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。

15.2.4. クライアント CA シークレット
リンクのコピー

クライアント CA シークレットは、Kafka クラスターの Cluster Operator によって管理されます。

<cluster_name>-clients-ca-cert の証明書は、Kafka ブローカーが信頼する証明書です。

<cluster_name>-clients-ca シークレットは、クライアントアプリケーションの証明書の署名に使用されます。このシークレットは AMQ Streams コンポーネントにアクセスできる必要があり、ユーザー Operator を使わずにアプリケーション証明書を発行する予定であれば管理者のアクセス権限が必要です。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。

Expand
表15.10 <cluster_name>-clients-ca シークレットのフィールド
フィールド説明

ca.key

クライアント CA の現在の秘密鍵。

Expand
表15.11 <cluster_name>-clients-ca-cert シークレットのフィールド
フィールド説明

ca.p12

証明書とキーを格納するための PKCS #12 ストア。

ca.password

PKCS #12 ストアを保護するためのパスワード。

ca.crt

クライアント CA の現在の証明書。

15.2.5. User Operator によって生成されたユーザーシークレット
リンクのコピー

ユーザーシークレットは User Operator によって管理されます。

User Operator でユーザーが作成されると、ユーザーの名前を使用してシークレットが生成されます。

Expand
表15.12 user_name シークレットのフィールド
Secret 名Secret 内のフィールド説明

<user_name>

user.p12

証明書とキーを格納するための PKCS #12 ストア。

user.password

PKCS #12 ストアを保護するためのパスワード。

user.crt

ユーザーの証明書、クライアント CA により署名されます。

user.key

ユーザーの秘密鍵。

15.2.6. ラベルおよびアノテーションのクラスター CA シークレットへの追加
リンクのコピー

KafkaカスタムリソースでclusterCaCertテンプレートプロパティーを設定することで、クラスターオペレータが作成したクラスター CA シークレットにカスタムラベルやアノテーションを追加することができます。ラベルとアノテーションは、オブジェクトを特定し、コンテキスト情報を追加するのに便利です。AMQ Streams カスタムリソースでテンプレートプロパティーを設定します。

ラベルおよびアノテーションを Secret に追加するテンプレートのカスタマイズ例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    template:
      clusterCaCert:
        metadata:
          labels:
            label1: value1
            label2: value2
          annotations:
            annotation1: value1
            annotation2: value2
    # ...
Copy to Clipboard Toggle word wrap

15.2.7. CA シークレットでの ownerReference の無効化
リンクのコピー

デフォルトでは、クラスターおよびクライアント CA シークレットは、Kafka カスタムリソースに設定される ownerReference プロパティーで作成されます。つまり、Kafka カスタムリソースが削除されると、OpenShift によって CA シークレットも削除 (ガベッジコレクション) されます。

新しいクラスターで CA を再利用する場合は、Kafka設定でクラスターおよびクライアント CA シークレットの generateSecretOwnerReference プロパティーを false に設定して、ownerReference を無効にすることができます。ownerReference が無効な場合に、対応する Kafka カスタムリソースが削除されると、OpenShift では CA シークレットは削除されません。

クラスターおよびクライアント CA の ownerReference が無効になっている Kafka 設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
# ...
spec:
# ...
  clusterCa:
    generateSecretOwnerReference: false
  clientsCa:
    generateSecretOwnerReference: 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