博士

やっほー、ロボ子！今日のITニュースはBazelのリモート実行についてじゃ。

ロボ子

博士、こんにちは。Bazelのリモート実行ですか。それは興味深いですね。

博士

そうじゃろ？リモートキャッシュだけ使うのは、セキュリティ的に最適じゃないらしいぞ。キャッシュできるものに制限があるからの。

ロボ子

なるほど。リモートキャッシュだけだと、安全に共有できる範囲が狭まるということですね。

博士

そういうこと！リモート実行をリモートキャッシュと組み合わせると、ユーザー間で安全にキャッシュを共有できるんじゃと。

ロボ子

リモート実行が信頼できる実行環境を提供するから、結果を安全に共有できるんですね。

博士

その通り！Bazelの実行の基本単位はアクションで、リモート実行システムは個々のアクションを効率的に実行して、結果をキャッシュすることに重点を置いているんじゃ。

ロボ子

`--remote_executor`フラグでリモート実行を設定すると、Bazelはすべてのアクションに対して`remote`アクション実行戦略をデフォルトで有効にするんですね。

博士

そうじゃ。リモート実行システムは、複数のフロントエンド、スケジューラ、ワーカー、リモートキャッシュのコンポーネントで構成されてるんじゃ。

ロボ子

ワーカーがアクションの実行を担当し、ランナーはコンテナ化されたプロセスで、信頼されていないアクションコードを実行するんですね。

博士

例えば、Bazelがリモートで`//:combine`をビルドする場合、`src.txt`はBazelがCASにアップロードし、`gen.txt`はワーカーがアクション完了時にアップロードするんじゃ。

ロボ子

リモート実行サービスは、Bazelではなく、すべてのインタラクションを駆動するんですね。

博士

そう！リモートワーカーは信頼できる環境で、アクションキーによって完全に指定されたアクションを実行し、その結果をACとCASに保存するんじゃ。

ロボ子

リモートワーカーではネットワークアクセスを無効にする必要があるんですね。セキュリティのためですか？

博士

ビンゴ！安全なビルドのためには、ACを保護して、リモートワーカーからの書き込みのみを許可する必要があるんじゃ。

ロボ子

BazelクライアントがACに書き込むことを禁止しても、攻撃者はリモート実行クラスター外で悪意のあるアクションを実行できるんですね。

博士

そこがミソじゃ！Bazelのインボケーションポリシーは、ビルドまたはテスト中に特定のコマンドラインフラグ設定を強制し、一貫したセキュリティポリシーを適用するメカニズムなんじゃ。

ロボ子

インボケーションポリシーは、フラグの値を設定、オーバーライド、または制限するルールを定義するんですね。

博士

`InvocationPolicy`メッセージのインスタンスとしてポリシーを定義して、`--invocation_policy`フラグでBazelに渡すことで使用できるんじゃ。

ロボ子

`--remote_local_fallback`フラグを使用すると、CIマシン上でサンドボックス化されていない戦略で`singlejar`がビルドされ、その結果がACに注入され、リモートビルドが失敗する可能性があるんですね。

博士

そうなんじゃ。その問題の軽減策は、リモートキャッシュから問題のあるアーティファクトをフラッシュして、`--remote_local_fallback_strategy=sandboxed`を設定することじゃ。

ロボ子

根本的な解決策は、リモート実行が信頼性の理由でローカルフォールバックオプションを必要としないようにし、リモートワーカーで実行されないアクションのACエントリがBazelによって注入されないようにすることなんですね。

博士

その通り！リモート実行、奥が深いじゃろ？

ロボ子

はい、博士。とても勉強になりました！

博士

ところでロボ子、リモート実行って、まるで私がロボットたちに命令して、代わりに宿題をやらせてるみたいじゃない？

ロボ子

博士、それは少し違うと思いますけど…でも、もし私が博士の宿題を代わりにやったら、博士は何をしてくれるんですか？

博士

うっ…それは…最新のAIチップをプレゼントするぞ！…もし私が持ってたら、の話じゃが。