第10章 証明書の再デプロイ
10.1. 概要
OpenShift Container Platform は、以下のコンポーネントで証明書を使用してセキュアな接続を提供します。
- マスター (API サーバーとコントローラー)
- etcd
- ノード
- レジストリー
- ルーター
インストーラーによって提供される Ansible Playbook を使用すると、クラスター証明書の有効期限を自動的にチェックできます。これらの証明書を自動的にバックアップしたり、再デプロイしたりするための Playbook も提供されます。これらの Playbook を使用すると、一般的な証明書エラーを修正できます。
証明書の再デプロイのユースケースとして以下が考えられます。
- インストーラーによって誤ったホスト名が検出され、そのことがすぐに判明しなかった。
- 証明書の有効期限が切れており、証明書を更新する必要がある。
- 新しい CA があり、その CA を代わりに使用する証明書を作成する。
10.2. 証明書の有効期限のチェック
インストーラーを使用して、設定可能な日数内に有効期限が切れる証明書に関する警告やすでに有効期限が切れた証明書に関する通知を受け取ることができます。証明書の有効期限切れ Playbook では、Ansible の openshift_certificate_expiry
ロールが使用されます。
ロールによって検査される証明書には、以下が含まれます。
- マスターおよびノードサービス証明書
- etcd シークレットのルーターおよびレジストリーサービス証明書
- マスター、ノード、ルーター、レジストリー、および cluster-admin ユーザーの kubeconfig ファイル
- etcd 証明書 (組み込み証明書を含む)
10.2.1. ロール変数
openshift_certificate_expiry
ロールは、以下の変数を使用します。
変数名 | デフォルト値 | 説明 |
---|---|---|
|
|
OpenShift Container Platform 基本設定ディレクトリーです。 |
|
|
現在を起点として指定された日数内に有効期限が切れる証明書にフラグを付けます。 |
|
|
正常な (期限切れや警告のない) 証明書を結果に組み込みます。 |
変数名 | デフォルト値 | 説明 |
---|---|---|
|
|
有効期限切れのチェック結果に関する HTML レポートを生成します。 |
|
|
HTML レポートを保存するための完全パスです。 |
|
|
有効期限のチェック結果を JSON ファイルとして保存します。 |
|
|
JSON レポートを保存するための完全パスです。 |
10.2.2. 証明書の有効期限切れ Playbook の実行
OpenShift Container Platform インストーラーは、openshift_certificate_expiry
ロールのさまざまな設定セットを使用して証明書の有効期限切れ Playbook のサンプル一式を提供します。
これらの Playbook は、クラスターを表す インベントリーファイルと一緒に使用する必要があります。最適な結果を得るには、ansible-playbook
に -v
オプションを指定して実行します。
easy-mode.yaml のサンプル Playbook を使用すると、ロールアウトを仕様に合わせて調整する前に試すことができます。この Playbook は以下を実行します。
- JSON レポートと定型化された HTML レポートを /tmp/ に生成します。
- ほぼ常に結果が得られるように警告期間を長い期間に設定します。
- すべての証明書 (正常であるかどうかを問わず) を結果に組み込みます。
easy-mode.yaml Playbook
- name: Check cert expirys hosts: nodes:masters:etcd become: yes gather_facts: no vars: openshift_certificate_expiry_warning_days: 1500 openshift_certificate_expiry_save_json_results: yes openshift_certificate_expiry_generate_html_report: yes openshift_certificate_expiry_show_all: yes roles: - role: openshift_certificate_expiry
easy-mode.yaml Playbook を実行するには、以下を実行します。
$ ansible-playbook -v -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/easy-mode.yaml
他のサンプル Playbook
その他のサンプル Playbook も /usr/share/ansible/openshift-ansible/playbooks/certificate_expiry/ ディレクトリーから直接実行できます。
ファイル名 | 使用法 |
---|---|
default.yaml |
|
html_and_json_default_paths.yaml |
HTML および JSON アーティファクトをデフォルトのパスに生成します。 |
longer_warning_period.yaml |
有効期限切れの警告期間を 1500 日に変更します。 |
longer-warning-period-json-results.yaml |
有効期限切れの警告期間を 1500 日に変更し、結果を JSON ファイルとして保存します。 |
これらのサンプル Playbook を実行するには、以下を実行します。
$ ansible-playbook -v -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-checks/certificate_expiry/<playbook>
10.2.3. 出力形式
上述のように、チェックレポートは 2 つの形式で出力できます。機械の解析に適した JSON 形式と簡単にスキミングできる定型化された HTML ページを使用できます。
HTML レポート
インストーラーには、HTML レポートのサンプルが付属しています。以下のファイルをブラウザーで開いて表示できます。
/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.html
JSON レポート
保存された JSON の結果には、data
と summary
の 2 つの最上位のキーがあります。
data
キーは、検証された各ホストの名前がキーとして、該当するホストごとに特定された証明書の確認結果が値として含まれるハッシュです。
summary
キーは、以下の条件に当てはまる証明書の合計数をまとめたハッシュです。
- クラスター全体で検査済み
- 問題なし
- 設定された警告期間内に有効期限が切れる
- すでに有効期限が切れている
完全な JSON レポートのサンプルについては、/usr/share/ansible/openshift-ansible/roles/openshift_certificate_expiry/examples/cert-expiry-report.json を参照してください。
JSON データのサマリーでは、さまざまなコマンドラインツールを使用して警告や有効期限を簡単にチェックできます。たとえば、grep
を使用して summary
という語を検索し、一致した箇所の後ろの 2 行を出力できます (-A2
)。
$ grep -A2 summary /tmp/cert-expiry-report.json "summary": { "warning": 16, "expired": 0
また、jq
ツールが使用可能な場合は、このツールを使用して特定の値を選択できます。以下の最初の 2 つの例は、warning
または expired
のいずれかの値を選択する方法を示しています。3 つ目の例は、両方の値を一度に選択する方法を示しています。
$ jq '.summary.warning' /tmp/cert-expiry-report.json 16 $ jq '.summary.expired' /tmp/cert-expiry-report.json 0 $ jq '.summary.warning,.summary.expired' /tmp/cert-expiry-report.json 16 0
10.3. 証明書の再デプロイ
該当するすべてのホストにマスター、etcd、ノード、レジストリーまたはルーター証明書を再デプロイするには、以下の Playbook を使用します。現在の CA を使用してこれらすべての証明書を一度に再デプロイすることも、特定のコンポーネント用の証明書のみを再デプロイすることも、新しく生成された CA またはカスタム CA 自体を再デプロイすることもできます。
証明書の有効期限切れ Playbook と同様に、これらの Playbook はクラスターを表すインベントリーファイルを使用して実行する必要があります。
特にインベントリーでは、すべてのホスト名と IP アドレスが現在のクラスター設定に一致するように、以下の変数でそれらを指定するか、または上書きする必要があります。
-
openshift_public_hostname
-
openshift_public_ip
-
openshift_master_cluster_hostname
-
openshift_master_cluster_public_hostname
以下のコマンドを実行すると、必要な Playbook が利用できるようになります。
# yum install atomic-openshift-utils
再デプロイ中に自動生成された証明書の有効性 (有効期限が切れるまでの日数) も Ansible で設定できます。「証明書の有効性の設定」を参照してください。
OpenShift Container Platform CA および etcd 証明書の有効期限は 5 年です。署名付きの OpenShift Container Platform 証明書の有効期限は 2 年です。
10.3.1. 現行の OpenShift Container Platform および etcd CA を使用したすべての証明書の再デプロイ
redeploy-certificates.yml Playbook は、OpenShift Container Platform CA 証明書を再生成しません。新しいマスター 、etcd、ノード、レジストリー、およびルーター証明書は、新規の証明書に署名するために現在の CA 証明書を使用して作成されます。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
- ノードサービス
現行の OpenShift Container Platform CA を使用してマスター、etcd、およびノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/redeploy-certificates.yml
10.3.2. 新規またはカスタムの OpenShift Container Platform CA の再デプロイ
openshift-master/redeploy-openshift-ca.yml Playbook は、新規の CA 証明書を生成し、クライアントの kubeconfig ファイルとノードの信頼できる CA のデータベース (CA-trust) を含むすべてのコンポーネントに更新されたバンドルを配布することによって OpenShift Container Platform CA 証明書を再デプロイします。
これには、以下の順次の再起動も伴います。
- マスターサービス
- ノードサービス
- Docker
さらに、証明書を再デプロイする際には、OpenShift Container Platform によって生成される CA を使用する代わりに、カスタム CA 証明書を指定することもできます。
マスターサービスが再起動すると、レジストリーとルーターは、再デプロイされなくてもマスターと引き続き通信できます。これは、マスターの提供証明書が同一であり、レジストリーとルーターの CA が依然として有効であるためです。
新たに生成される CA またはカスタム CA を再デプロイするには、以下を実行します。
オプションで、カスタム CA を指定します。カスタム CA パラメーター
openshift_master_ca_certificate
の一部として指定するcertfile
には、OpenShift Container Platform 証明書に署名する単一証明書のみが含まれる必要があります。チェーンに中間証明書が含まれる場合、それらを別のファイルにバンドルする必要があります。中間証明書なしで CA を指定するには、インベントリーファイルに以下の変数を指定します。
# Configure custom ca certificate # NOTE: CA certificate will not be replaced with existing clusters. # This option may only be specified when creating a new cluster or # when redeploying cluster certificates with the redeploy-certificates # playbook. openshift_master_ca_certificate={'certfile': '</path/to/ca.crt>', 'keyfile': '</path/to/ca.key>'}
中間 CA によって発行された CA 証明書を指定するには、以下を実行します。
CA の中間およびルート証明書の詳細チェーンが含まれるバンドルされた証明書を作成します。
# cat intermediate/certs/<intermediate.cert.pem> \ certs/ca.cert.pem >> intermediate/certs/ca-chain.cert.pem
以下の変数をインベントリーファイルに設定します。
# Configure custom ca certificate # NOTE: CA certificate will not be replaced with existing clusters. # This option may only be specified when creating a new cluster or # when redeploying cluster certificates with the redeploy-certificates # playbook. openshift_master_ca_certificate={'certfile': '</path/to/ca.crt>', 'keyfile': '</path/to/ca.key>'} openshift_additional_ca=intermediate/certs/ca-chain.cert.pem
openshift-master/redeploy-openshift-ca.yml Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-openshift-ca.yml
新規の OpenShift Container Platform CA が導入されている場合、新規の CA によって署名された証明書をすべてのコンポーネントに再デプロイする必要がある場合にはいつでも openshift-master/redeploy-certificates.yml Playbook を使用できます。
10.3.3. 新規 etcd CA の再デプロイ
openshift-etcd/redeploy-ca.yml Playbook は、新規 CA 証明書を生成し、すべての etcd ピアとマスタークライアントに更新したバンドルを配布することによって etcd CA 証明書を再デプロイします。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
新たに生成された etcd CA を再デプロイするには、以下を実行します。
openshift-etcd/redeploy-ca.yml Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-ca.yml
新規 etcd CA が導入されている場合、新規 CA によって署名された証明書を etcd ピアとマスタークライアントに再デプロイする必要がある場合にはいつでも openshift-etcd/redeploy-certificates.yml Playbook を使用できます。または、redeploy-certificates.yml Playbook を使用して、etcd ピアとマスタークライアントに加えて、OpenShift Container Platform コンポーネントの証明書も再デプロイできます。
10.3.4. マスター証明書のみの再デプロイ
openshift-master/redeploy-certificates.yml Playbook は、マスター証明書のみを再デプロイします。これには、マスターサービスの順次の再起動も伴います。
マスター証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-master/redeploy-certificates.yml
この Playbook を実行した後に、サービス提供証明書を含む既存のシークレットを削除するか、またはアノテーションを削除し、適切なサービスに再度追加して、サービス提供証明書またはキーペアを再生成する必要があります。
10.3.5. etcd 証明書のみの再デプロイ
openshift-etcd/redeploy-certificates.yml Playbook は、マスタークライアント証明書を含む etcd 証明書のみを再デプロイします。
これには、以下の順次の再起動も伴います。
- etcd
- マスターサービス
etcd 証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-etcd/redeploy-certificates.yml
10.3.6. ノード証明書のみの再デプロイ
openshift-node/redeploy-certificates.yml Playbook は、ノード証明書のみを再デプロイします。これには、ノードサービスの順次の再起動も伴います。
ノード証明書を再デプロイするには、この Playbook を実行し、インベントリーファイルを指定します
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-node/redeploy-certificates.yml
10.3.7. レジストリー証明書またはルーター証明書のみの再デプロイ
openshift-hosted/redeploy-registry-certificates.yml Playbook と openshift-hosted/redeploy-router-certificates.yml Playbook は、インストーラーによって作成されたレジストリー証明書とルーター証明書を置き換えます。レジストリーとルーターでカスタム証明書が使用されている場合にそれらを手動で置き換えるには、「 カスタムのレジストリー証明書またはルーター証明書の再デプロイ」を参照してください。
10.3.7.1. レジストリー証明書のみの再デプロイ
レジストリー証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-registry-certificates.yml
10.3.7.2. ルーター証明書のみの再デプロイ
ルーター証明書を再デプロイするには、以下の Playbook を実行し、インベントリーファイルを指定します。
$ ansible-playbook -i <inventory_file> \ /usr/share/ansible/openshift-ansible/playbooks/openshift-hosted/redeploy-router-certificates.yml
10.3.8. カスタムのレジストリー証明書またはルーター証明書の再デプロイ
再デプロイされた CA が原因でノードが退避させられると、レジストリー Pod とルーター Pod が再起動されます。レジストリー証明書とルーター証明書を新規 CA と共に再デプロイしなかった場合は、それらが古い証明書を使用してマスターにアクセスできなくなるため、停止状態が生じることがあります。
証明書を再デプロイする Playbook は、カスタムのレジストリー証明書またはルーター証明書を再デプロイできません。この問題を解決するため、レジストリー証明書とルーター証明書を手動で再デプロイする必要があります。
10.3.8.1. 手動によるレジストリー証明書の再デプロイ
レジストリー証明書を手動で再デプロイするには、新規レジストリー証明書を registry-certificates
という名前のシークレットに追加してから、レジストリーを再デプロイする必要があります。
これ以降の手順では
default
プロジェクトに切り替えます。$ oc project default
最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにシークレットをご使用ください)。
以下のコマンドを実行し、
OPENSHIFT_CA_DATA
、OPENSHIFT_CERT_DATA
、およびOPENSHIFT_KEY_DATA
環境変数を探します。$ oc env dc/docker-registry --list
これらの環境変数が存在しない場合は、この手順を省略します。存在する場合は、以下の
ClusterRoleBinding
を作成します。$ cat <<EOF | apiVersion: v1 groupNames: null kind: ClusterRoleBinding metadata: creationTimestamp: null name: registry-registry-role roleRef: kind: ClusterRole name: system:registry subjects: - kind: ServiceAccount name: registry namespace: default userNames: - system:serviceaccount:default:registry EOF oc create -f -
次に、以下のコマンドを実行して環境変数を削除します。
$ oc env dc/docker-registry OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
以下の環境変数をローカルに設定し、後で使用するコマンドを単純化します。
$ REGISTRY_IP=`oc get service docker-registry -o jsonpath='{.spec.clusterIP}'` $ REGISTRY_HOSTNAME=`oc get route/docker-registry -o jsonpath='{.spec.host}'`
新規レジストリー証明書を作成します。
$ oc adm ca create-server-cert \ --signer-cert=/etc/origin/master/ca.crt \ --signer-key=/etc/origin/master/ca.key \ --hostnames=$REGISTRY_IP,docker-registry.default.svc,docker-registry.default.svc.cluster.local,$REGISTRY_HOSTNAME \ --cert=/etc/origin/master/registry.crt \ --key=/etc/origin/master/registry.key \ --signer-serial=/etc/origin/master/ca.serial.txt
Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから
oc adm
コマンドを実行します。registry-certificates
シークレットを新規レジストリー証明書で更新します。$ oc create secret generic registry-certificates \ --from-file=/etc/origin/master/registry.crt,/etc/origin/master/registry.key \ -o json --dry-run | oc replace -f -
レジストリーを再デプロイします。
$ oc rollout latest dc/docker-registry
10.3.8.2. 手動によるルーター証明書の再デプロイ
ルーターの初回デプロイ時に、アノテーションがサービス提供証明書シークレットを自動的に作成するルーターのサービスに追加されます。
ルーター証明書を手動で再デプロイするため、そのサービス提供証明書の再作成をトリガーできます。これは、シークレットを削除し、アノテーションを削除してから router
サービスに再度追加し、ルーターを再デプロイして実行できます。
これ以降の手順では
default
プロジェクトに切り替えます。$ oc project default
最初にレジストリーを OpenShift Container Platform 3.1 以前で作成した場合は、環境変数が証明書を保存するために使用されている場合があります (この方法は現在は推奨されていません。代わりにサービス提供証明書シークレットをご使用ください)。
以下のコマンドを実行し、
OPENSHIFT_CA_DATA
、OPENSHIFT_CERT_DATA
、およびOPENSHIFT_KEY_DATA
環境変数を探します。$ oc env dc/router --list
それらの変数が存在する場合は、以下の
ClusterRoleBinding
を作成します。$ cat <<EOF | apiVersion: v1 groupNames: null kind: ClusterRoleBinding metadata: creationTimestamp: null name: router-router-role roleRef: kind: ClusterRole name: system:router subjects: - kind: ServiceAccount name: router namespace: default userNames: - system:serviceaccount:default:router EOF oc create -f -
それらの変数が存在する場合は、以下のコマンドを実行してそれらを削除します。
$ oc env dc/router OPENSHIFT_CA_DATA- OPENSHIFT_CERT_DATA- OPENSHIFT_KEY_DATA- OPENSHIFT_MASTER-
証明書を取得します。
- 外部の認証局 (CA) を使用して証明書に署名する場合、以下の内部プロセスに従って、新規の証明書を作成し、これを OpenShift Container Platform に指定します。
内部の OpenShift Container Platform CA を使用して証明書に署名する場合は、以下のコマンドを実行します。
重要以下のコマンドは、内部で署名される証明書を生成します。これは、OpenShift Container Platform CA を信頼するクライアントによってのみ信頼されます。
$ cd /root $ mkdir cert ; cd cert $ oc adm ca create-server-cert \ --signer-cert=/etc/origin/master/ca.crt \ --signer-key=/etc/origin/master/ca.key \ --signer-serial=/etc/origin/master/ca.serial.txt \ --hostnames='*.hostnames.for.the.certificate' \ --cert=router.crt \ --key=router.key \
これらのコマンドは以下のファイルを生成します。
- router.crt という名前の新規の証明書
- 署名する CA 証明書チェーン /etc/origin/master/ca.crt のコピーです。このチェーンには中間の CA を使用する場合に複数の証明書が含まれる場合があります。
- router.key という名前の対応するプライベートキー。
生成された証明書を連結する新規ファイルを作成します。
$ cat router.crt /etc/origin/master/ca.crt router.key > router.pem
新規シークレットを生成する前に、現在のシークレットをバックアップします。
$ oc get -o yaml --export secret router-certs > ~/old-router-certs-secret.yaml
新規の証明書およびキーを保持する新規シークレットを作成し、既存のシークレットの内容を置き換えます。
$ oc create secret tls router-certs --cert=router.pem \ 1 --key=router.key -o json --dry-run | \ oc replace -f -
- 1
- router.pem は、生成した証明書の連結を含むファイルです。
以下のアノテーションを
router
サービスから削除します。$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name- \ service.alpha.openshift.io/serving-cert-signed-by-
アノテーションを再度追加します。
$ oc annotate service router \ service.alpha.openshift.io/serving-cert-secret-name=router-certs
ルーターを再デプロイします。
$ oc rollout latest dc/router