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

17.3. 証明書の更新および有効期間

クラスター CA およびクライアント CA の証明書は、限定された期間、すなわち有効期間に限り有効です。通常、この期間は証明書の生成からの日数として定義されます。

Cluster Operator によって自動的に作成される CA 証明書には、kafka リソースで次のプロパティーを使用して、証明書の有効期間を設定します。

  • Kafka.spec.clusterCa.validityDays (クラスター CA 証明書用)
  • Kafka.spec.clientsCa.validityDays (クライアント CA 証明書用)

デフォルトの有効期間は、両方の証明書で 365 日です。手動でインストールした CA 証明書には、独自の有効期間が定義されている必要があります。

CA 証明書の期限が切れると、その証明書を信頼しているコンポーネントおよびクライアントは、その CA 秘密鍵で署名された証明書を持つ相手からの接続を受け入れなくなります。代わりに、コンポーネントおよびクライアントは 新しい CA 証明書を信頼する必要があります。

サービスを中断せずに CA 証明書を更新できるようにするため、Cluster Operator は古い CA 証明書が期限切れになる前に証明書の更新を開始します。

kafka リソースで次のプロパティーを使用して、Cluster Operator によって作成された証明書の更新期間を設定します。

  • Kafka.spec.clusterCa.renewalDays (クラスター CA 証明書用)
  • Kafka.spec.clientsCa.renewalDays (クライアント CA 証明書用)

デフォルトの更新期間は、両方の証明書とも 30 日です。

更新期間は、現在の証明書の有効期日から逆算されます。

更新期間に対する有効期間

Not Before                                     Not After
    |                                              |
    |<--------------- validityDays --------------->|
                              <--- renewalDays --->|
Copy to Clipboard

都合の良い時間に更新期間をスケジュールするには、メンテナンス時間枠 を使用します。

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
# ...
Copy to Clipboard

更新期間中の Cluster Operator の動作は、クラスター CA およびクライアント CA の generateCertificateAuthority 証明書生成プロパティーの設定によって異なります。

true
プロパティーが true に設定されている場合、CA 証明書は Cluster Operator によって自動的に生成され、更新期間内に自動的に更新されます。
false
プロパティーが false に設定されている場合、CA 証明書は Cluster Operator によって生成されません。独自の証明書をインストールする 場合は、このオプションを使用します。

17.3.1. 自動生成された CA 証明書の更新

CA 証明書を更新する時間になると、Cluster Operator が次の手順を実行します。

  1. 新しい CA 証明書を生成しますが、既存のキーは保持します。

    該当する Secret 内の ca.crt という名前の古い証明書が新しい証明書に置き換えられます。

  2. 新しいクライアント証明書を生成します (ZooKeeper ノード、Kafka ブローカー、および Entity Operator 用)。

    署名鍵は変わっておらず、CA 証明書と同期してクライアント証明書の有効期間を維持するため、これは必須ではありません。

  3. 新しい CA 証明書を信頼し、新しいクライアント証明書を使用するために、ZooKeeper ノードを再起動します。
  4. 新しい CA 証明書を信頼し、新しいクライアント証明書を使用するために、Kafka ブローカーを再起動します。

  5. 新しい CA 証明書を信頼し、新しいクライアント証明書を使用するために、Topic Operator と User Operator を再起動します。

    ユーザー証明書はクライアント CA により署名されます。User Operator は、クライアントの CA が更新されるときにユーザー証明書の更新を処理します。

17.3.2. クライアント証明書の更新

Cluster Operator は、Kafka クラスターを使用するクライアントアプリケーションを認識しません。証明書の更新後もクライアントが動作するようにする必要があります。更新プロセスは、クライアントの設定によって異なります。

クライアントをクラスターに接続し、正しく動作させるには、クライアントアプリケーションに次の設定を含める必要があります。

  • Kafka クラスターのアイデンティティーを検証するための <cluster_name>-cluster-ca-cert シークレットからのトラストストア認証情報。
  • Kafka クラスターに接続するときにユーザーを検証するために接続する <user_name> シークレットからのキーストア認証情報。

ユーザーシークレットは、PEM および PKCS #12 形式の認証情報を提供します。また、SCRAM-SHA 認証を使用する場合は、パスワードを提供することもできます。ユーザーの作成時に User Operator によってユーザークレデンシャルが生成されます。クライアント設定に証明書を追加する例は、「Kafka へのユーザーアクセスのセキュア化」 を参照してください。

クライアント証明書と鍵のプロビジョニングを手動で行う場合、新しいクライアント証明書を生成し、更新期間内に新しい証明書がクライアントによって使用されるようにする必要があります。更新期間の終了までにこれが行われないと、クライアントアプリケーションがクラスターに接続できなくなる可能性があります。

