鍵をコピーせずに Raspberry Pi VPN アプライアンスを再構築する

イメージから一度起動しただけでは、Pi は再構築可能なアプライアンスにはなりません。必要なのは、再適用できる小さな入力の集合、すなわち、保守されたベース、宣言された構成、アプリケーションの永続データ、そしてそのボードだけに属するデバイス識別情報です。最後の一つを忘れると、交換のたびに資格情報のクローンが生まれます。

以下の手順は作業の順序であり、ツールの推奨ではありません。それを表現できる構成管理システムなら何でも構いません。

まず四種類の入力を列挙する

ベースイメージとそのパッケージは、オペレーティングシステム、アーキテクチャ、更新の入手元を定義し、イメージビルダーは、それが名指すツールがお使いのリリース向けにまだ保守されている場合にのみ役立ちます。宣言された構成は人がレビューする部分で、ネットワークの役割、サービスの設定、各サービスが必要とするライフサイクル操作を含みます。アプリケーションの永続データは、サービスが再生成できないすべてであり、その場所とバックアップ方法はイメージではなくそのアプリケーションに属します。デバイス識別情報と秘密は四番目の入力であり、動作中のカードをクローンするときに人々が忘れるのはまさにこれです。

何かを再構築する前に四つのリストを書きます。空の行があるリストは、まだ下していない決定です。

秘密をリポジトリの外に置き、どこにあるかを明示する

リポジトリは、レビュー済みのテンプレートや秘密でない構成の置き場所としては適していますが、VPN の秘密鍵、再利用可能な管理者資格情報、診断アーカイブの置き場所としては不適切です。秘密をデバイス上に置かざるを得ない場合は、その出所、読める人、ローテーション方法を記録します。一枚の SD カードにしか存在しない鍵は単一障害点であり、すべてのボードにコピーされた鍵は所有者のいないフリート全体の資格情報です。どちらも復旧計画にはなりません。

テストは簡単です——明日リポジトリが漏れたら、攻撃者は何を得るでしょうか。テンプレートとトポロジーのメモは生き残ります。動作する識別情報は生き残りません。

再実行できるものは自動化に所有させる

Ansible のモデルは、管理対象ノードのインベントリを、プレイ、タスク、ロール、そしてタスクが変更を報告したときに起動するハンドラから分離して保ちます。その構造を使って 各サービスに構成の所有者を一人だけ与え、シェル履歴を再生するのはやめましょう。二度実行しても安全な操作を選び、変更されたファイルが実行中のプロセスにどう届くかを意識的に決めます。サービスの起動を保証するタスクは、書き換えたばかりの構成を必ずしも再読み込みさせません。

管理の段階も分けます。ブートストラップ接続、日常的な構成、VPN に依存する管理は三つの異なる時間帯であり、三番目は、再構築がその下のネットワークを初期化すると自分のアクセスを失わせる可能性があります。独立した進入経路を確保してください。

データと識別情報を意図的に復元する

コンテナのボリュームはコンテナのライフサイクルとは独立して永続しますが、コンテナ内の書き込み可能レイヤーはそうではないため、イメージからコンテナを作り直しても、アプリケーションが使っていた状態は再現されません（ボリュームのドキュメントが説明するとおりです）。アプライアンスが依存するボリューム、バインドマウント、外部サービスを記録し、アプリケーション自身のバックアップと復元の手順を使います。エラーなく起動するコンテナは、データベースとファイルが一致している証拠ではありません。

識別情報については、同じデバイスを復元するのか、交換品を登録するのかを決めますが、どちらも後片付けの異なる別の操作です。

他の場所で識別情報を有効にする前に、古いピアのアクセスを整合させ、その後にだけ、再構築したアプライアンスを隔離環境または復旧環境で試験します。必要なデータ、正しい識別情報、所有者のいる更新経路、意図したネットワークポリシーを確認します。

起動可能なイメージは四つの入力のうちの一つであり、最も再現しやすいものです。