第4章 カスタム認証局の設定


MicroShift サービスでは、カスタム証明局 (CA) を使用して接続を暗号化できます。

4.1. MicroShift でのカスタム認証局の仕組み

デフォルトの API サーバー証明書は、内部の MicroShift クラスター認証局 (CA) によって発行されます。デフォルトでは、クラスター外部のクライアントは API サーバー証明書を検証できません。この証明書は、クライアントが信頼するカスタム CA によって外部的に発行されたカスタムサーバー証明書に置き換えることができます。次の手順は、MicroShift のワークフローを示しています。

  1. 証明書とキーをホストオペレーティングシステムの優先ディレクトリーにコピーします。ファイルに root のみがアクセスできることを確認してください。
  2. MicroShift /etc/microshift/config.yaml 設定ファイルで証明書名と新しい完全修飾ドメイン名 (FQDN) を指定して、各カスタム CA の MicroShift 設定を更新します。

    各証明書設定には、以下の値を含めることができます。

    • 証明書ファイルの場所は必須の値です。
    • API サーバーの DNS と IP アドレスまたは IP アドレス範囲を含む単一の共通名。

      ヒント

      ほとんどの場合、MicroShift は、指定した IP アドレスまたは範囲を含むカスタム CA の新しい kubeconfig を生成します。例外は、IP アドレスにワイルドカードが指定されている場合です。この場合、MicroShift はサーバーのパブリック IP アドレスを使用して kubeconfig を生成します。ワイルドカードを使用するには、特定の詳細で kubeconfig ファイルを更新する必要があります。

    • API サーバーの DNS と IP アドレス、またはワイルドカード証明書を含む複数のサブジェクト別名 (SAN)。
    • 各証明書に追加の DNS 名を指定できます。
  3. MicroShift サービスが再起動した後、生成された kubeconfig ファイルをクライアントにコピーする必要があります。
  4. クライアントシステムで追加の CA を設定します。たとえば、Red Hat Enterprise Linux (RHEL) トラストストア内の CA バンドルを更新できます。
  5. 証明書と鍵は、ホスト上の指定されたファイルの場所から読み取られます。設定のテストおよび検証はクライアントから行われます。
  6. 外部サーバー証明書は自動的に更新されません。外部証明書を手動でローテーションする必要があります。
注記

検証に失敗した場合、MicroShift サービスはカスタム設定をスキップし、デフォルトの証明書を使用して起動します。サービスを中断せずに継続することが最優先事項です。MicroShift は、サービスの開始時にエラーを記録します。一般的なエラーには、証明書の期限切れ、ファイルの欠落、IP アドレスの誤りなどがあります。

重要

カスタムサーバー証明書は、ホストオペレーティングシステムの信頼ルートに設定された CA データに対して検証する必要があります。詳細は、システム全体のトラストストア を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.