ルートを替えた瞬間、誰が誰を信じられなくなるか
一言でいうと
istiodは、デフォルトでは自分で作ったルートでワークロード証明書に署名します。プラグインCAは、組織のルートが署名した中間CAをcacertsSecretとしてistiodに差し込み、メッシュの身元を組織のPKIの下に入れる方法です。すでに動いているメッシュでこれを変える瞬間、古いルートだけを信頼するワークロードと、新しい証明書を受け取ったワークロードが、互いを信頼できなくなります。
なぜ必要なのか
自己署名ルートは始めるには便利ですが、困る点が3つあります。ルートの鍵がクラスターの中(istio-ca-secret)にあるため、クラスターが破られるとルートも破られます。クラスターごとにルートが違うため、2つのクラスターのワークロードが互いを信頼できません。そして、組織の監査・失効の体系の外にあります。
Istioのドキュメントが勧める構造はこうです。ルートCAはセキュリティの強いオフラインのマシンに置き、そのルートでクラスターごとに中間CAを発行して、各istiodに渡します。istiodはその中間CAでワークロード証明書に署名し、管理者が渡したルートを信頼の起点(トラストアンカー)としてワークロードに配ります。中間CA 1つが漏れてもルートは無事で、同じルートの下のクラスター同士は、互いのワークロードを信頼します。
どう動くのか
cacertsの4つのファイル
| キー | 内容 |
|---|---|
ca-cert.pem |
istiodが使う中間CA証明書 |
ca-key.pem |
その秘密鍵 |
root-cert.pem |
ワークロードに配るルート |
cert-chain.pem |
中間CA → ルートにつながるチェーン |
istiodは起動するときにistio-system/cacertsを探します。あればそれを使い(ログに、cacertsからルートを読んだと残ります)、なければ自分で作ったルートを使います。起動済みのistiodは、後からできたSecretに気づかないので、再起動する必要があります。
ワークロード証明書はサイドカーが受け取ります。サイドカーのエージェントが鍵を作ってistiodに署名を要求し、短命(デフォルトは24時間)の証明書を受け取ってEnvoyにSDSで入れ、期限が切れる前に自動で入れ替えます。身元はsubjectではなく、SANのSPIFFE URI(spiffe://cluster.local/ns/bank/sa/client)に入ります。認可ポリシーのprincipalsがまさにこの値なので、CAを変えても、トラストドメインが同じならポリシーはそのままです。
ルートを変える瞬間。新しいistiodは、ネームスペースごとにistio-ca-root-certを新しいルートに替え、新しく起動したPodは新しいルートを信頼し、新しい中間CAが署名した証明書を受け取ります。ところが、すでに起動しているサイドカーは古いルートだけを持っています。mTLSは両側が互いのチェーンを検証するので、新しい証明書を受け取ったwebと、古いルートだけを信頼するclientの間では、接続が張れません(503)。すべて再起動するか、証明書が入れ替わるまで、この状態が続きます。
Istio 1.31のドキュメントのプラグインCAの手順は、インストールする前にcacertsを差し込む場合を扱っています。すでに動いているメッシュで変えると、上のような途切れが生じることを、このラボで自分で見ます。その観察から出る結論は1つです。途切れる理由が「互いのルートを知らない」ことなので、運用中に変えるなら、すべてのワークロードが新しいルートを信頼するようになることと、新しいCAで署名し始めることを分けて順序を決め(2つのルートを一緒に信頼する期間)、全員が新しい証明書を受け取った後で、古いルートを外す必要があります。
現場での姿
cacertsを入れたのに証明書のissuerがそのままの場合です。istiodを再起動していないか、Podがまだ古い証明書を使っています。istiodのログと、サイドカーのproxy-config secretを分けて見ます。
CAを変えた後、一部のサービス間だけ503になる場合です。片側だけ再起動された組です。2つのサイドカーのROOTCAとワークロード証明書のissuerを並べて見れば、すぐわかります。
2つのクラスターをつないだのに、互いにmTLSができない場合です。2つのistiodが別々のルートを使っています。同じルートの下の中間CAを、それぞれに差し込む必要があります。
公式ドキュメント: Plug in CA Certificates・Security — PKI・Identity and certificate management
次のラボですること
istiodが自分で作ったルートをまず確認し、ディストリビューションのMakefileでルートとクラスター用の中間CAを作って、cacertsとして差し込みます。webだけを再起動して、片側だけが新しい証明書を受け取った状態の503を体験し、clientまで再起動して復旧させた後、新しいチェーンが自分たちのルートまでつながるかと、身元・寿命を証明書から直接読みます。