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

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

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

Cluster Operator によって自動作成される CA 証明書の場合、以下の有効期間を設定できます。

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

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

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

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

Cluster Operator によって作成される証明書の更新期間を設定できます。

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

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

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

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

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

Kafka クラスターの作成後に有効期間と更新期間の変更を行うには、Kafka カスタムリソースの設定と適用、およびmanually renew the CA certificatesを行います。証明書を手動で更新しないと、証明書が次回自動更新される際に新しい期間が使用されます。

証明書の有効および更新期間の 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 Toggle word wrap

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

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

16.3.1. 自動生成された CA 証明書での更新プロセス
リンクのコピー

Cluster Operator は、CA 証明書を更新する時に以下のプロセスをこの順序で実行します。

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

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

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

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

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

  5. Topic Operator および User Operator を再起動して、それらの Operator が新しい CA 証明書を信頼し、新しいクライアント証明書を使用するようにします。

    ユーザー証明書はクライアント CA により署名されます。User Operator によって生成されるユーザー証明書は、クライアント CA の更新時に更新されます。

16.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 を信頼する内部クライアントの設定 を参照してください。

16.3.3. 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 Toggle word wrap

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

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

  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 Toggle word wrap

    新しいクライアント 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 Toggle word wrap

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

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

    参照:

16.3.4. 期限切れの 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 Toggle word wrap

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

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

  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 Toggle word wrap

    新しいクライアント 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 Toggle word wrap

    このコマンドは、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 Toggle word wrap

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

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

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

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

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

    参照:

16.3.5. Cluster Operator が管理する CA 証明書で使用される秘密鍵の置き換え
リンクのコピー

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

注記

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

前提条件

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

手順

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

    Expand
    表16.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