セキュリティアーキテクチャ

LatchkeyがすべてのCIジョブをどのように隔離するか: 専用の使い捨て仮想マシン、インバウンドネットワークなし、エフェメラルな認証情報、保存時および転送中の暗号化、そしてセルフヒーリングエージェントが動作する際の制約。

このページはセキュリティレビュー向けに書かれています。ランナープラットフォームが実際にどのように構築されているか、つまり隔離境界、マシンから外部に出るもの、認証情報の取り扱い方、そしてセルフヒーリングエージェントに許可されていること・いないことを説明します。GitHub Appがあなたのリポジトリで読み取り・書き込みできる内容については、セキュリティとGitHubの権限を参照してください。

隔離: 1ジョブ、1マシン#

Latchkeyはジョブ間でマシンを共有しません。各ジョブは、そのジョブのために起動された専用のEC2仮想マシン(m6aクラス、Ubuntu 24.04 LTS)上で実行されます。あなたのジョブは、他のテナントとカーネルを共有するコンテナではなく、長期稼働する共有ホスト上のプロセスでもありません。

単一使用は慣習によってではなく、GitHubの登録レイヤーで強制されます。コールドスタートのランナーはジャストインタイム構成で登録され、GitHubはこれを正確に1つのジョブに対してのみ受け入れます。ウォームプールのランナーは --ephemeral フラグで登録され、同じ動作になります。いずれの場合も、インスタンスはシャットダウン時に終了するよう構成されているため、何らかの問題が発生しても再利用されることはありません。

ランナーグループは visibility: selected と明示的なリポジトリリストで作成されるため、あなたのworkspace向けに登録されたランナーには、有効化したリポジトリのジョブのみが割り当てられます。

何がrootとして動作し、なぜそれが封じ込められているのか#

自身のVM内では、あなたのジョブは完全な制御権を持ちます: runner ユーザーはパスワードなしのsudoとDockerアクセスを持ちます。これはCIとしては通常のことであり(ビルドはパッケージをインストールし、コンテナを実行します)、そして安全である理由はまさに、影響範囲がインバウンドネットワークを持たず、ジョブの終了時に破棄される短命なマシン1台に限られているからです。存在しないサンドボックスをほのめかすよりも、これを率直に述べることを選びます。

ネットワーク#

認証情報とシークレット#

デプロイはGitHub OIDCによるロール引き受けでAWSに認証します。CIに長期間有効なAWSアクセスキーは存在しません。MCP連携用のAPIキーはSHA-256ハッシュとしてのみ保存され、平文のキーは作成時に一度だけ表示され、永続化されることはありません。

暗号化#

ビルドキャッシュの隔離#

キャッシュオブジェクトは、あなたの組織IDから導出されたキープレフィックスの下にS3へ保存され、テナントIDはジョブリクエストからコントロールプレーンによって注入されます: ジョブが環境変数を設定して別のテナントを名乗ることはできません。オブジェクトは14日後に失効します。

ランナーから外部に出るもの#

2種類のデータがマシンから外部に出ます。2つ目については正確に述べる価値があります。

• 実行およびジョブのメタデータ: 名前、タイミング、ステータス、ラベル、そしてワークフローYAML。これらが分析機能と最適化機能を支えます。
• 失敗したステップの出力。 ステップが失敗すると、セルフヒーリングのパイプラインがそのステップの標準出力と標準エラー(それぞれ最大1 MiB)を取得して保存し、失敗の診断と、必要に応じた修正案の作成に使用できるようにします。保持期間は90日です。

セルフヒーリングエージェントに課された制約#

セルフヒーリングは、実行中のジョブを変更する唯一のコンポーネントであるため、レビュアーが最も強く精査すべき部分です。ここでは、それが何をできるのかを正確に説明します。

• systemdサービスとして、rootではなく runner ユーザーで動作します。
• グループに制限されたパーミッションを持つUnixドメインソケットでリッスンします。TCPリスナーもネットワーク面の攻撃対象もありません。
• ランナーエージェント自身のステップスクリプトのみを横取りするシムを介して呼び出されます。それ以外のコマンドはすべて、手を加えられずにそのまま通過します。
• フェイルオープンします: エージェントがタイムアウト、拒否、またはエラーになった場合、コマンドはLatchkeyがない場合とまったく同じように実行されます。壊れたヒーラーがあなたのビルドを壊すことはできません。

実行できる特権操作はフィルタリングではなく、許可リスト方式です:

GitHub Appがアクセスできるもの#

以下のすべての権限は、特定の機能を支えるために存在します。付与の理由がすぐ隣で分かるよう、フラットなリストではなく用途ごとにグループ化しています。

リポジトリへの変更#

Latchkeyがデフォルトブランチにプッシュすることは決してありません。すべての変更はあなたがレビューするプルリクエストであり、書き込み経路は3つの方法でゲートされています:

1. ファイルパスは、リポジトリごとのマニフェストに照らして編集可能と解決される必要があります。一致しないパスはデフォルトで編集不可となります: このチェックはフェイルクローズです。
2. フォークを起点とするプルリクエストは拒否されます。また、フォークかどうかのシグナルが欠落している場合も、安全であると仮定せずに拒否されます。
3. 提案された修正は、取得済みのログ内の失敗シグネチャと一致する必要があり、一致しない場合は抑制されます。

運用上のセキュリティ#

• ランナーイメージは毎週再ビルドされるため、OSのセキュリティパッチが計画的にフリートへ適用されます。
• ランナーのインスタンスロールは最小権限であり、AWSマネージドポリシーのアカウント全体にわたるParameter Storeへのアクセスを、Latchkey自身のランナーパスに絞り込む明示的な拒否を含みます。
• 変更を伴うすべての管理操作は、操作者、アクション、対象、パラメーター、結果とともに監査ログに記録されます。
• ダッシュボードとAPIへのアクセスは、APIゲートウェイのJWTオーソライザーによって認証されます。workspaceのロールはOwner、Admin、Memberであり、オーナーは削除や降格から保護されています。

データの保持#

Latchkeyが保存するものと、その保持期間です。

リポジトリを無効化すると、そのリポジトリの収集が停止します。workspaceを削除すると、そのデータが削除されます。組織として特定の保持期間が必要な場合は、お問い合わせいただければご相談に応じます。

脆弱性の報告#

security@latchkey.dev までメールでご連絡ください。セキュリティ報告のためにパブリックなGitHub issueを作成しないでください。