9.9. cert-manager Operator for Red Hat OpenShift によるルート保護
OpenShift Container Platform では、シークレット経由で TLS 証明書を参照するための設定可能なオプションを提供するために、ルート API が拡張されました。外部管理証明書 を有効にすると、手動介入によるエラーを最小限に抑え、証明書管理プロセスを効率化し、OpenShift Container Platform ルーターが参照先の証明書を迅速に提供できるようになります。
9.9.1. クラスター内のルートを保護するための証明書の設定 リンクのコピーリンクがクリップボードにコピーされました!
次の手順は、cert-manager Operator for Red Hat OpenShift を Let’s Encrypt の ACME HTTP-01 チャレンジタイプとともに使用して、OpenShift Container Platform クラスター内のルートリソースを保護するプロセスを示しています。
前提条件
- cert-manager Operator for Red Hat OpenShift のバージョン 1.14.0 以降がインストールされている。
-
ルートの作成と更新の両方に使用される
routes/custom-hostサブリソースに対するcreate権限がある。 -
公開する
Serviceリソースがある。
手順
次のコマンドを実行して、HTTP-01 ソルバーを設定する
Issuerを作成します。その他の ACME 発行者タイプについては、「ACME 発行者の設定」を参照してください。Issuer.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
Issuerが配置されている namespace を指定します。ルートの namespace と同じである必要があります。
次のコマンドを実行して、ルートの
Certificateオブジェクトを作成します。secretNameは、cert-manager が発行および管理する TLS シークレットを指定し、次の手順のルートでも参照されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、参照先のシークレットを読み取る権限をルーターのサービスアカウントに付与するための
Roleを作成します。oc create role secret-reader \ --verb=get,list,watch \ --resource=secrets \ --resource-name=<secret_name> \ --namespace=<namespace>
$ oc create role secret-reader \ --verb=get,list,watch \ --resource=secrets \ --resource-name=<secret_name> \1 --namespace=<namespace>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルーターのサービスアカウントを、新しく作成した
RoleリソースにバインドするRoleBindingリソースを作成します。oc create rolebinding secret-reader-binding \ --role=secret-reader \ --serviceaccount=openshift-ingress:router \ --namespace=<namespace>
$ oc create rolebinding secret-reader-binding \ --role=secret-reader \ --serviceaccount=openshift-ingress:router \ --namespace=<namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- シークレットとルートの両方が配置されている namespace を指定します。
次のコマンドを実行して、エッジ TLS 終端とカスタムホスト名を使用するサービスリソースのルートを作成します。ホスト名は、次のステップで
Certificateリソースを作成するときに使用します。oc create route edge <route_name> \ --service=<service_name> \ --hostname=<hostname> \ --namespace=<namespace>
$ oc create route edge <route_name> \1 --service=<service_name> \2 --hostname=<hostname> \3 --namespace=<namespace>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、ルートの
.spec.tls.externalCertificateフィールドを更新し、以前に作成したシークレットを参照し、cert-manager が発行した証明書を使用します。oc patch route <route_name> \ -n <namespace> \ --type=merge \ -p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}'$ oc patch route <route_name> \1 -n <namespace> \2 --type=merge \ -p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}'3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、証明書が作成され、使用できる状態になっていることを確認します。
oc get certificate -n <namespace> oc get secret -n <namespace>
$ oc get certificate -n <namespace>1 $ oc get secret -n <namespace>2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ルーターが参照された外部証明書を使用していることを確認します。コマンドは、ステータスコード
200 OKを返すはずです。curl -IsS https://<hostname>
$ curl -IsS https://<hostname>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ルートのホスト名を指定します。
次のコマンドを実行して、サーバー証明書の
subject、subjectAltName、issuerが、すべて curl verbose 出力から期待されるとおりであることを確認します。curl -v https://<hostname>
$ curl -v https://<hostname>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ルートのホスト名を指定します。
これでルートは、cert-manager が発行した参照シークレットの証明書で正常に保護されました。cert-manager は証明書のライフサイクルを自動的に管理します。