エグレスポリシー

エグレスポリシーとは、システムがどの外向きのネットワーク接続を行えるかを、宛先（ドメインまたはIPレンジ）、プロトコル、ポートで定め、それ以外の通信をどう扱うかを決めるものです。エグレスフィルタリングは、ファイアウォール、プロキシ、ネットワークポリシーによってそのポリシーを適用することを指します。エグレスファイアウォールは、その適用を行う機器や機能です。

デフォルト許可とデフォルト拒否

デフォルト許可のポリシーは、既知の悪意ある宛先の一覧をブロックし、それ以外をすべて通します。デフォルト拒否のポリシーは、既知の正当な宛先の一覧を許可し、それ以外をブロックします。Kubernetesも同じ仕組みです。Podは、ネットワークポリシーによってエグレスの対象として選択されるまではどこにでも到達でき、選択された後はそのポリシーが許可する接続だけが可能になります（Kubernetesのネットワークポリシー）。

誰も想定していなかった宛先への通信を止められるのはデフォルト拒否だけであり、攻撃者のサーバーはまさにそうした宛先です。その代償は運用面にあります。許可リストを作成し、最新の状態に保つ必要があります。

Kubernetesでのデフォルト拒否のエグレスポリシー

Kubernetesのドキュメントでは、名前空間内のすべてのPodを選択し、外向きの通信を一切許可しない次のポリシーが紹介されています（Kubernetes network policies）。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

このポリシーはDNSもブロックするため、名前解決を行うワークロードには、クラスターのDNSサービスへの外向き通信を許可する2つ目のポリシーが必要です。許可する宛先は、Pod、名前空間、IP範囲（ipBlock）ごとに別のポリシーとして追加していきます。

FQDNベースのポリシー

標準のNetworkPolicyが対象にできるのはPod、名前空間、IP範囲で、ドメイン名は指定できません。パッケージレジストリはアドレスが変わるCDNの背後にあるため、その許可リストは名前で記述します。これが一部のネットワークプラグインが追加するFQDNベースのポリシーです。CiliumのtoFQDNsルールは、matchNameで完全一致の名前を、matchPatternでワイルドカードを指定し、DNSプロキシが見たDNS応答からアドレスを学習します（Cilium DNS-based policies）。Calico CloudとCalico Enterpriseでは、エグレスの許可ルールにdomainsを記述します（Calico DNS policy）。

CIにエグレスポリシーが必要な理由

ビルドジョブはデプロイキー、クラウドの認証情報、トークンを保持し、ダウンロードしたパッケージのインストールスクリプトを実行します。侵害された依存関係は、CIランナーが到達できるあらゆる場所へそれらのシークレットを送信できます。CIにおけるトークン窃取は、こうして起こります。ほとんどのランナーは、デフォルトですべての外向き通信を許可しています。

ジョブの環境変数を不明なホストに送信するnpmのpostinstallスクリプトを例にします。npmレジストリと自社のアーティファクトストアだけを許可するデフォルト拒否のポリシーがあれば、そのリクエストは失敗し、シークレットはジョブの中にとどまります。

ポリシーがブロックしたとき、ビルドには何が見えるか

接続が失敗し、ビルドは通常のネットワークエラーを報告します。ポリシーがどこで適用されるかによって、接続の拒否やリセット、タイムアウト、DNS解決の失敗、TLSハンドシェイクのエラーなどになり、パッケージマネージャーが再試行した後に表示されることもよくあります。開発者には不安定なレジストリのように見えるため、優れたエグレスポリシーはブロックした接続をすべて、宛先と理由とともに記録します。

確認すべきポイント

• 種類で指定できる宛先。 IPアドレスだけでなく、パッケージレジストリをソースとして名前で指定できること。レジストリはアドレスが変わるコンテンツデリバリーネットワークの背後にあるためです。
• ジョブ開始前の検証。 壊れたポリシーが中途半端に適用されるのではなく、目に見える形で失敗するようにします。
• フェイルクローズ。 適用ができない場合に、ジョブが保護なしで実行されないようにします。

GitHub Actionsでの導入方法は、GitHub Actionsのエグレスポリシーをご覧ください。

CRACI

CRACIはランナー上でエグレスポリシーを適用します。デフォルト拒否またはデフォルト許可を選べ、24種類の組み込みソフトウェアソースのプリセットと、npm、PyPI、apt、apk、Goプロキシ、Nix、Cargo、OCIレジストリ、HTTPSおよびSSH経由のGitに対応した種類指定のカスタムソースがあります。ポリシーはジョブ開始前に検証され、フェイルクローズで動作し、違反はアラートを発します。同じジョブで、許可された接続を通じてどのパッケージが取得されたかも記録されます。ランナーのセキュリティ比較をご覧ください。

CRACIのポリシーが接続をブロックすると、ジョブには403 Forbidden、接続のリセット、EOF、TLSハンドシェイクの失敗といった通常のエラーが表示されます。ジョブのネットワークトレースには、その接続がプロキシ違反として理由とともに一覧表示されます。たとえば、どのプリセット、ソース、ルールも宛先に一致しなかった場合はno_matchです。トレースはジョブの実行中にジョブ画面にリアルタイムで表示され、APIからも取得できます（CRACIドキュメント: ネットワークの問題をデバッグする）。

Kubernetesのワークロード、サーバー、引き続き使うGitHubホステッドランナーのエグレス制御には、ネットワークポリシー、クラウドファイアウォール、またはランナーエージェントを使ってください。CRACIがポリシーを適用するのは自社のランナーのみで、ブロック前の監査モードはロードマップに掲載されています。