
LeitWacht Agent v0.9.0
eBPF + nftables + DNS proxy による GitLab Runner CI/CD ジョブコンテナのエグレス制御 — community edition data plane https://leitwacht.eu/
leitwacht-agent
https://leitwacht.eu — 正規のソース: https://gitlab.com/leitwacht/leitwacht-agent. Issue、MR、議論はGitLab上で行われます。
Pre-1.0. 0.x シリーズはプレリリース安定版です。マイナーリリースでは、1.0 が出るまで API、環境変数名、Helm
values.yamlのキー、ルールファイルのスキーマに破壊的変更が加えられる可能性があります。本番環境ではイメージダイジェスト(フローティングタグ不可)を固定してください。アップグレード時の注意点は CHANGELOG.md を参照してください。
leitwacht GitLab Runner の出口制御システム用データプレーンエージェントです。eBPF + nftables + ネットワーク名前空間内DNSプロキシが各CIランナーコンテナにアタッチし、出口ポリシーを適用します。CE(このリポジトリ)はローカルのYAMLファイルからルールを読み込み、完全にスタンドアロンで動作します(バックエンド不要、外部への通信不要、登録不要)。
別途ライセンスされたEnterprise Edition
(gitlab.com/leitwacht/leitwacht)
では、管理されたコントロールプレーン(ルール作成UI、マルチテナンシー、監査、GitLab統合)が追加されます。EEエージェントはこのリポジトリから agentcore/ をインポートし、YAMLローダーをgRPCルールストリームに置き換えます。
構成
agentcore/ データプレーン基本機能 (MPL-2.0)
enforcer/ eBPF + nftables + DNSプロキシ + LSM cred/proc_mem
watcher/ コンテナライフサイクルイベントソース (containerd, docker)
handler/ ライフサイクルハンドラ — エディションに依存しない
policy/ ResolvedPolicy + Sourceインターフェース + ローダー
advisory/ プレーンGoのアドバイザリ型 + Sinkインターフェース
violation/ プレーンGoの違反報告Sinkインターフェース
wildcard/ ドメインパターンマッチングヘルパー
version/ ビルドバージョンスタンプ(-ldflagsで設定)
cmd/
leitwacht-initc/ ポッド初期化コンテナ(エージェントアタッチまでエントリポイントをブロック)
ce/ Community Edition デーモン (MPL-2.0)
cmd/agent-ce/ バイナリ
config/ 環境変数駆動のデーモン設定
ruleyaml/ YAMLルールローダー + fsnotifyによるホットリロード
sinks/ stdout NDJSON / Prometheus / webhook
helm/agent-ce/ Helmチャート
SCHEMA.md YAMLルールスキーマ (v1)
examples/
rules.yaml スタータールールセット
docs/
EVENT_FLOW.md watcher → handler → enforcer のフローとチューニング可能パラメータ(mermaid使用)
コンテナスコープ
leitwacht-agent は、GitLab Runner 管理ラベル com.gitlab.gitlab-runner.managed=true を持つコンテナのみを検査します。このラベルがないコンテナ(手動で起動したもの、サイドカー、アプリケーションのワークロード)は完全に無視されます(イベントなし、適用なし、違反なし)。これは意図的なものです:leitwacht は CI ランナーの出口用データプレーンであり、ランナー以外のワークロードを黙ってインターセプトすべきではありません。ランナー以外のユースケースは v0.1.0 の対象外です。
既知の制限 (v0.1.0)
- IPv4 のみ。 eBPF プログラムと DNS プロキシは IPv4 トラフィックに適用されます。IPv6 の出口はポリシーに関係なくネット名前空間の境界でドロップされます。IPv6 接続を必要とする CI ジョブは、この問題が解決されるまで leitwacht の適用を使用できません。
- Linux x86_64 のみ。 arm64 ランナーはまだサポートされていません(CI では amd64 イメージを出荷しています。arm64 はそのアーキテクチャ用の eBPF アーティファクトが準備でき次第フォローします)。
- GitLab Runner ワークロードのみ。 上記「コンテナスコープ」を参照してください。
クイックスタート
# ビルド(CGO_ENABLED=0 により非Linuxホストでもクリーンにクロスコンパイル可能)
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build ./...
# コンテナイメージ
docker build -f Dockerfile.agent-ce -t leitwacht/agent-ce:dev .
# Helm インストール(Kubernetes)。dnsUpstream は必須です — パブリックなものではなく、クラスタのDNSリゾルバを指定してください。
# これにより内部サービスが解決され続け、クエリが漏洩しません。
KUBE_DNS_IP=$(kubectl -n kube-system get svc kube-dns -o jsonpath='{.spec.clusterIP}')
helm install leitwacht-ce ./ce/helm/agent-ce \
-n leitwacht --create-namespace \
--set-file rules=examples/rules.yaml \
--set "dnsUpstream=${KUBE_DNS_IP}:53"
rules.yaml の完全なスキーマリファレンスは ce/SCHEMA.md にあります。
ライセンス
agentcore/ および ce/ は Mozilla Public License 2.0 の下で配布されています — LICENSE を参照してください。MPL-2.0 はファイルレベルのコピーレフトライセンスです:これらのファイルを自身の製品(商用・非商用を問わず)で使用、修正、再配布することができますが、MPL-2.0 でライセンスされたファイルに加えた変更は、同じライセンスの下で利用可能にしなければなりません。
gitlab.com/leitwacht/leitwacht にある Enterprise Edition バックエンドは、別のライセンスで配布されています。2つのリポジトリは同じチームによって共同開発されています。
コントリビューション
問題やマージリクエストは公式の GitLab リポジトリ (https://gitlab.com/leitwacht/leitwacht-agent) にお願いします。セキュリティ問題は SECURITY.md のプロセスに従ってください。ワークフローとスタイルに関する注意事項は CONTRIBUTING.md にあります。
ビルド
Linux のみ(eBPF + nftables): GOOS=linux GOARCH=amd64 go build ./...
eBPF オブジェクト(*_bpfel.o)はコミットされています。再生成には clang とカーネルヘッダーが必要であり、CI ビルドはコミットされたアーティファクトに依存するためです。Linux 上でローカルに再生成するには:
go generate ./agentcore/enforcer/