VPN の Compose ファイルを共有しますか？レンダリング後のコピーから秘密情報を削除する

Compose ファイルを共有するときは常に二つの成果物がある：自分が書いたものと、ツールが変数を置換した後にレンダリングするものだ。後者は前者より機密性が高く、しかも読まずに問題報告へ貼られるのはたいていこちらである。ソースファイルだけを確認するのは、間違った文書を確認していることになる。

何を削除するかを決める前に、それぞれのコピーが何を含み得るかを比較する。

レンダリング後のモデルは別の文書である

Compose は環境変数を解決し、オーバーライドファイルをマージし、手書きの値と区別がつかなくなった実効設定を生成する。ソース上の変数名という参照は、出力ではアカウントのトークンそのものになる。診断に役立つ構造はこの変換を生き延び、決して含まれるべきでなかったものも同じように生き延びる。

添付する前にファイルを自分でレンダリングし、その出力を確認対象の成果物として扱う。レンダリングできないなら、何を公開しようとしているのかを知ることはできない。

秘密情報は鍵のフィールド以外にもある

明白なものから始める：秘密鍵、事前共有鍵、トークン、パスワード、認証情報を埋め込んだ接続 URL だ。参照は削除ではないので、次にファイルが参照するすべてを見る。サービスにマウントされた env ファイル、ホストからバインドマウントされた設定ファイル、トークンを載せたラベル、パスワードを含むコマンド引数は、YAML がきれいに見えても配備と一緒に運ばれる。安心させる名前の変数に貼られた鍵も、やはり鍵である。

ホストのパスとサービス名は二種類目の情報を漏らす。ホームディレクトリ名、内部ホスト名、ネットワーク範囲は、認証情報を一つも含まずに個人や組織を特定し得るので、その文脈も同じ理由で削除する価値がある。

秘密の宣言は秘密ではない

Compose の secret オブジェクトは宣言と実体を分離する：サービスはパスまたはターゲットを受け取り、内容は別の場所に置かれる。レビューする人は秘密が存在することと、どうマウントされるかを見る必要があるため、宣言を残して実体を置き換えるのが通常は正しい取引だ。生き残ってはいけないのは内容そのものである。

ラベルとコメントも同じ扱いが必要だ。どの vault パスが本番鍵を保持しているかを書いたコメントは、鍵を含んでいなくても攻撃者にどこを見るべきかを教える。

形を残して、ファイルが診断に使えるようにする

ネットワークモード、イメージのバージョン、ケイパビリティ設定を削除する墨消しは、誰もデバッグできないファイルを生む。機密の値だけを置き換え、関係（どのサービスが何をマウントし、どのネットワークに参加し、どのデバイスを必要とするか）は残す。読者が 欠けたルートや利用できないデバイスを説明する ために使うのはこの部分である。同僚が自分の動作中の配備と比較できるのもこの版だ。

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

墨消ししたコピーを、動作する原本のように配備してはいけない。それは説明であり、安全に見えるよう編集された説明は設定の不具合のように失敗する。

素材が露出したなら、差し替える

添付を外しても、他人がすでに作ったコピーは消えず、ミラーやキャッシュは自前のものを保持する。漏えいしたものについては発行者の失効と交換の手順を使い、その後に配備を更新する。順序が重要で、先に交換して後に失効させると、有効な認証情報が二つある窓が残る。

サポートスレッドでは、正確なエラー、イメージのバージョン、ネットワークモード、そして重要で秘密ではない設定を一つ先に示す。その組み合わせのほうが、鍵よりもはるかに多く、欠けたデバイスや壊れたルートを説明する。