注記

同じ OpenShift クラスターと namespace 内で実行されているワークロードの場合、シークレットをボリュームとしてマウントすると、クライアント Pod がシークレットの現在の状態からキーストアとトラストストアを構築できます。この手順の詳細は、クラスター CA を信頼する内部クライアントの設定 を参照してください。

17.3.3. メンテナンス時間枠のスケジュール設定

クライアントアプリケーションへの影響が最小限になるように、Cluster Operator による Kafka または ZooKeeper クラスターへの証明書更新をスケジュールします。時間枠は、Cluster Operator によって作成された CA 証明書の更新期間 (Kafka.spec.clusterCa.renewalDays および Kafka.spec.clusterCa.renewalDays) と組み合わせて使用します。

更新は、通常ユーザーまたはユーザーツールによる Kafka リソースの変更によってトリガーされます。証明書の有効期限切れによるローリング再起動は、Kafka リソースの変更なしに発生する可能性があります。予定外の再起動は、サービスの可用性には影響しませんが、クライアントアプリケーションのパフォーマンスに影響を及ぼす可能性があります。メンテナンス時間枠を使用すると、都合の良い時間にこれらの更新をスケジュールできます。

メンテナンス時間枠は次のように設定します。

  • Kafka リソースの Kafka.spec.maintenanceTimeWindows プロパティーを使用して文字列の配列を設定します。
  • 各文字列は、UTC (協定世界時) として解釈される cron 式 です。

以下の例では、日、月、火、水、および木曜日の午前 0 時に開始し、午前 1 時 59 分 (UTC) に終わる、単一のメンテナンス時間枠が設定されます。

メンテナンス時間枠の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
  maintenanceTimeWindows:
    - "* * 0-1 ? * SUN,MON,TUE,WED,THU *"
  #...
Copy to Clipboard

注記

Cluster Operator は、メンテナンス操作の指定時間枠に厳密には従いません。メンテナンス操作は、指定時間枠内で発生する最初の調整によってトリガーされます。時間枠が調整間隔よりも短い場合、調整が時間枠外で行われるリスクがあります。したがって、メンテナンス時間枠は少なくとも調整間隔と同じ長さにする必要があります。

17.3.4. Cluster Operator が管理する CA 証明書の手動更新

Cluster Operator によって生成されるクラスターおよびクライアント CA 証明書は、各証明書の更新期間の開始時に自動更新されます。ただし、strimzi.io/force-renew アノテーションを使用して、証明書の更新期間が始まる前に、これらの証明書の一方または両方を手動で更新することができます。セキュリティー上の理由や、証明書の更新または有効期間を変更した 場合などに、自動更新を行うことがあります。

更新された証明書は、更新前の証明書と同じ秘密鍵を使用します。

注記

独自の CA 証明書を使用している場合は、force-renew アノテーションは使用できません。代わりに、独自の CA 証明書を更新する 手順に従ってください。

前提条件

この手順では、my-project namespace 内の my-cluster という名前の Kafka クラスターを使用します。

手順

  1. strimzi.io/force-renew アノテーションを、更新対象の CA 証明書が含まれる secret に適用します。

    クラスター CA シークレットの更新

    oc annotate secret my-cluster-cluster-ca-cert -n my-project strimzi.io/force-renew="true"
    Copy to Clipboard

    クライアント CA シークレットの更新

    oc annotate secret my-cluster-clients-ca-cert -n my-project strimzi.io/force-renew="true"
    Copy to Clipboard

  2. 次回の調整時に、Cluster Operator は新しい証明書を生成します。

    メンテナンス時間枠が設定されている場合、Cluster Operator によって、最初の調整時に次のメンテナンス時間枠内で新規 CA 証明書が生成されます。

  3. 新しい CA 証明書の有効期間を確認します。

    新しいクラスター CA 証明書の有効期間の確認

    oc get secret my-cluster-cluster-ca-cert -n my-project -o=jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates
    Copy to Clipboard

    新しいクライアント CA 証明書の有効期間の確認

    oc get secret my-cluster-clients-ca-cert -n my-project -o=jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates
    Copy to Clipboard

    このコマンドは、CA 証明書の有効な開始日と終了日である notBefore および notAfter の日付を返します。

  4. 新しいクラスター CA 証明書を信頼するようにクライアント設定を更新します。

    参照:

17.3.5. 期限切れの Cluster Operator 管理の CA 証明書からの手動回復

