Kubernetesの証明書管理という言葉を聞くと、多くのエンジニアは「cert-managerを入れれば終わり」というイメージを持つ。しかし実際の現場で証明書更新が炎上する原因は、たいてい技術ではない。TerraformやHelmのコードを書く作業そのものは1〜2日で終わっても、それを本番に適用する許可を得るまでに1〜2ヶ月かかる、という話は決して珍しくない。
証明書が原因のインシデントは、いまだに「よくある事故」の代表格だ。ある調査では、過去1年間に証明書関連の障害を一度以上経験した組織は7割を超えるとされている（Gart Solutions のレポート）。原因不明のダウンタイムを調べてみたら、犯人は期限切れのTLS証明書だった——という展開は、インフラエンジニアなら一度は経験しているはずだ。
この記事では、証明書更新がなぜ「手続きの問題」になりやすいのかを構造的に解説し、cert-managerによる自動化の範囲と限界、そして運用負債を最初から負わない設計について整理する。実は、この負債の一部はKuboのようなマネージドK8sを選ぶことで、そもそも発生させずに済む場合がある。
1. 証明書が切れる本当の理由は「技術」ではなく「手続き」だった
多くの組織における証明書更新のフローは、驚くほどアナログだ。期限が近づいた証明書を誰かが見つけ、CSR（証明書署名要求）を手動で作成し、それを別チームや外部の認証局担当者に送り、署名済み証明書を受け取り、最後に手動でアップロードする。このプロセスには複数の承認ポイントと部門間のやり取りが挟まり、1件の更新に数週間かかることも珍しくない。
問題は、この手続きが「誰の担当なのか」が曖昧なまま運用されているケースが多いことだ。証明書の所有者が明確でないシステムでは、期限切れの兆候に誰も気づかず、本番環境がダウンしてから初めて発覚する。Encryption Consultingのまとめでは、2018年にEricssonの証明書管理システムの障害が原因で英国内だけで約3200万人が4Gサービスを利用できなくなった事例や、2017年のEquifaxの情報漏洩において監視デバイスの証明書失効が19ヶ月間気づかれずに放置されていた事例が紹介されている。いずれも、技術的な原因は「証明書が切れていた」というシンプルな一点だが、それに気づく仕組みが組織内に存在しなかったことが被害を拡大させた。
さらに厄介なのは、技術的な改善（例えばTerraformで証明書更新を自動化するコードを書くこと）自体はごく短期間で完成するにもかかわらず、それを「本当に何も壊れないのか」「既存の運用フローとどう整合するのか」という説明・合意形成に想像以上の時間がかかる点だ。コードを書くことは今の時代、比較的簡単な部類の作業になっている。難しいのは、変更を安全に導入するための「手続き」の設計である。
2. cert-manager は何を自動化し、何を自動化しないのか
Kubernetesエコシステムには、この証明書運用の負担を軽減するための定番ツールがある。それがcert-managerだ。cert-manager公式ドキュメントによると、cert-managerには「ingress-shim」というサブコンポーネントが含まれており、Ingressリソースに特定のannotationを付けるだけで、対応するCertificateリソースを自動生成する。開発者はcert-manager.io/cluster-issuerのようなannotationを1行追加するだけで、証明書の発行・格納・更新をcert-managerに委ねられる。
証明書の発行元を管理するリソースにはIssuerとClusterIssuerの2種類がある。cert-managerのIssuerに関する公式ドキュメントによれば、Issuerは名前空間に閉じたスコープを持ち、その名前空間内のリソースからしか参照できない。一方ClusterIssuerはクラスタ全体からスコープを持ち、複数の名前空間にまたがるIngressやCertificateから共通の認証局設定を参照できる。組織全体で証明書発行ポリシーを統一したい場合はClusterIssuer、チームごとに異なる認証局を使い分けたい場合はIssuerを使う、という判断基準になる。
証明書発行元としてよく使われるのがLet's Encryptだ。ただし本番用のACMEエンドポイントには発行数の制限がある。Let's Encrypt公式のレート制限ドキュメントでは、1つのアカウントあたり3時間に新規オーダー300件まで、同一ドメインには7日間に証明書50件までといった上限が定められている。開発中に本番用エンドポイントへ何度も証明書リクエストを送るとこの制限に引っかかりやすいため、Let's Encryptはステージング環境の利用を強く推奨している。cert-managerを「入れて終わり」にできない理由の一つは、こうした運用上の制約を理解した上でIssuer設計・監視体制を構築する必要があるからだ。
cert-manager単体では防げない失効リスク
cert-managerは証明書の自動更新を担うが、更新が失敗した場合に誰も気づかない状態は防げない。ACMEチャレンジの失敗、DNS設定の不整合、権限不足によるSecret更新失敗など、自動化された仕組みの中でも障害は起きる。この「自動化はしたが監視はしていない」という状態が、後述する運用設計の重要なポイントになる。
3. 証明書更新を「儀式」から「非イベント」に変える設計
証明書管理を本当に「運用の負債」から解放するには、cert-managerを導入するだけでなく、更新プロセスそのものを人間の気づきに依存させない設計が必要だ。その代表的な手段が、証明書の有効期限をメトリクスとして継続的に監視する仕組みだ。
Prometheus公式ドキュメントによると、Prometheusは数値時系列データを収集・保存するオープンソースの監視ツールで、収集したメトリクスに対してルールを評価し、条件を満たした場合にAlertmanagerを通じて通知を発行する仕組みを持つ。cert-managerのメトリクスをPrometheusで収集し、証明書の残り有効期限が一定のしきい値を下回った際にアラートを発火させることで、「誰かが気づく」から「システムが知らせる」へと運用の前提を変えられる。
さらに、証明書のライフサイクル自体が今後さらに短くなっていく点も無視できない。Sectigoのブログ記事によれば、業界標準の証明書有効期間は2026年3月から398日から200日に短縮され、2027年には100日、2029年には47日まで段階的に短縮される計画が決まっている。有効期間が短くなるほど更新頻度は増え、手動運用の負荷は指数関数的に増大する。同記事は、この段階では「手動での証明書管理は持続不可能になる」と指摘している。つまり、今のうちに更新プロセスを自動化・監視体制込みで設計しておくことは、将来的な運用コストの先取り対策でもある。
日本語圏でも、この分野の解説記事は増えている。ITmediaの記事は、証明書の更新忘れという典型的な事故を防ぐためにcert-managerを導入する入門的な内容を紹介しているが、多くの解説記事は「導入方法」に主眼を置いており、更新プロセスの所有者を明確化する、監視・アラート込みで設計する、といった運用面の負債を減らす視点にまで踏み込んでいるものは少ない。
Rancherベースの環境でも同様の設計思想が当てはまる。Rancher環境でのcert-manager構築を扱う技術ブログでは、K3s/Rancher環境でHelmを使ってcert-managerをデプロイし、Let's EncryptやRancher CAと連携させる手順が紹介されている。K3sベースの軽量なクラスタであっても、証明書管理の自動化と監視の重要性は変わらない。
4. マネージドK8sなら、この手続き自体が最初から存在しない
ここまで見てきたように、証明書管理を「安心して回る仕組み」にするには、cert-managerの導入だけでなく、Issuer設計、レート制限を踏まえたテスト運用、Prometheusによる監視・アラート体制の構築まで、複数のレイヤーを積み上げる必要がある。これは決して小さな作業ではなく、多くの組織がここでつまずいて「証明書更新は面倒なもの」という認識のまま放置してしまう。
KuboはK3sベースのマネージドKubernetesサービスで、cert-manager + Let's Encryptがあらかじめ標準搭載されている。つまり、この記事で解説したIssuer設計・監視体制の構築フェーズそのものが、利用開始時点で完了している状態から始められる。EKSやAKS上で自前にcert-managerを構築・検証・監視設定する場合と比べて、証明書運用にかかる初期構築コストと属人化リスクを大きく削減できる。
証明書更新の「手続きの複雑さ」に日々悩まされているなら、そもそもその手続き自体を持たない選択肢を検討する価値がある。Kuboは、本格的なKubernetesの機能はそのままに、こうした運用の負債を最初から背負わない構成で提供されている。
5. まとめ
証明書管理の本質的な課題は、cert-managerというツールの有無ではなく、「更新プロセスの所有者は誰で、それをどう監視するか」という運用設計にある。自動化ツールを導入することと、手続きの負債をなくすことは似ているようで別の問題だ。cert-manager自体は優れたツールだが、Issuer/ClusterIssuerの設計、レート制限を踏まえた運用、監視・アラート体制まで含めて構築しなければ、「入れたのに気づいたら失効していた」という事態は起こり得る。
証明書のライフサイクルが今後さらに短縮されていく中で、この運用負債を先送りにするコストは年々増していく。証明書更新のたびに会議が発生する状態から抜け出したいなら、まずは自分たちの証明書運用フローの「所有者」と「監視体制」を明確にすることから始めてほしい。そのうえで、Kuboのように証明書管理を標準搭載したマネージドKubernetesを選ぶことも、有効な選択肢の一つだ。証明書運用について相談したい場合は、お問い合わせから気軽に連絡してほしい。