9.9. cert-manager Operator for Red Hat OpenShift によるルート保護

手順

1. 次のコマンドを実行して、HTTP-01 ソルバーを設定する Issuer を作成します。その他の ACME 発行者タイプについては、「ACME 発行者の設定」を参照してください。

   $ oc create -f - << EOF
   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-acme
     namespace: <namespace>
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       privateKeySecretRef:
         name: letsencrypt-acme-account-key
       solvers:
         - http01:
             ingress:
               ingressClassName: openshift-default
   EOF

   <namespace> を、発行者 が配置されている名前空間に置き換えてください。それは、ルートの名前空間と同じでなければなりません。

2. 次のコマンドを実行して、ルートの Certificate オブジェクトを作成します。secretName は、cert-manager が発行および管理する TLS シークレットを指定し、次の手順のルートでも参照されます。

   $ oc create -f - << EOF
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: example-route-cert
     namespace: <namespace>
   spec:
     commonName: <common_host>
     dnsNames:
       - <hostname>
     usages:
       - server auth
     issuerRef:
       kind: Issuer
       name: letsencrypt-acme
     secretName: <secret_name>
   EOF

   ここでは、以下のようになります。

   <namespace>

   証明書 リソースが配置されている 名前 空間を指定します。ルートの namespace と同じである必要があります。

   <common_host>

   ルートのホスト名を使用して、証明書の共通名を指定します。

   <hostname>

   証明書の DNS 名へのルートのホスト名を指定します。

   <secret_name>

   証明書を含むシークレットの名前を指定します。

3. 次のコマンドを使用して、参照先のシークレットを読み取る権限をルーターのサービスアカウントに付与するための Role を作成します。

   $ oc create role secret-reader \
     --verb=get,list,watch \
     --resource=secrets \
     --resource-name=<secret_name> \
     --namespace=<namespace>

   ここでは、以下のようになります。

   <secret_name>

   アクセスを許可するシークレットの名前を指定します。これは、Certificate リソースで指定された secretName と一致する必要があります。

   <namespace>

   シークレットとルートの両方が配置されている名前空間を指定します。

4. 次のコマンドを実行して、ルーターのサービスアカウントを、新しく作成した Role リソースにバインドする RoleBinding リソースを作成します。

   $ oc create rolebinding secret-reader-binding \
     --role=secret-reader \
     --serviceaccount=openshift-ingress:router \
     --namespace=<namespace>

   <namespace> を、シークレットとルートの両方が存在する名前空間に置き換えてください。

5. 次のコマンドを実行して、エッジ TLS 終端とカスタムホスト名を使用するサービスリソースのルートを作成します。ホスト名は、次のステップで Certificate リソースを作成するときに使用します。

   $ oc create route edge <route_name> \
     --service=<service_name> \
     --hostname=<hostname> \
     --namespace=<namespace>

   ここでは、以下のようになります。

   <route_name>

   ルート名を指定します。

   < サービス名 >

   公開したいサービスを指定します。

   <hostname>

   ルートのホスト名を指定します。

   <namespace>

   ルートが配置されている名前空間を指定します。

6. 次のコマンドを使用して、ルートの .spec.tls.externalCertificate フィールドを更新し、以前に作成したシークレットを参照し、cert-manager が発行した証明書を使用します。

   $ oc patch route <route_name> \
     -n <namespace> \
     --type=merge \
     -p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}'

   ここでは、以下のようになります。

   <route_name>

   ルート名を指定します。

   <namespace>

   シークレットとルートの両方が配置されている名前空間を指定します。

   <secret_name>

   証明書を含むシークレットの名前を指定します。

検証

1. 次のコマンドを実行して、証明書が作成され、使用できる状態になっていることを確認します。

   $ oc get certificate -n <namespace>
   $ oc get secret -n <namespace>

   <namespace> を、シークレットとルートの両方が存在する名前空間名に置き換えてください。

2. 次のコマンドを実行して、ルーターが参照された外部証明書を使用していることを確認します。コマンドは、ステータスコード 200 OK を返すはずです。

   $ curl -IsS https://<hostname>

   <hostname> を ルートのホスト名に置き換えてください。

3. 次のコマンドを実行して、サーバー証明書の subject、subjectAltName、issuer が、すべて curl verbose 出力から期待されるとおりであることを確認します。

   $ curl -v https://<hostname>

   <hostname> を ルートのホスト名に置き換えてください。これでルートは、cert-manager が発行した参照シークレットの証明書で正常に保護されました。cert-manager は証明書のライフサイクルを自動的に管理します。