3.2. API サーバー証明書の追加

デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。クラスター外のクライアントは、デフォルトで API サーバーの証明書を検証できません。この証明書は、クライアントが信頼する CA によって発行される証明書に置き換えることができます。

3.2.1. API サーバーの名前付き証明書の追加

デフォルトの API サーバー証明書は、内部 OpenShift Container Platform クラスター CA によって発行されます。リバースプロキシーやロードバランサーが使用される場合など、クライアントが要求する完全修飾ドメイン名 (FQDN) に基づいて、API サーバーが返す代替証明書を 1 つ以上追加できます。

前提条件

  • FQDN とそれに対応するプライベートキーの証明書が必要です。それぞれが個別の PEM 形式のファイルである必要があります。
  • プライベートキーの暗号化は解除されている必要があります。キーが暗号化されている場合は、これを OpenShift Container Platform にインポートする前に復号化します。
  • 証明書には、FQDN を示す subjectAltName 拡張が含まれる必要があります。
  • 証明書ファイルでは、チェーンに 1 つ以上の証明書を含めることができます。API サーバー FQDN の証明書は、ファイルの最初の証明書である必要があります。この後には中間証明書が続き、ファイルの最後はルート CA 証明書にすることができます。
警告

内部ロードバランサーに名前付きの証明書を指定しないようにしてください (ホスト名 api-int.<cluster_name>.<base_domain>)。これを指定すると、クラスターの状態は動作の低下した状態になります。

手順

  1. kubeadmin ユーザーとして新しい API にログインします。 

    $ oc login -u kubeadmin -p <password> https://FQDN:6443

  2. kubeconfig ファイルを取得します。 

    $ oc config view --flatten > kubeconfig-newapi

  3. openshift-config namespace に証明書およびプライベートキーが含まれるシークレットを作成します。 

    $ oc create secret tls <secret> \1
     --cert=</path/to/cert.crt> \2
     --key=</path/to/cert.key> \3
     -n openshift-config
    1
    <secret> は、証明書チェーンおよびプライベートキーが含まれるシークレットの名前です。
    2
    </path/to/cert.crt> は、ローカルファイルシステム上の証明書チェーンへのパスです。
    3
    </path/to/cert.key> は、この証明書に関連付けられるプライベートキーへのパスです。

  4. API サーバーを作成されたシークレットを参照するように更新します。 

    $ oc patch apiserver cluster \
     --type=merge -p \
     '{"spec":{"servingCerts": {"namedCertificates":
     [{"names": ["<FQDN>"], 1
     "servingCertificate": {"name": "<secret>"}}]}}}' 2
    1
    <FQDN> を、API サーバーが証明書を提供する FQDN に置き換えます。
    2
    <certificate> を、直前の手順でシークレットに使用された名前に置き換えます。

  5. apiserver/cluster オブジェクトを検査し、シークレットが参照されていることを確認します。 

    $ oc get apiserver cluster -o yaml

    出力例

    ...
spec:
  servingCerts:
    namedCertificates:
    - names:
      - <FQDN>
      servingCertificate:
        name: <secret>
...

  6. kube-apiserver Operator を確認し、Kubernetes API サーバーの新しいリビジョンがロールアウトされることを確認します。Operator が設定の変更を検出して新しいデプロイメントをトリガーするのに 1 分かかる場合があります。新しいリビジョンが公開されている間、PROGRESSING は True を報告します。 

    $ oc get clusteroperators kube-apiserver

    以下の出力にあるように、PROGRESSING が False と表示されるまで次の手順に移行しないでください。

    出力例

    NAME             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
kube-apiserver   4.7.0     True        False         False      145m

    PROGRESSING が True と表示されている場合は、数分待機してから再試行します。