こんにちは！クラウドインフラの世界へようこそ。
Kubernetes（クーベネティクス）を使ってウェブアプリを動かすようになると、必ずぶ
つかるのが「通信の暗号化（HTTPS対応）」ですよね。
「ブラウザに鍵マークを出したい！」
「通信をのぞき見られないように安全にしたい！」
そう思ってTLS証明書を手に入れたものの、「3ヶ月ごとに手動で更新なんてやってられない……」「うっかり期限を切らして、お客様の画面に『この接続は安全ではありません』と表示されて冷や汗をかいた……」そんな苦い経験をお持ちの方も多いのではないでしょうか。
今回は、Kubernetes環境において、その面倒な証明書管理を完全に自動化してくれる心強い相棒 cert-manager と、入り口の門番である Ingress Controller の組み合わせについて、身近な防犯の仕組みに例えながら優しく紐解いていきます。
一歩ずつ、安全なインフラ作りを学んでいきましょう！
—
1. 例え話で納得！Kubernetesの通信とTLS証明書
まずは、少しイメージを膨らませてみましょう。
あなたが大切なお店（Kubernetes上のウェブアプリ）を経営しているとします。お店には毎日たくさんのお客様（ユーザー）がやってきて、注文用紙（リクエスト）を渡してくれます。
もし、お店とお客様のやり取りが「丸見えのハガキ」だったらどうでしょう？ 悪意ある泥棒（攻撃者）に、お客様のクレジットカード番号やパスワードを途中で盗み見られてしまいますよね。
ここで登場するのが TLS（HTTPS） という「頑丈な鍵付きの透明なアタッシュケース」です。このケースに入れてやり取りすれば、途中で泥棒にのぞき見られても、中身は暗号化されていて絶対に読めません。
しかし、ここで一つ問題があります。
「そのアタッシュケースの鍵は、本当にそのお店が持っている本物か？」を証明しなければ、お客様は安心して買い物ができませんよね。そこで信頼できる第三者機関（Let’s Encryptなど）に「この店は本物ですよ」という身分証明書（TLS証明書）を発行してもらう必要があります。
厄介なのは「証明書の有効期限」
この身分証明書、実は「3ヶ月（90日）ごとに新しいものへ取り替えなければならない」というルールがあります。
もし、うっかり取り替えを忘れて期限切れになると、お店の入り口で警備員が「おい、この身分証明書は期限切れだ！危ないから入れない！」と、お客様を追い返してしまうのです。
これを人間の手で毎回やろうとすると、忙しい開発者はすぐに疲弊してしまいますよね。そこで、「証明書の期限が近づいたら、自動的に裏でこっそり新しい身分証明書をもらってきて、自動で付け替えてくれる優秀な秘書」を雇いましょう。それが今回紹介する cert-manager です。
—
2. 全体像を把握する：Ingressとcert-managerの役割
Kubernetesの世界では、外部からやってきた通信を受け止める最初の窓口を Ingress Controller（Nginx Ingress Controllerなど）と呼びます。いわば「お店の正面玄関の受付係」ですね。
そして、この受付係に「HTTPSで安全にお客様を迎えてね」と指示を出すのが Ingressリソース です。
全体の仕組みを図解の代わりに言葉で整理すると、こうなります。
1. お客様がアクセス：ブラウザから https://example.com にアクセスする。
2. IngressがTLS終端を担当：玄関（Ingress Controller）で「鍵付きのアタッシュケース」の鍵を開け、中身を取り出して安全な店内に通す（これを TLS終端（TLS Termination） と呼びます）。
3. cert-managerが裏で監視：「そろそろ身分証明書の期限が切れるぞ」と気づいた cert-manager が、Let’s Encryptに自動で新しい証明書をオーダーし、Kubernetesの秘密情報保管庫（Secret）にこっそり補充する。
この連携プレーにより、人間が何もしなくても、24時間365日安全なHTTPS通信が維持されるというわけです。
—
3. 実践！設定ファイルを書いてみよう
それでは、実際にKubernetesへデプロイする設定ファイル（マニフェスト）を見ていきましょう。
今回は、cert-manager をあらかじめクラスタにインストール済みの環境を前提に、「Let’s Encryptから証明書を自動発行してもらい、Ingressで適用する」までの手順をコードで解説します。
ステップ1：Issuer（発行者）の定義
まずは、「どこから、どうやって証明書をもらうか」を cert-manager に教えるための設定（Issuer または ClusterIssuer）を作成します。ここでは無料の証明機関である Let’s Encrypt を指定します。
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod # クラスタ全体で使える発行者名
spec:
acme:
# Let's Encryptの本番サーバーのURL
server: https://acme-v02.api.letsencrypt.org/directory
# 証明書の有効期限切れや重要な通知を受け取るためのあなたのメールアドレス
email: your-email@example.com
# 証明書の鍵を保存するKubernetesのSecret名
privateKeySecretRef:
name: letsencrypt-prod-account-key
# 「HTTP-01」という方式を使って、ドメインの所有権を証明します
solvers:
- http01:
ingress:
class: nginx> 💡 現場の泥臭いワンポイントアドバイス：
> 最初から本番用（letsencrypt-prod）でテストを繰り返すと、Let’s Encrypt側から「短期間に何度もリクエストを送るな！」と一時的なアクセス制限（レートリミット）を食らうことがあります。最初は必ずテスト用のサーバー（https://acme-staging-v02.api.letsencrypt.org/directory）を使って動作確認をするのが、百戦錬磨のインフラエンジニアの知恵です！
ステップ2：Ingressリソースと証明書自動化の紐付け
次に、いよいよ本丸である Ingress リソースの設定です。ここに cert-manager 向けの「アノテーション（注釈）」を書き込んでおくことで、マジックのように自動で証明書が生成されます。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
namespace: default
annotations:
# cert-managerに対して「このIngress用の証明書を自動作成して！」と指示する呪文
cert-manager.io/cluster-issuer: "letsencrypt-prod"
# Nginx Ingress Controllerに「HTTPへのアクセスは強制的にHTTPSにリダイレクトしてね」と伝える設定
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
# 使用するIngress Controllerの種類を指定
ingressClassName: nginx
tls:
- hosts:
- example.com
# 自動作成された証明書が格納されるKubernetesのSecret名（名前は自由ですが分かりやすく）
secretName: example-com-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-service
port:
number: 80このたった数行のアノテーション (cert-manager.io/cluster-issuer) を書き加えるだけで、cert-manager が裏で自動的にIngressのルールを読み取り、Let’s Encryptとの通信を行って、example-com-tls という名前の Secret（鍵の束）を自動生成してくれます。
—
4. 現場でありがちなトラブルと対策（トラブルシューティング）
「よし、設定ファイルを適用したぞ！」と意気込んだものの、なぜかブラウザでアクセスするとエラーになる……。そんなときに現場で確認すべきポイントをいくつかご紹介します。
① 証明書がいつまでも発行されない（Pendingのまま）
- 原因と対策：
cert-manager のログを確認してみましょう。以下のコマンドで様子を見ることができます。
kubectl describe certificate example-com-tls
大抵の場合、ドメインのDNS設定（Aレコード）が、Kubernetesのロードバランサー（外向きのIPアドレス）を正しく向いていないことが原因です。Let’s Encryptが「本当にこのドメインの持ち主か？」を確認しに来たとき、正しく応答できないと証明書は発行されません。
② ブラウザで「保護されていない通信」と言われる
- 原因と対策：
前述の通り、テスト環境（Staging）の ClusterIssuer を使ったままになっていませんか？ Staging環境の証明書は「ブラウザにとって信頼できない偽物の証明書」を使ってテストするため、警告画面が出るのは正常な動作です。本番環境用の ClusterIssuer に切り替えているか確認してみてください。
—
まとめ
今回は、Kubernetesにおける Ingress Controller と cert-manager を使った、TLS証明書の自動化についてお話ししました。
- TLS証明書は、お店の身分証明書のようなもの。3ヶ月ごとの更新が必要。
cert-managerは、面倒な更新作業を裏で完璧にこなしてくれる優秀な秘書。- Ingressにちょっとしたアノテーションを書くだけで、安全なHTTPS環境が自動で手に入る。
セキュリティの対策と聞くと「難しそう」「面倒くさそう」と感じてしまうかもしれませんが、一度自動化の仕組みを作ってしまえば、あとはインフラが勝手にあなたの大切なシステムを守り続けてくれます。
一歩ずつ、確実に知識と仕組みをアップデートして、自信を持ってセキュアなアプリケーションを世の中に届けましょう！あなたのインフラライフが、より安全で快適なものになりますように。
コメント