Cluster Operator は、更新期間が開始されると、クラスターとクライアントの CA 証明書を自動的に更新します。ただし、Cluster Operator のダウンタイムが長引いたり、Kafka クラスターが利用できなくなったりするなど、予期しない運用上の問題や中断により、更新プロセスが妨げられる場合があります。CA 証明書の有効期限が切れると、Kafka クラスターコンポーネントは相互に通信できなくなり、Cluster Operator は手動介入なしに CA 証明書を更新できなくなります。

リカバリーを迅速に実行するには、この手順で説明されている手順を指定された順序で実行してください。期限切れのクラスターおよびクライアント CA 証明書から回復できます。このプロセスには、Cluster Operator によって新しい証明書が生成されるように、期限切れの証明書を含むシークレットを削除することが含まれます。Streams for Apache Kafka で管理されるシークレットの詳細は、「Cluster Operator で生成されたシークレット」 を参照してください。

注記

独自の CA 証明書を使用していて期限切れになる場合、プロセスは似ていますが、Cluster Operator によって生成された証明書を使用するのではなく、CA 証明書を更新する 必要があります。

前提条件

この手順では、my-project namespace 内の my-cluster という名前の Kafka クラスターを使用します。

手順

  1. 期限切れの CA 証明書を含むシークレットを削除します。

    クラスター CA シークレットの削除

    oc delete secret my-cluster-cluster-ca-cert -n my-project
    Copy to Clipboard

    クライアント CA シークレットの削除

    oc delete secret my-cluster-clients-ca-cert -n my-project
    Copy to Clipboard

  2. Cluster Operator が新しい証明書を生成するまで待ちます。

    • Kafka ブローカーの ID を検証するための新しい CA クラスター証明書が、同じ名前のシークレット (my-cluster-cluster-ca-cert) で作成されます。
    • Kafka ユーザーの ID を検証するための新しい CA クライアント証明書が、同じ名前のシークレット (my-cluster-clients-ca-cert) で作成されます。

  3. 新しい CA 証明書の有効期間を確認します。

    新しいクラスター CA 証明書の有効期間の確認

    oc get secret my-cluster-cluster-ca-cert -n my-project -o=jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates
    Copy to Clipboard

    新しいクライアント CA 証明書の有効期間の確認

    oc get secret my-cluster-clients-ca-cert -n my-project -o=jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -dates
    Copy to Clipboard

    このコマンドは、CA 証明書の有効な開始日と終了日である notBefore および notAfter の日付を返します。

  4. CA 証明書を使用するコンポーネント Pod とシークレットを削除します。

    1. ZooKeeper シークレットを削除します。
    2. Cluster Operator が欠落している ZooKeeper シークレットを検出し、再作成するまで待ちます。
    3. すべての ZooKeeper Pod を削除します。
    4. Kafka シークレットを削除します。
    5. Cluster Operator が欠落している Kafka シークレットを検出して再作成するまで待ちます。
    6. すべての Kafka Pod を削除します。

    クライアント CA 証明書のみを回復する場合は、Kafka シークレットと Pod を削除するだけで済みます。

    次の oc コマンドを使用してリソースを検索し、それらが削除されたことを確認することもできます。 

    oc get <resource_type> --all-namespaces | grep <kafka_cluster_name>
    Copy to Clipboard

    <resource_type> を、Pod や Secret などのリソースのタイプに置き換えます。

  5. Cluster Operator が欠落している Kafka および ZooKeeper Pod を検出し、更新された CA 証明書を使用してそれらを再作成するまで待ちます。

    調整時に、Cluster Operator は新しい CA 証明書を信頼するように他のコンポーネントを自動的に更新します。

  6. Cluster Operator ログに証明書の検証に関連する問題がないことを確認します。

  7. 新しいクラスター CA 証明書を信頼するようにクライアント設定を更新します。

    参照:

17.3.6. Cluster Operator が管理する CA 証明書で使用される秘密鍵の置き換え

Cluster Operator によって生成されるクラスター CA およびクライアント CA 証明書によって使用される秘密鍵を置換できます。秘密鍵が交換されると、Cluster Operator によって新しい秘密鍵の新しい CA 証明書が生成されます。

注記

独自の CA 証明書を使用している場合は、force-replace アノテーションは使用できません。代わりに、独自の CA 証明書を更新する 手順に従ってください。

前提条件

  • Cluster Operator が稼働中である。
  • CA 証明書と秘密鍵がインストールされている Kafka クラスターが必要です。

手順

  • 更新対象の秘密鍵が含まれる Secret に strimzi.io/force-replace アノテーションを適用します。

    表17.13 秘密鍵を置き換えるコマンド
    秘密鍵Secretannotate コマンド

    クラスター 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 証明書をクライアントアプリケーションがリロードする必要があります。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat