16.2. Operator によって生成されたシークレット
Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または mTLS 認証を有効にする場合、他の TLS 証明書も設定されます。
シークレットは、Kafka や KafkaUser などのカスタムリソースがデプロイされるときに作成されます。Streams for Apache Kafka はこのシークレットを使用して、Kafka クラスター、クライアント、およびユーザーの秘密鍵と公開鍵の証明書を保存します。Secrets は、Kafka ブローカー間およびブローカーとクライアント間で TLS で暗号化された接続を確立するために使用されます。これらは mTLS 認証にも使用されます。
クラスターとクライアントのシークレットは常に、公開鍵と、秘密鍵のペアとなっています。
- クラスターシークレット
- クラスターシークレットには、Kafka ブローカー証明書に署名するためのクラスター CAが含まれています。接続するクライアントは、証明書を使用して、Kafka クラスターとの TLS 暗号化接続を確立します。証明書はブローカーのアイデンティティを確認します。
- クライアントシークレット
- クライアントシークレットには、ユーザーが独自のクライアント証明書に署名するためのクライアント CAが含まれています。これにより、Kafka クラスターに対する相互認証が可能になります。ブローカーは、証明書を使用してクライアントのアイデンティティを検証します。
- ユーザーシークレット
- ユーザーシークレットには、秘密鍵と証明書が含まれています。シークレットは、新しいユーザーの作成時にクライアント CA で作成され、署名されます。キーと証明書は、クラスターへのアクセス時にユーザーの認証および承認に使用されます。
TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーに Kafka リスナー証明書 を指定できます。Kafka リスナー証明書を使用して、既存のセキュリティーインフラストラクチャーを組み込みます。
16.2.1. PEM または PKCS #12 形式の鍵と証明書を使用した TLS 認証
Streams for Apache Kafka によって作成されたシークレットは、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 日間有効です。有効期間は変更できます。
16.2.2. Cluster Operator で生成されたシークレット
Cluster Operator は、以下の証明書を生成します。これらの証明書は、OpenShift クラスターにシークレットとして保存されます。Streams for Apache Kafka はデフォルトでこれらのシークレットを使用します。
クラスター CA とクライアント CA には、秘密鍵と公開鍵に別々のシークレットがあります。
<cluster_name>-cluster-ca- クラスター CA の秘密鍵が含まれています。Streams for Apache Kafka および 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 を確認します。
Streams for Apache Kafka コンポーネント間の通信用のシークレットには、クラスター 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- Topic 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 ブローカーに接続できます。
16.2.3. クラスター CA シークレット
クラスター CA シークレットは、Kafka クラスターの Cluster Operator によって管理されます。
<cluster_name>-cluster-ca-cert シークレットのみがクライアントに必要です。その他のすべてのクラスターシークレットは、Streams for Apache Kafka コンポーネントによってアクセスされます。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。
TLS を介した Kafka ブローカーへの接続時に Kafka ブローカー証明書を検証するため、<cluster_name>-cluster-ca-cert の CA 証明書は Kafka クライアントアプリケーションによって信頼される必要があります。
| フィールド | 説明 |
|---|---|
|
| クラスター CA の現在の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
| クラスター CA の現在の証明書。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
Kafka ブローカー Pod <num> の証明書。 |
|
|
Kafka ブローカー Pod |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
ZooKeeper ノード <num> の証明書。 |
|
|
ZooKeeper Pod |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
Cluster Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。 |
|
| Cluster Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
Topic Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。 |
|
| Topic Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
ユーザー Operator と Kafka または ZooKeeper との間の mTLS 通信の証明書。 |
|
| ユーザー Operator と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
Cruise Control と Kafka または ZooKeeper との間の mTLS 通信の証明書。 |
|
| Cruise Control と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
|
Kafka Exporter と Kafka または ZooKeeper との間の mTLS 通信の証明書。 |
|
| Kafka Exporter と Kafka または ZooKeeper との間の mTLS 通信の秘密鍵。 |
16.2.4. クライアント CA シークレット
クライアント CA シークレットは、Kafka クラスターの Cluster Operator によって管理されます。
<cluster_name>-clients-ca-cert の証明書は、Kafka ブローカーが信頼する証明書です。
<cluster_name>-clients-ca シークレットは、クライアントアプリケーションの証明書の署名に使用されます。このシークレットには、Streams for Apache Kafka コンポーネントからアクセスできる必要があります。User Operator を使用せずにアプリケーション証明書を発行する予定の場合は、管理アクセス権からもアクセスできる必要があります。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。
| フィールド | 説明 |
|---|---|
|
| クライアント CA の現在の秘密鍵。 |
| フィールド | 説明 |
|---|---|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 |
|
| クライアント CA の現在の証明書。 |
16.2.5. User Operator によって生成されたユーザーシークレット
ユーザーシークレットは User Operator によって管理されます。
User Operator でユーザーが作成されると、ユーザーの名前を使用してシークレットが生成されます。
| Secret 名 | Secret 内のフィールド | 説明 |
|---|---|---|
|
|
| 証明書とキーを格納するための PKCS #12 ストア。 |
|
| PKCS #12 ストアを保護するためのパスワード。 | |
|
| ユーザーの証明書、クライアント CA により署名されます。 | |
|
| ユーザーの秘密鍵。 |
16.2.6. ラベルおよびアノテーションのクラスター CA シークレットへの追加
Kafka カスタムリソースで clusterCaCert テンプレートプロパティーを設定することで、Cluster Operator によって作成された Cluster CA シークレットにカスタムラベルとアノテーションを追加できます。ラベルとアノテーションは、オブジェクトを特定し、コンテキスト情報を追加するのに便利です。テンプレートプロパティーは、Streams for Apache Kafka カスタムリソースで設定します。
ラベルおよびアノテーションを 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
# ...
16.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
# ...
