GitHubがeBPFを活用してデプロイメントの安全性を向上させる方法

すべてのDNS呼び出しをユーザースペースDNSプロキシにリダイレクトしているため、各リクエストのトランザクションIDを確認し、解決中のドメインを特定し、eBPFマップを参照してどのプロセスがリクエストを行ったかを確認できます。/proc/{PID}/cmdlineを読み取ることで、リクエストをトリガーした完全なコマンドラインを抽出することさえ可能です。 その後、すべての情報を含むログ行を出力できます： > WARN DNS BLOCKED reason=FromDNSRequest blocked=true blockedAt=dns domain=github.com. pid=266767 cmd="curl github.com " firewallMethod=blocklist これで完了です。 これで次のことが可能になりました： * デプロイスクリプトから循環依存を引き起こすドメインを条件付きでブロックする。 * ブロックされたリクエストをトリガーしたコマンドを所有チームに通知する。 * デプロイ中に連絡されたすべてのドメインの監査リストを提供する。 * cGroupsを使用してデプロイスクリプトにCPUとメモリの制限を適用し、暴走するリソース使用がワークロードに影響を与えるのを防ぐ。 次は何ですか？ 新しい循環依存検出プロセスは、6か月のロールアウト後に本番環境で稼働しています。 現在、チームが誤って問題のある依存関係を追加した場合、または既存のバイナリツールが新しい依存関係を取得した場合、ツールはその問題を検出し、チームにフラグを立てます。 最終的な結果は、より安定したGitHubと、インシデント時の平均復旧時間の短縮です（これらの循環依存関係の削除による）。 循環依存関係がまだ問題を引き起こす可能性はありますか？ もちろんあります—そして、それらを発見したらツールを改善していきます。 深く掘り下げたいですか？ これで、eBPFで何ができるかについて興味が湧きましたか？ cilium/ebpfの例とdocs.ebpf.ioサイトの優れたドキュメントを見ることから始めてください。 独自のeBPFツールの作成を始める準備がまだできていない場合は、bpftrace（深いトレーシング用）やptcpdump（コンテナレベルのメタデータを含むTCPダンプ取得用）など、eBPFを利用したオープンソースツールを試してみてください。 この投稿「GitHubがeBPFを使用してデプロイの安全性を向上させる方法」は、The GitHub Blogで最初に公開されました。

GitHubがeBPFを活用してデプロイメントの安全性を向上させる方法

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト