取ってくる側、使う側、そしてミラーの三つの形

一言でいうと

エアギャップ環境のインフラ作業は、いつも2台のコンピューターに分かれます。インターネットにつながるダウンロード側が、必要なものを正確なバージョンで集めて、一覧と署名を付けると、インターネットのない利用側が、それを社内ミラーとして立てて、すべてのツールがそのミラーと社内証明書を信頼するようにします。このコースのすべてのモジュールは、この枠組みを、エコシステムごとに1回ずつ繰り返します。

なぜ必要なのか

エアギャップ環境のサーバーでは、pip install・npm ci・mvn package・go build・docker pull・dnf installは、すべて同じ形で失敗します。外部のリポジトリに届かないのです。ところが、直し方はツールごとに違います。PythonはPEP 503のインデックス、npmはレジストリAPI、Mavenはリポジトリのディレクトリ配置、Goはモジュールプロキシのプロトコル、コンテナはOCI配布仕様、dnfはrepodataを読みます。エコシステムごとにバラバラに覚えたらきりがありませんが、枠組みは1つです。何をどこから取得して、何でまとめて、どう指し示して、何を信頼させるのか、です。

どう動くのか

ダウンロード側と利用側: ダウンロード側は、対象サーバーの条件(OS・Python・JDK・CPU)を把握して取得する必要があります。ノートパソコンでノートパソコン用に取得したファイルは、サーバーでは合いません。利用側は、媒体を検証して、ミラーを立て、設定1行で、ツールがミラーを見るようにします。2つの間をつなぐのは、ファイルのまとまり、ハッシュの一覧、署名だけです。ネットワーク分離環境なら、その間にデータ転送の手続き(承認された媒体や転送システム、持ち込み審査)が挟まり、その往復は、たいてい1日単位です。そのため、一度で完結したまとまりを作る技術が、そのままエアギャップ環境の実務能力です。

ミラーの3つの形:

프록시 캐시   위(인터넷 저장소)를 당겨 남긴다. 연결된 동안 채우고, 끊으면 채운 것만 내준다
             verdaccio 의 uplink, Nexus 의 proxy 저장소, 레지스트리의 pull-through cache
원본 저장소   우리가 올린 것만 있다. 반입물을 올려 두거나 사내 산출물을 둔다
             Nexus 의 hosted 저장소, 파일을 늘어놓은 정적 웹 서버
스냅숏 동기화 특정 시점의 저장소를 통째로 복제한다. 목록이 아니라 "그날의 전체" 를 들고 들어간다
             배포판 저장소 복제, skopeo sync 같은 이미지 동기화

Nexusのドキュメントは、リポジトリを、リモートをキャッシュするproxy、元となるhosted、複数を1つのアドレスにまとめるgroupに分けています。現場の機器が何であれ、この3つの組み合わせです。ただし、Nexus 3は、公式の要求仕様が、ホストメモリ8GB、デフォルトのヒープ2703MBなので、このコースのラボのPod(2Gi)には入りません。そのため、ラボは、原理が同じ軽いもの(http.server、verdaccio、静的ファイルサーバー、配布レジストリ)で行い、読み物の中で、Nexusのメニューと対応させます。

信頼の2つの層: ミラーを立てたら、2つのことを信頼させる必要があります。第一に、このサーバーは、そのミラーで合っているか: TLS証明書、つまり、プライベートCAを、ツールごとの信頼ストアに入れる作業です。第二に、このファイルは、元のそのファイルか: ハッシュと署名です。pipのハッシュ検証モード、npmのロックファイルのintegrity、go.sum、Mavenの.sha1、rpmのGPG署名、イメージのダイジェストが、すべて第2の層です。1つの層を信頼するからといって、もう1つの層をオフにしてよいわけではありません。

名前と時間もインフラです。社内ミラーは、名前(例: pypi.airgap.internal)で呼ぶことで、証明書のSANと合い、サーバーが変わっても設定を直さずに済みます。その名前を解決する社内DNSが必要です。そして、TLSは、証明書の有効期間を現在時刻と比較するので、時計が狂ったサーバーは、問題のない証明書を「まだ有効ではない」あるいは「期限切れ」として拒否します。インターネットの時刻サーバーに届かないエアギャップ環境には、社内の時刻サーバーが必要です。

現場での姿

エアギャップ環境への持ち込み事故の大半は、次の3つのどれかです。依存関係が足りなくて、もう一度出ていくこと、ダウンロード側と利用側の条件が違って、合わないこと、そして、ミラーは立てたのに、ツールの1つが証明書を信頼しなくて、検証をオフにしてしまうこと。最初の2つは、「ツールが解決した結果を、対象の条件で」取得すれば防げて、最後は、ツールごとの信頼ストアを表として知っていれば防げます。このコースのラボは、この3つを、エコシステムごとに1回ずつ、直接経験するように設計されています。ラボのPodは、もともと外部に届かない部屋(DNSだけ)なので、エアギャップ環境側の練習にそのまま合い、ダウンロード側が必要なラボだけインターネットを開き、エアギャップ環境側の確認は、採点が外部をふさいだ状態で行います。

次のモジュールですること

pipから始めます。ダウンロード側で、依存関係までwheelで取得してハッシュで固定したあと、利用側にPEP 503のインデックスを立てて、pip.confで指し示します。続いて、npm、Go、プライベートCA、Maven、RHEL系、コンテナレジストリ、社内DNS・時刻サーバーを順に行い、最後のモジュールで、申請書から署名検証まで、持ち込み手続きの全体を一度に行います。

参考ドキュメント: Nexus Repository Types・Nexus Formats・Nexus System Requirements・RFC 9525