cert-manager経由でKubernetes IngressでLet’s EncryptのSSL証明書を使用する（後半）

この記事は長いので２つに分けてお送りします。今回は後半です。具体的なメソッドの続きです。

前述したように、ドメインのコントロールを証明するために利用できるものには、HTTP-01とDNS-01の2種類があります。

最初のアプローチ(HTTP-01)では、小さなウェブサーバーを別のデプロイメントとしてデプロイします。認証サーバーのリクエストごとに http://<YOUR_DOMAIN>/.known/acme-challenge/<TOKEN> URL でいくつかの情報を提供します。したがって、この方法では、80番ポートを介した外界からのIngressへのアクセス性と、ドメインのDNSレコードの公開することになります。

2番目のもの(DNS-01)は、ドメインのDNSレコードを変更するために使用できるAPIがあれば意味をなします。発行者はこれらのトークンを使用してドメインのTXTレコードを作成します。そして、ACME サーバは確認中にこれらのレコードを取得します。Let’s Encrypt は、CloudFlare、AWS Route53、Google CloudDNS などを含む様々な DNS プロバイダと簡単に統合することができます（LE 独自の DNS 実装である acme-dns と同様です）。

注意: Let’s Encrypt は ACME サーバへのリクエストにかなり厳しい制限を課しています。LE の本番環境に不要な負荷をかけないようにするために、テスト用にe letsencrypt-staging証明書を使うことをお勧めします (違いは ACME サーバのみです)。

それでは、リソースについて説明していきましょう。

apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt
solvers:
- http01:
ingress:
class: nginx
---
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: le-crt
spec:
secretName: tls-secret
issuerRef:
kind: Issuer
name: letsencrypt
commonName: yet-another.website
dnsNames:
- yet-another.website

Issuerには acme のserver フィールドにあるステージングサーバを使用していることに注意してください。これは後で本番サーバに置き換えることができます。

この設定を適用して、証明書の取得プロセス全体をトレースしてみましょう。

1. Certificate の作成は、新しい CertificateRequest リソースの出現につながる：

kubectl -n app describe certificate le-crt
...
Created new CertificateRequest resource "le-crt-1127528680"

2. その説明では、 Order 作成に関する通知があります。

kubectl -n app describe certificaterequests…