第11章 TLS 証明書の管理
AMQ Streams は、Kafka と AMQ Streams コンポーネントとの間で TLS プロトコルを使用して暗号化された通信をサポートします。Kafka ブローカー間の通信 (Interbroker 通信)、ZooKeeper ノード間の通信 (Internodal 通信)、およびこれらと AMQ Streams Operator 間の通信は、常に暗号化されます。Kafka クライアントと Kafka ブローカーとの間の通信は、クラスターが設定された方法に応じて暗号化されます。Kafka および AMQ Streams コンポーネントでは、TLS 証明書も認証に使用されます。
Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または TLS 認証を有効にする場合、他の TLS 証明書も設定されます。ユーザーが用意した証明書は更新されません。
TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は、「Kafka リスナー証明書」 を参照してください。
図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 証明書と秘密鍵をインストールする方法について説明します。
以下の手順を使用して、独自のクラスターまたはクライアント CA 証明書をインストールできます。
この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。
前提条件
- Cluster Operator が稼働している必要があります。
- Kafka クラスターがデプロイされていない必要があります。
クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。
ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。
- クラスターまたはクライアント CA
- 1 つ以上の中間 CA
- ルート CA
- チェーン内のすべての CA は、X509v3 の基本制約 (Basic Constraint) で CA として設定する必要があります。
手順
CA 証明書を対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はCLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はCLUSTER-NAME-clients-ca-cert
になります。「Not Exists」エラーを無視します。
新規シークレットを作成およびラベル付けします。
oc create secret generic CA-CERTIFICATE-SECRET --from-file=ca.crt=CA-CERTIFICATE-FILENAME
CA キーを対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-KEY-SECRET
CA-KEY-SECRET は CA 鍵の名前です。これは、クラスター CA 鍵の場合は
CLUSTER-NAME-cluster-ca
、クライアント CA 鍵の場合はCLUSTER-NAME-clients-ca
になります。新規シークレットを作成します。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
strimzi.io/kind=Kafka
およびstrimzi.io/cluster=CLUSTER-NAME
というラベルをシークレットに付けます。oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
クラスターの
Kafka
リソースを作成し、生成された CA を使用 しない ようにKafka.spec.clusterCa
およびKafka.spec.clientsCa
オブジェクトを設定します。独自指定の証明書を使用するようにクラスター CA を設定する
Kafka
リソースの例 (抜粋)kind: Kafka version: kafka.strimzi.io/v1beta2 spec: # ... clusterCa: generateCertificateAuthority: false
その他のリソース
- 以前インストールした CA 証明書を更新する場合は 「独自の CA 証明書の更新」 を参照してください。
- 「独自の Kafka リスナー証明書の指定」
11.2. Secret
AMQ Streams は Secret を使用して、Kafka クラスターコンポーネントおよびクライアントの秘密鍵および証明書を格納します。Secrets は、Kafka ブローカー間およびブローカーとクライアント間で TLS で暗号化された接続を確立するために使用されます。Secret は相互 TLS 認証にも使用されます。
- Cluster Secret には、Kafka ブローカー証明書に署名するためのクラスター CA 証明書が含まれます。また、接続クライアントによって、Kafka クラスターとの TLS 暗号化接続を確立してブローカー ID を検証するために使用されます。
- Client Secret にはクライアント CA 証明書が含まれ、これによりユーザーは独自のクライアント証明書に署名し、Kafka クラスターに対する相互認証が可能になります。ブローカーはクライアント CA 証明書を使用してクライアント ID を検証します。
- User Secret には、新規ユーザーの作成時にクライアント CA 証明書によって生成および署名される秘密鍵と証明書が含まれています。この鍵と証明書は、クラスターへのアクセス時の認証および承認に使用されます。
Secret には、PEM 形式および PKCS #12 形式の秘密鍵と証明書が含まれます。PEM 形式の秘密鍵と証明書を使用する場合、ユーザーは Secret からそれらの秘密鍵と証明書を取得し、Java アプリケーションで使用するために対応するトラストストア (またはキーストア) を生成します。PKCS #12 ストレージは、直接使用できるトラストストア (またはキーストア) を提供します。
すべての鍵のサイズは 2048 ビットです。
11.2.1. PKCS #12 ストレージ
PKCS #12 は、暗号化オブジェクトをパスワードで保護された単一のファイルに格納するためのアーカイブファイル形式 (.p12
) を定義します。PKCS #12 を使用して、証明書および鍵を一元的に管理できます。
各 Secret には、PKCS #12 特有のフィールドが含まれています。
-
.p12
フィールドには、証明書と鍵が含まれます。 -
.password
フィールドは、アーカイブを保護するパスワードです。
11.2.2. クラスター CA Secret
以下の表は、Kafka クラスターの Cluster Operator によって管理される Cluster Secret を表しています。
<cluster>-cluster-ca-cert
Secret のみがクライアントによって使用される必要があります。表に記載されているそれ以外の Secrets
はすべて AMQ Streams コンポーネントによるアクセスのみが必要です。これは、必要な場合に OpenShift のロールベースアクセス制御を使用して強制できます。
フィールド | 説明 |
---|---|
| クラスター CA の現在の秘密鍵。 |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
| クラスター CA の現在の証明書。 |
TLS を介した Kafka ブローカーへの接続時に Kafka ブローカー証明書を検証するため、<cluster>-cluster-ca-cert
の CA 証明書は Kafka クライアントアプリケーションによって信頼される必要があります。
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
Kafka ブローカー Pod <num> の証明書。 |
|
Kafka ブローカー Pod |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
ZooKeeper ノード <num> の証明書。 |
|
ZooKeeper Pod |
フィールド | 説明 |
---|---|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 |
|
Entity Operator と Kafka または ZooKeeper との間の TLS 通信の証明書。 |
| Entity Operator と、Kafka または ZooKeeper との間の TLS 通信の秘密鍵。 |
11.2.3. クライアント CA Secret
Secret 名 | Secret 内のフィールド | 説明 |
---|---|---|
|
| クライアント CA の現在の秘密鍵。 |
|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 | |
| クライアント CA の現在の証明書。 |
<cluster>-clients-ca-cert
の証明書は、Kafka ブローカーが信頼する証明書です。
<cluster>-clients-ca
は、クライアントアプリケーションの証明書への署名に使用されます。また AMQ Streams コンポーネントにアクセスできる必要があり、User Operator を使わずにアプリケーション証明書を発行する予定であれば管理者のアクセス権限が必要です。これは、必要な場合に OpenShift のロールベースのアクセス制御を使用して強制できます。
11.2.4. ラベルおよびアノテーションの Secret への追加
Kafka
カスタムリソースの clusterCaCert
テンプレートプロパティーを設定すると、カスタムラベルとアノテーションを Cluster Operator によって作成された Cluster CA Secret に追加できます。ラベルとアノテーションは、オブジェクトを特定し、コンテキスト情報を追加するのに便利です。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 # ...
テンプレートプロパティーの設定に関する詳細は、「OpenShift リソースのカスタマイズ」 を参照してください。
11.2.5. CA Secret での ownerReference
の無効化
デフォルトでは、クラスターおよびクライアント CA Secret は、Kafka
カスタムリソースに設定される ownerReference
プロパティーで作成されます。つまり、Kafka
カスタムリソースが削除されると、OpenShift によって CA Secret も削除 (ガベッジコレクション) されます。
新しいクラスターに CA を再利用する場合は、Kafka
設定で Cluster および Client CA Secret の generateSecretOwnerReference
プロパティーを false
に設定して、ownerReference
を無効にすることができます。ownerReference
を無効にすると、対応する Kafka
カスタムリソースが削除されても、CA Secret は OpenShift によって削除されません。
クラスターおよびクライアント CA の ownerReference
が無効になっている Kafka 設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: # ... clusterCa: generateSecretOwnerReference: false clientsCa: generateSecretOwnerReference: false # ...
その他のリソース
11.2.6. User Secret
Secret 名 | Secret 内のフィールド | 説明 |
---|---|---|
|
| 証明書および鍵を格納するための PKCS #12 アーカイブファイル。 |
| PKCS #12 アーカイブのファイルを保護するパスワード。 | |
| ユーザーの証明書、クライアント CA により署名されます。 | |
| ユーザーの秘密鍵。 |
11.3. 証明書の更新および有効期間
クラスター CA およびクライアント CA の証明書は、限定された期間、すなわち有効期間に限り有効です。通常、この期間は証明書の生成からの日数として定義されます。
Cluster Operator によって自動作成される CA 証明書の場合、以下の有効期間を設定できます。
-
クラスター CA 証明書の場合:
Kafka.spec.clusterCa.validityDays
-
クライアント CA 証明書の場合:
Kafka.spec.clientsCa.validityDays
デフォルトの有効期間は、両方の証明書で 365 日です。手動でインストールした CA 証明書には、独自の有効期間が定義されている必要があります。
CA 証明書の期限が切れると、その証明書を信頼しているコンポーネントおよびクライアントは、その CA 秘密鍵で署名された証明書を持つ相手からの TLS 接続を受け入れません。代わりに、コンポーネントおよびクライアントは 新しい CA 証明書を信頼する必要があります。
サービスを中断せずに CA 証明書を更新できるようにするため、Cluster Operator は古い CA 証明書が期限切れになる前に証明書の更新を開始します。
Cluster Operator によって作成される証明書の更新期間を設定できます。
-
クラスター CA 証明書の場合:
Kafka.spec.clusterCa.renewalDays
-
クライアント CA 証明書の場合:
Kafka.spec.clientsCa.renewalDays
デフォルトの更新期間は、両方の証明書とも 30 日です。
更新期間は、現在の証明書の有効期日から逆算されます。
更新期間に対する有効期間
Not Before Not After | | |<--------------- validityDays --------------->| <--- renewalDays --->|
Kafka クラスターの作成後に有効期間および更新期間を変更するには、Kafka
カスタムリソースを設定および適用し、CA 証明書を手動で更新 します。証明書を手動で更新しないと、証明書が次回自動更新される際に新しい期間が使用されます。
証明書の有効および更新期間の Kafka 設定例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka # ... spec: # ... clusterCa: renewalDays: 30 validityDays: 365 generateCertificateAuthority: true clientsCa: renewalDays: 30 validityDays: 365 generateCertificateAuthority: true # ...
更新期間中の Cluster Operator の動作は、証明書生成プロパティー generateCertificateAuthority
および generateCertificateAuthority
の設定によって異なります。
true
-
プロパティーが
true
に設定されている場合、CA 証明書は Cluster Operator によって自動的に生成され、更新期間内に自動的に更新されます。 false
-
プロパティーが
false
に設定されている場合、CA 証明書は Cluster Operator によって生成されません。独自の証明書をインストールする場合は、このオプションを使用します。
11.3.1. 自動生成された CA 証明書での更新プロセス
Cluster Operator は以下のプロセスを実行して CA 証明書を更新します。
-
新しい CA 証明書を生成しますが、既存の鍵は保持します。該当する
Secret
内のca.crt
という名前の古い証明書が新しい証明書に置き換えられます。 - 新しいクライアント証明書を生成します (ZooKeeper ノード、Kafka ブローカー、および Entity Operator 用)。署名鍵は変わっておらず、CA 証明書と同期してクライアント証明書の有効期間を維持するため、これは必須ではありません。
- ZooKeeper ノードを再起動して、ZooKeeper ノードが新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
- Kafka ブローカーを再起動して、Kafka ブローカーが新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
- Topic Operator および User Operator を再起動して、それらの Operator が新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。
11.3.2. クライアント証明書の更新
Cluster Operator は、Kafka クラスターを使用するクライアントアプリケーションを認識しません。
クラスターに接続し、クライアントアプリケーションが正しく機能するように確認するには、クライアントアプリケーションは以下を行う必要があります。
- <cluster>-cluster-ca-cert Secret でパブリッシュされるクラスター CA 証明書を信頼する必要があります。
<user-name> Secret でパブリッシュされたクレデンシャルを使用してクラスターに接続します。
User Secret は PEM および PKCS #12 形式のクレデンシャルを提供し、SCRAM-SHA 認証を使用する場合はパスワードを提供できます。ユーザーの作成時に User Operator によってユーザークレデンシャルが生成されます。
証明書の更新後もクライアントが動作するようにする必要があります。更新プロセスは、クライアントの設定によって異なります。
クライアント証明書と鍵のプロビジョニングを手動で行う場合、新しいクライアント証明書を生成し、更新期間内に新しい証明書がクライアントによって使用されるようにする必要があります。更新期間の終了までにこれが行われないと、クライアントアプリケーションがクラスターに接続できなくなる可能性があります。
同じ OpenShift クラスターおよび namespace 内で実行中のワークロードの場合、Secrets はボリュームとしてマウントできるので、クライアント Pod はそれらのキーストアとトラストストアを現在の状態の Secrets から構築できます。この手順の詳細は、「クラスター CA を信頼する内部クライアントの設定」を参照してください。
11.3.3. Cluster Operator によって生成される CA 証明書の手動更新
Cluster Operator によって生成されるクラスターおよびクライアント CA 証明書は、各証明書の更新期間の開始時に自動更新されます。ただし、strimzi.io/force-renew
アノテーションを使用すると、証明書の更新期間が始まる前に、これらの証明書のいずれかまたは両方を手動で更新できます。セキュリティー上の理由や、証明書の更新または有効期間を変更した 場合などに、自動更新を行うことがあります。
更新された証明書は、更新前の証明書と同じ秘密鍵を使用します。
独自の CA 証明書を使用している場合は、force-renew
アノテーションを使用できません。代わりに、独自の CA 証明書を更新する手順に従ってください。
前提条件
- Cluster Operator が稼働している必要があります。
- CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。
手順
strimzi.io/force-renew
アノテーションを、更新対象の CA 証明書が含まれるSecret
に適用します。表11.8 証明書の更新を強制する Secret のアノテーション。 証明書 Secret annotate コマンド クラスター CA
KAFKA-CLUSTER-NAME-cluster-ca-cert
oc annotate secret KAFKA-CLUSTER-NAME-cluster-ca-cert strimzi.io/force-renew=true
クライアント CA
KAFKA-CLUSTER-NAME-clients-ca-cert
oc annotate secret KAFKA-CLUSTER-NAME-clients-ca-cert strimzi.io/force-renew=true
次回の調整で、アノテーションを付けた
Secret
の新規 CA 証明書が Cluster Operator によって生成されます。メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新規 CA 証明書が生成されます。Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。
CA 証明書が有効である期間を確認します。
たとえば、以下のように
openssl
コマンドを使用します。oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d | openssl x509 -subject -issuer -startdate -enddate -noout
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はKAFKA-CLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はKAFKA-CLUSTER-NAME-clients-ca-cert
になります。CA-CERTIFICATE は CA 証明書の名前です (例:
jsonpath={.data.ca\.crt}
)。このコマンドは、CA 証明書の有効期間である
notBefore
およびnotAfter
の日付を返します。たとえば、クラスター CA 証明書の場合は以下のようになります。
subject=O = io.strimzi, CN = cluster-ca v0 issuer=O = io.strimzi, CN = cluster-ca v0 notBefore=Jun 30 09:43:54 2020 GMT notAfter=Jun 30 09:43:54 2021 GMT
Secret から古い証明書を削除します。
コンポーネントで新しい証明書が使用される場合でも、古い証明書がアクティブであることがあります。古い証明書を削除して、潜在的なセキュリティーリスクを取り除きます。
11.3.4. Cluster Operator によって生成された CA 証明書によって使用される秘密鍵の置き換え
Cluster Operator によって生成されるクラスター CA およびクライアント CA 証明書によって使用される秘密鍵を置換できます。秘密鍵が交換されると、Cluster Operator によって新しい秘密鍵の新しい CA 証明書が生成されます。
独自の CA 証明書を使用している場合は、force-replace
アノテーションは使用できません。代わりに、独自の CA 証明書を更新する手順に従ってください。
前提条件
- Cluster Operator が稼働している必要があります。
- CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。
手順
strimzi.io/force-replace
アノテーションを、更新対象の秘密鍵が含まれるSecret
に適用します。表11.9 秘密鍵を置き換えるコマンド 秘密鍵 Secret annotate コマンド クラスター CA
CLUSTER-NAME-cluster-ca
oc annotate secret CLUSTER-NAME-cluster-ca strimzi.io/force-replace=true
クライアント CA
CLUSTER-NAME-clients-ca
oc annotate secret CLUSTER-NAME-clients-ca strimzi.io/force-replace=true
次回の調整時に、Cluster Operator は以下を生成します。
-
アノテーションを付けた
Secret
の新しい秘密鍵 - 新規 CA 証明書
メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新しい秘密鍵と CA 証明書が生成されます。
Cluster Operator によって更新されたクラスターおよびクライアント CA 証明書をクライアントアプリケーションがリロードする必要があります。
その他のリソース
11.3.5. 独自の CA 証明書の更新
この手順では、Cluster Operator によって生成される証明書を使用せずに、独自にインストールした CA 証明書および鍵を更新する方法を説明します。
独自の証明書を使用している場合、Cluster Operator は自動的に更新されません。したがって、期限切れ間近の CA 証明書を交換するために、証明書の更新期間中にこの手順を実行することが重要になります。
この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。
前提条件
- Cluster Operator が稼働している必要があります。
- 独自の CA 証明書と秘密鍵がインストールされている必要があります。
- クラスターおよびクライアントの PEM 形式による新しい X.509 証明書と鍵が必要です。
これらは、openssl
コマンドを使用して以下のように生成できます。
openssl req -x509 -new -days NUMBER-OF-DAYS-VALID --nodes -out ca.crt -keyout ca.key
手順
Secret
で、現在の CA 証明書の詳細を確認します。oc describe secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は
Secret
の名前です。これは、クラスター CA 証明書の場合はKAFKA-CLUSTER-NAME-cluster-ca-cert
、クライアント CA 証明書の場合はKAFKA-CLUSTER-NAME-clients-ca-cert
になります。シークレットに既存の CA 証明書が含まれるディレクトリーを作成します。
mkdir new-ca-cert-secret cd new-ca-cert-secret
更新する各 CA 証明書のシークレットを取得します。
oc get secret CA-CERTIFICATE-SECRET -o 'jsonpath={.data.CA-CERTIFICATE}' | base64 -d > CA-CERTIFICATE
CA-CERTIFICATE を各 CA 証明書の名前に置き換えます。
古い
ca.crt
ファイルの名前をca-DATE.crt
に変更します。ここで DATE は、YEAR-MONTH-DAYTHOUR-MINUTE-SECONDZ 形式で表した証明書の有効期限日に置き換えます。たとえば、
ca-2018-09-27T17-32-00Z.crt
のようになります。mv ca.crt ca-$(date -u -d$(openssl x509 -enddate -noout -in ca.crt | sed 's/.*=//') +'%Y-%m-%dT%H-%M-%SZ').crt
新しい CA 証明書をディレクトリーにコピーし、
ca.crt
という名前を付けます。cp PATH-TO-NEW-CERTIFICATE ca.crt
CA 証明書を対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-CERTIFICATE-SECRET
CA-CERTIFICATE-SECRET は、最初のステップで返された、
Secret
の名前です。「Not Exists」エラーを無視します。
シークレットを再作成します。
oc create secret generic CA-CERTIFICATE-SECRET --from-file=.
作成したディレクトリーを削除します。
cd .. rm -r new-ca-cert-secret
CA キーを対象の
Secret
に配置します。既存のシークレットを削除します。
oc delete secret CA-KEY-SECRET
CA-KEY-SECRET は CA 鍵の名前です。これは、クラスター CA 鍵の場合は
KAFKA-CLUSTER-NAME-cluster-ca
、クライアント CA 鍵の場合はKAFKA-CLUSTER-NAME-clients-ca
になります。新しい CA 鍵でシークレットを再作成します。
oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
strimzi.io/kind=Kafka
およびstrimzi.io/cluster=KAFKA-CLUSTER-NAME
というラベルをシークレットに付けます。oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=KAFKA-CLUSTER-NAME oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=KAFKA-CLUSTER-NAME
11.4. TLS 接続
11.4.1. ZooKeeper の通信
すべてのポート上の ZooKeeper ノード間の通信と、クライアントと ZooKeeper 間の通信は暗号化されます。
11.4.2. Kafka のブローカー間の通信
Kafka ブローカー間の通信は、ポート 9091 の内部リスナーを介して行われます。この通信はデフォルトで暗号化され、Kafka クライアントへはアクセスできません。
Kafka ブローカーと ZooKeeper ノード間の通信も暗号化されます。
11.4.3. Topic Operator および User Operator
すべての Operator は、Kafka と ZooKeeper 両方との通信に暗号化を使用します。Topic Operator および User Operator では、ZooKeeper との通信時に TLS サイドカーが使用されます。
11.4.4. Cruise Control
Cruise Control は、Kafka と ZooKeeper 両方との通信に暗号化を使用します。TLS サイドカーは、ZooKeeper との通信時に使用されます。
11.4.5. Kafka クライアント接続
Kafka ブローカーとクライアント間の暗号化または非暗号化通信は、spec.kafka.listeners
の tls
プロパティーを使用して設定されます。
11.5. クラスター CA を信頼する内部クライアントの設定
この手順では、TLS リスナーに接続する OpenShift クラスター内部に存在する Kafka クライアントがクラスター CA 証明書を信頼するように設定する方法を説明します。
これを内部クライアントで実現するには、ボリュームマウントを使用して、必要な証明書と鍵が含まれる Secrets
にアクセスするのが最も簡単な方法です。
以下の手順に従い、クラスター CA によって署名された信頼できる証明書を Java ベースの Kafka Producer、Consumer、および Streams API に設定します。
クラスター CA の証明書の形式が PKCS #12 (.p12
) または PEM (.crt
) であるかに応じて、手順を選択します。
この手順では、Kafka クラスターの ID を検証する Cluster Secret をクライアント Pod にマウントする方法を説明します。
前提条件
- Cluster Operator が稼働している必要があります。
-
OpenShift クラスター内に
Kafka
リソースが必要です。 - TLS を使用して接続し、クラスター CA 証明書を必ず信頼する Kafka クライアントアプリケーションが、OpenShift クラスター内部に必要です。
-
クライアントアプリケーションが
Kafka
リソースと同じ namespace で実行している必要があります。
PKCS #12 形式 (.p12) の使用
クライアント Pod の定義時に、Cluster Secret をボリュームとしてマウントします。
以下に例を示します。
kind: Pod apiVersion: v1 metadata: name: client-pod spec: containers: - name: client-name image: client-name volumeMounts: - name: secret-volume mountPath: /data/p12 env: - name: SECRET_PASSWORD valueFrom: secretKeyRef: name: my-secret key: my-password volumes: - name: secret-volume secret: secretName: my-cluster-cluster-ca-cert
ここでは、以下をマウントしています。
- PKCS #12 ファイルを設定可能な正確なパスにマウント。
- パスワードを Java 設定に使用できる環境変数にマウント。
Kafka クライアントを以下のプロパティーで設定します。
セキュリティープロトコルのオプション:
-
security.protocol: SSL
(TLS 認証ありまたはなしで、暗号化に TLS を使用する場合)。 -
security.protocol: SASL_SSL
(TLS 経由で SCRAM-SHA 認証を使用する場合)。
-
-
ssl.truststore.location
(証明書がインポートされたトラストストアを指定)。 -
ssl.truststore.password
(トラストストアにアクセスするためのパスワードを指定)。 -
ssl.truststore.type=PKCS12
(トラストストアのタイプを識別)。
PEM 形式の使用 (.crt)
クライアント Pod の定義時に、Cluster Secret をボリュームとしてマウントします。
以下に例を示します。
kind: Pod apiVersion: v1 metadata: name: client-pod spec: containers: - name: client-name image: client-name volumeMounts: - name: secret-volume mountPath: /data/crt volumes: - name: secret-volume secret: secretName: my-cluster-cluster-ca-cert
- X.509 形式の証明書を使用するクライアントでこの証明書を使用します。
11.6. クラスター CA を信頼する外部クライアントの設定
この手順では、external
リスナーに接続する OpenShift クラスター外部に存在する Kafka クライアントがクラスター CA 証明書を信頼するように設定する方法を説明します。クライアントのセットアップ時および更新期間中に、古いクライアント CA 証明書を交換する場合は、以下の手順に従います。
以下の手順に従い、クラスター CA によって署名された信頼できる証明書を Java ベースの Kafka Producer、Consumer、および Streams API に設定します。
クラスター CA の証明書の形式が PKCS #12 (.p12
) または PEM (.crt
) であるかに応じて、手順を選択します。
この手順では、Kafka クラスターの ID を検証する Cluster Secret から証明書を取得する方法を説明します。
CA 証明書の更新期間中に、<cluster-name>-cluster-ca-cert
Secret
に複数の CA 証明書が含まれます。クライアントは、それらを すべて をクライアントのトラストストアに追加する必要があります。
前提条件
- Cluster Operator が稼働している必要があります。
-
OpenShift クラスター内に
Kafka
リソースが必要です。 - TLS を使用して接続し、クラスター CA 証明書を必ず信頼する Kafka クライアントアプリケーションが、OpenShift クラスター外部に必要です。
PKCS #12 形式 (.p12) の使用
生成された
<cluster-name>-cluster-ca-cert
Secret から、クラスター CA 証明書およびパスワードを抽出します。oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.p12}' | base64 -d > ca.p12
oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.password}' | base64 -d > ca.password
Kafka クライアントを以下のプロパティーで設定します。
セキュリティープロトコルのオプション:
-
security.protocol: SSL
(TLS 認証ありまたはなしで、暗号化に TLS を使用する場合)。 -
security.protocol: SASL_SSL
(TLS 経由で SCRAM-SHA 認証を使用する場合)。
-
-
ssl.truststore.location
(証明書がインポートされたトラストストアを指定)。 -
ssl.truststore.password
(トラストストアにアクセスするためのパスワードを指定)。このプロパティーは、トラストストアで必要なければ省略できます。 -
ssl.truststore.type=PKCS12
(トラストストアのタイプを識別)。
PEM 形式の使用 (.crt)
生成された
<cluster-name>-cluster-ca-cert
Secret から、クラスター CA 証明書を抽出します。oc get secret <cluster-name>-cluster-ca-cert -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt
- X.509 形式の証明書を使用するクライアントでこの証明書を使用します。
11.7. Kafka リスナー証明書
以下のタイプのリスナーに、独自のサーバー証明書と秘密鍵を指定できます。
- OpenShift クラスター内で通信するための内部 TLS リスナー
-
Kafka クライアントと Kafka ブローカー間の通信に TLS 暗号化が有効になっている外部リスナー (
route
、loadbalancer
、ingress
、およびnodeport
タイプ)
これらのユーザー提供による証明書は、Kafka リスナー証明書 と呼ばれます。
外部リスナーに Kafka リスナー証明書を提供すると、既存のセキュリティーインフラストラクチャー (所属組織のプライベート CA やパブリック CA など) を利用できます。Kafka クライアントは Kafka ブローカーに接続する際に、クラスター CA またはクライアント CA によって署名された証明書ではなく、Kafka リスナー証明書を使用します。
Kafka リスナー証明書の更新が必要な場合は、手作業で更新する必要があります。
11.7.1. 独自の Kafka リスナー証明書の指定
この手順では、独自の秘密鍵と Kafka リスナー証明書と呼ばれるサーバー証明書を使用するようにリスナーを設定する方法について説明します。
Kafka ブローカーの ID を検証するため、クライアントアプリケーションは CA 公開鍵を信頼できる証明書として使用する必要があります。
前提条件
- OpenShift クラスターが必要です。
- Cluster Operator が稼働している必要があります。
リスナーごとに、外部 CA によって署名された互換性のあるサーバー証明書が必要です。
- X.509 証明書を PEM 形式で提供します。
- リスナーごとに正しい SAN (サブジェクト代替名) を指定します。詳細は、「Kafka リスナーのサーバー証明書の SAN」 を参照してください。
- 証明書ファイルに CA チェーン全体が含まれる証明書を提供できます。
手順
秘密鍵およびサーバー証明書が含まれる
Secret
を作成します。oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
クラスターの
Kafka
リソースを編集します。Secret
、証明書ファイル、および秘密鍵ファイルを使用するように、リスナーをconfiguration.brokerCertChainAndKey
プロパティーで設定します。TLS 暗号化が有効な
loadbalancer
外部リスナーの設定例# ... listeners: - name: plain port: 9092 type: internal tls: false - name: external port: 9094 type: loadbalancer tls: true authentication: type: tls configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
TLS リスナーの設定例
# ... listeners: - name: plain port: 9092 type: internal tls: false - name: tls port: 9093 type: internal tls: true authentication: type: tls configuration: brokerCertChainAndKey: secretName: my-secret certificate: my-listener-certificate.crt key: my-listener-key.key # ...
新しい設定を適用してリソースを作成または更新します。
oc apply -f kafka.yaml
Cluster Operator は、Kafka クラスターのローリングアップデートを開始し、これによりリスナーの設定が更新されます。
注記TLS または外部リスナーによってすでに使用されている
Secret
の Kafka リスナー証明書を更新した場合でも、ローリングアップデートが開始されます。
11.7.2. Kafka リスナーのサーバー証明書の SAN
独自の Kafka リスナー証明書で TLS ホスト名検証を使用するには、リスナーごとに SAN (サブジェクト代替名) を使用する必要があります。証明書の SAN は、以下のホスト名を指定する必要があります。
- クラスターのすべての Kafka ブローカー
- Kafka クラスターブートストラップサービス
ワイルドカード証明書は、CA でサポートされれば使用できます。
11.7.2.1. TLS リスナー SAN の例
以下の例を利用して、TLS リスナーの証明書で SAN のホスト名を指定できます。
ワイルドカードの例
//Kafka brokers *.<cluster-name>-kafka-brokers *.<cluster-name>-kafka-brokers.<namespace>.svc // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
ワイルドカードのない例
// Kafka brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers <cluster-name>-kafka-0.<cluster-name>-kafka-brokers.<namespace>.svc <cluster-name>-kafka-1.<cluster-name>-kafka-brokers <cluster-name>-kafka-1.<cluster-name>-kafka-brokers.<namespace>.svc # ... // Bootstrap service <cluster-name>-kafka-bootstrap <cluster-name>-kafka-bootstrap.<namespace>.svc
11.7.2.2. 外部リスナー SAN の例
TLS 暗号化が有効になっている外部リスナーの場合、証明書に指定する必要があるホスト名は、外部リスナーの type
によって異なります。
外部リスナータイプ | SAN で指定する内容 |
---|---|
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
| Kafka ブローカー Pod がスケジュールされるすべての OpenShift ワーカーノードのアドレス。 一致するワイルドカード名を使用できます。 |
その他のリソース