第7章 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 バンドルを更新できます。

   重要

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

   • システム全体のトラストストア

5. 証明書と鍵は、ホスト上の指定されたファイルの場所から読み取られます。クライアントから設定をテストして検証できます。

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

手順

1. 追加するカスタム証明書を MicroShift ホストの信頼ルートにコピーします。証明書と秘密鍵に MicroShift のみがアクセス可能であることを確認します。

2. 必要なカスタム CA ごとに、次の例を使用して、namedCertificates という apiServer セクションを /etc/microshift/config.yaml MicroShift 設定ファイルに追加します。

   apiServer:
     namedCertificates:
      - certPath: ~/certs/api_fqdn_1.crt 

   1

   
        keyPath:  ~/certs/api_fqdn_1.key 

   2

   
      - certPath: ~/certs/api_fqdn_2.crt
        keyPath:  ~/certs/api_fqdn_2.key
        names: 

   3

   
        - api_fqdn_1
        - *.apps.external.com

   1

   証明書の完全パスを追加します。

   2

   証明書キーへの完全パスを追加します。

   3

   オプション: 明示的な DNS 名のリストを追加します。ワイルドカードは、先頭に指定できます。名前が指定されていない場合は、暗黙名が証明書からリストされます。

3. 次のコマンドを実行して、MicroShift を再起動し、証明書を適用します。

   $ systemctl microshift restart

4. システムが再起動してカスタムサーバーが適用されるまで数分間待ちます。新しい kubeconfig ファイルは /var/lib/microshift/resources/kubeadmin/ ディレクトリーに生成されます。
5. kubeconfig ファイルをクライアントにコピーします。IP アドレスにワイルドカードを指定した場合は、kubeconfig を更新してサーバーのパブリック IP アドレスを削除し、その IP アドレスを使用する特定のワイルドカード範囲に置き換えます。

6. クライアントからは、次の手順を実行します。

   1. 次のコマンドを実行して、使用する kubeconfig を指定します。

      $ export KUBECONFIG=~/custom-kubeconfigs/kubeconfig 

      1

      1

      コピーした kubeconfig ファイルの場所をパスとして使用します。

   2. 次のコマンドを使用して、証明書が適用されていることを確認します。

      $ oc --certificate-authority ~/certs/ca.ca get node

      出力例

      oc get node
      NAME                             STATUS   ROLES                         AGE   VERSION
      dhcp-1-235-195.arm.example.com   Ready    control-plane,master,worker   76m   v1.32.3

   3. 次のコマンドを実行して、新しい CA ファイルを $KUBECONFIG 環境変数に追加します。

      $ oc config set clusters.microshift.certificate-authority /tmp/certificate-authority-data-new.crt

   4. 次のコマンドを実行して、新しい kubeconfig ファイルに新しい CA が含まれていることを確認します。

      $ oc config view --flatten

      外部で生成された kubeconfig ファイルの例

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority: /tmp/certificate-authority-data-new.crt 

      1

      
          server: https://api.ci-ln-k0gim2b-76ef8.aws-2.ci.openshift.org:6443
        name: ci-ln-k0gim2b-76ef8
      contexts:
      - context:
          cluster: ci-ln-k0gim2b-76ef8
          user:
        name:
      current-context:
      kind: Config
      preferences: {}

      1

      外部で生成された kubeconfig ファイルには、certificate-authority-data セクションが存在しません。これは、以前使用した oc config set コマンドで追加されます。

   5. 次のコマンドを実行して、カスタマイズされた API サーバー認証局の subject と issuer を確認します。

      $ curl --cacert /tmp/caCert.pem https://${fqdn_name}:6443/healthz -v

      出力例

      Server certificate:
        subject: CN=kas-test-cert_server
        start date: Mar 12 11:39:46 2024 GMT
        expire date: Mar 12 11:39:46 2025 GMT
        subjectAltName: host "dhcp-1-235-3.arm.eng.rdu2.redhat.com" matched cert's "dhcp-1-235-3.arm.eng.rdu2.redhat.com"
        issuer: CN=kas-test-cert_ca
        SSL certificate verify ok.

      重要

      生成された kubeconfig ファイル内の certificate-authority-data を新しい rootCA に置き換えるか、certificate-authority-data をオペレーティングシステムの信頼ルートに追加します。両方の方法を使用しないでください。

   6. オペレーティングシステムの信頼ルートで追加の CA を設定します。たとえば、クライアントシステム上の RHEL クライアントトラストストア内などです。システム全体のトラストストア。

      • CA を含む設定で証明書バンドルを更新することを推奨します。
      • 証明書バンドルを設定しない場合は、代わりに oc login localhost:8443 --certificate-authority=/path/to/cert.crt コマンドを使用することもできますが、この方法は推奨されません。

手順

1. MicroShift から、次のコマンドを実行して、証明書が kube-apiserver によって提供されていることを確認し、証明書パスが --tls-sni-cert-key フラグに追加されていることを確認します。

   $ journalctl -u microshift -b0 | grep tls-sni-cert-key

   出力例

   Jan 24 14:53:00 localhost.localdomain microshift[45313]: kube-apiserver I0124 14:53:00.649099   45313 flags.go:64] FLAG: --tls-sni-cert-key="[/home/eslutsky/dev/certs/server.crt,/home/eslutsky/dev/certs/server.key;/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-external-signer/kube-external-serving/server.key;/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-localhost-signer/kube-apiserver-localhost-serving/server.key;/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.crt,/var/lib/microshift/certs/kube-apiserver-service-network-signer/kube-apiserver-service-network-serving/server.key

2. クライアントから次のコマンドを実行して、kube-apiserver が正しい証明書を提供していることを確認します。

   $ openssl s_client -connect <SNI_ADDRESS>:6443 -showcerts | openssl x509 -text -noout -in - | grep -C 1 "Alternative\|CN"

手順

1. 次のコマンドを実行して、MicroShift サービスを停止し、カスタム証明書をクリーンアップします。

   $ sudo microshift-cleanup-data --cert

   出力例

   Stopping MicroShift services
   Removing MicroShift certificates
   MicroShift service was stopped
   Cleanup succeeded

2. 次のコマンドを実行して、MicroShift サービスを再起動し、カスタム証明書を再作成します。

   $ sudo systemctl start microshift