Nebula に必要な三つのファイル：CA、ホスト証明書、ホスト鍵

Nebula のディレクトリを人に渡すと、たいていはワークステーションから絶対に出してはいけないファイルまで含めて中身ごとすべてコピーされます。混乱は無理もありません。ホストの PKI ブロックにある三つのファイルは見た目が似ており、そのうち二つは証明書だからです。それぞれが別の問いに答えるもので、ノードに置くべきは二つだけなので、コピーする前に役割で仕分けてください。

三つのファイル、三つの異なる役割

CA 証明書は信頼の基点であり、別のホストが身元を提示したとき、どの機関を信じるべきかをホストに伝えます。ホスト証明書はノード自身の資格情報で、その機関によって署名されています。ホスト鍵は対応する秘密の半分であり、ちょうど一つのマシンに属します。CA 証明書と自分の鍵ペアを持つノードはオーバーレイに参加し、自分が誰であるかを証明できます。他人の鍵を持つノードもその人を名乗れてしまい、この構成はまさにその事故を防ぐためにあります。

動作しているホストディレクトリを二台目のマシンにコピーするのは、近道ではありません。結果の読める身元の複製にすぎません。

署名鍵は決して移動しない

CA の署名鍵はどのホスト設定にも含まれません。新しい身元を作り出す鍵であり、持っている者は任意のオーバーレイアドレスと任意のグループの証明書を発行できます。ピアが署名を検証するのに必要なのは公開 CA 証明書だけなので、秘密の半分はクライアントでは何の役割も持ちません。証明書を発行するマシンに保管し、うっかりした複製は便利なものではなくインシデントとして扱ってください。

複数の人が証明書を発行する必要があるなら、鍵の複製ではなく手順を渡してください。ノート PC 上の共有署名鍵は、誰も監査できず失効もできない権限です。

ホスト証明書の中身

ホスト証明書はファイル名以上のものを鍵に結び付けます。ノードのオーバーレイアドレス、名前、グループ所属を保持し、いずれも署名されているため、ピアは受け入れるかどうかを判断できます。だからこそホストの名前を変えることは、設定行を編集することではなく、新しい証明書を発行することを意味します。

nebula-cert print -path host.crt は実際に何が発行されたかを表示します。証明書が意図したアドレスを持っていると決めつける前に読んでください。

再読み込みだけでは足りないことがある

PKI の設定にはシグナルで再読み込みされるものと、そうでないものがあります。 オーバーレイアドレスが変わった証明書 は、再読み込みではなくプロセスの再起動が必要になる典型例です。

設定ファイルに書かれたパスだけでなく、実行中のプロセスが実際に開いたパスを確認してください。そのうえで一つの資格情報を変更し、接続とログを検証し、それから次に進みます。古い証明書がメモリに残ったまま成功したように見える再読み込みは、ルーティングの問題に見える不一致を生みます。再起動は安上がりですが、オーバーレイの半分がまだ古い見え方をしている身元をデバッグするのは安上がりではありません。

身元を外すにはブロックリストが要る

失った、あるいは露出した資格情報の交換には二つの半分があります。新しい証明書がアクセスを回復し、古い身元は受け入れられなくなります。これは別々の作業であり、前者だけを行うと漏れた資格情報は有効なままです。

ブロックリストはホストに配るファイルであり、lighthouse が勝手に配信するものではありません。今日オフラインのノードも含め、すべてのノードにどう届けるかを計画し、どの指紋をブロックしたかを記録してください。発行マシンで鍵をローテーションし、新しい証明書の情報をホストの記録と一緒に保管します。編集したマシンにしか存在しない失効は失効ではありません。