9.9. cert-manager Operator for Red Hat OpenShift によるルート保護
OpenShift Container Platform では、シークレット経由で TLS 証明書を参照するための設定可能なオプションを提供するために、ルート API が拡張されました。外部で管理される証明書を使用してルートを作成する テクノロジープレビュー機能を有効にすると、手動介入によるエラーを最小限に抑え、証明書管理プロセスを効率化し、OpenShift Container Platform ルーターが参照された証明書を迅速に提供できるようになります。
cert-manager Operator for Red Hat OpenShift を使用してルートを保護する機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
9.9.1. クラスター内のルートを保護するための証明書の設定
次の手順は、Let's Encrypt ACME HTTP-01 challenge タイプを使用して cert-manager Operator for Red Hat OpenShift を利用し、OpenShift Container Platform クラスター内のルートリソースを保護するプロセスを示しています。
前提条件
- cert-manager Operator for Red Hat OpenShift のバージョン 1.14.0 以降がインストールされている。
-
RouteExternalCertificate
フィーチャーゲートを有効にした。 -
routes/custom-host
サブリソースに対するcreate
およびupdate
権限がある。 -
公開する
Service
リソースがある。
手順
次のコマンドを実行して、エッジ TLS Termination とカスタムホスト名を使用して、
Service
リソースのRoute
リソースを作成します。ホスト名は、次の手順でCertificate
リソースを作成するときに使用されます。$ oc create route edge <route_name> \ 1 --service=<service_name> \ 2 --hostname=<hostname> \ 3 --namespace=<namespace> 4
次のコマンドを実行して、HTTP-01 ソルバーを設定する
Issuer
を作成します。その他の ACME 発行者タイプについては、「ACME 発行者の設定」を参照してください。Issuer.yaml
ファイルの例$ oc create -f - << EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-acme namespace: <namespace> 1 spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-acme-account-key solvers: - http01: ingress: ingressClassName: openshift-default EOF
- 1
Issuer
が配置されている namespace を指定します。ルートの namespace と同じである必要があります。
次のコマンドを実行して、ルートの
Certificate
オブジェクトを作成します。secretName
は、cert-manager が発行および管理する TLS シークレットを指定し、次の手順のルートでも参照されます。$ oc create -f - << EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-route-cert namespace: <namespace> 1 spec: commonName: <hostname> 2 dnsNames: - <hostname> 3 usages: - server auth issuerRef: kind: Issuer name: letsencrypt-acme secretName: <secret_name> 4 EOF
次のコマンドを使用して、参照されたシークレットを読み取るためのルーターサービスアカウント権限を付与する
Role
を作成します。$ oc create role secret-reader \ --verb=get,list,watch \ --resource=secrets \ --resource-name=<secret_name> \ 1 --namespace=<namespace> 2
次のコマンドを使用して、ルーターサービスアカウントを新しく作成した
Role
リソースにバインドするRoleBinding
リソースを作成します。$ oc create rolebinding secret-reader-binding \ --role=secret-reader \ --serviceaccount=openshift-ingress:router \ --namespace=<namespace> 1
- 1
- シークレットとルートの両方が配置されている namespace を指定します。
次のコマンドを使用して、ルートの
.spec.tls.externalCertificate
フィールドを更新し、以前に作成したシークレットを参照し、cert-manager が発行した証明書を使用します。$ oc patch route <route_name> \ 1 -n <namespace> \ 2 --type=merge \ -p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}' 3
検証
次のコマンドを実行して、証明書が作成され、使用できる状態になっていることを確認します。
$ oc get certificate -n <namespace> 1 $ oc get secret -n <namespace> 2
次のコマンドを実行して、ルーターが参照された外部証明書を使用していることを確認します。コマンドは、ステータスコード
200 OK
を返すはずです。$ curl -IsS https://<hostname> 1
- 1
- ルートのホスト名を指定します。
次のコマンドを実行して、サーバー証明書の
subject
、subjectAltName
、issuer
が、すべて curl verbose 出力から期待されるとおりであることを確認します。$ curl -v https://<hostname> 1
- 1
- ルートのホスト名を指定します。
これでルートは、cert-manager が発行した参照シークレットの証明書で正常に保護されました。cert-manager は証明書のライフサイクルを自動的に管理します。