第3章 カスタム認証局の設定
MicroShift サービスでは、カスタム証明局 (CA) を使用して接続を暗号化できます。
3.1. MicroShift でのカスタム認証局の仕組み
デフォルトの API サーバー証明書は、内部の MicroShift クラスター認証局 (CA) によって発行されます。デフォルトでは、クラスター外部のクライアントは API サーバー証明書を検証できません。この証明書は、クライアントが信頼するカスタム CA によって外部的に発行されたカスタムサーバー証明書に置き換えることができます。次の手順は、MicroShift のワークフローを示しています。
- 証明書とキーをホストオペレーティングシステムの優先ディレクトリーにコピーします。ファイルに root のみがアクセスできることを確認してください。
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 名を指定できます。
-
MicroShift サービスが再起動した後、生成された
kubeconfigファイルをクライアントにコピーする必要があります。 - クライアントシステムで追加の CA を設定します。たとえば、Red Hat Enterprise Linux (RHEL) トラストストア内の CA バンドルを更新できます。
- 証明書と鍵は、ホスト上の指定されたファイルの場所から読み取られます。設定のテストおよび検証はクライアントから行われます。
- 外部サーバー証明書は自動的に更新されません。外部証明書を手動でローテーションする必要があります。
検証に失敗した場合、MicroShift サービスはカスタム設定をスキップし、デフォルトの証明書を使用して起動します。サービスを中断せずに継続することが最優先事項です。MicroShift は、サービスの開始時にエラーを記録します。一般的なエラーには、証明書の期限切れ、ファイルの欠落、IP アドレスの誤りなどがあります。
カスタムサーバー証明書は、ホストオペレーティングシステムの信頼ルートに設定された CA データに対して検証する必要があります。詳細は、システム全体のトラストストア を参照してください。
