HN 日本語サマリー

← 一覧へ戻る
プログラミング

UnYOLO: GitHubアカウント向けのAgent認証情報ブローカーおよびポリシーエンジン

UnYOLO: Agent credential broker and policy engine for your GitHub account (unyolo.io)

5 pointsby hosolmaz0 コメント

要約

UnYOLOは、GitHubなどのサービスで利用するエージェントの認証情報を安全に管理するためのフレームワークです。エージェントは直接認証情報を持たず、ローカルのポリシーファイルに基づいて細粒度のアクセス制御が行われます。これにより、エージェントが誤ったコマンドを実行しても、アカウント全体への影響を防ぐことができます。必要に応じて、一時的な権限付与も可能です。

全文翻訳

コンテンツへスキップ エージェントと安全にYOLO unYOLOは、GitHub、Hugging Face、Google Workspaceなどのサービス向けの認証情報ブローカーおよびプロキシを構築するためのフレームワークです。エージェントはブローカーと通信し、実際の認証情報を保持することはありません。 unYOLOを使用すると、ローカルファイルに細粒度のポリシーを保持できます。エージェント用の権限画面をクリックしたり、別のアカウントを作成したりする必要はありません。エージェントがより多くの権限を必要とする場合は、自分で期限切れになる時間制限付きの付与を与えることができます。 開始する ソースを表示する YOU AGENT agent-a@workstation $ gh-broker operation submit pull_request.create op_9c2f succeeded pull request #482 opened $ gh-broker operation submit pull_request.merge op_1d55 pending policy requires operator approval op_1d55 approved by operator, single use op_1d55 succeeded pull request #482 merged ‹ u unYOLObot unYOLO Approval required agent-a wants to merge #482 in acme/api. Merging is not in this agent's policy. 09:41 Approve · 1 use Deny ✓ Approved by you 1x UnYOLOをインストールする macOSまたはLinuxでガイド付きインストーラーを実行します。 $ curl -fsSL https://unyolo.io/install.sh | sh コピー インストールオプション 認証情報の境界線 エージェントツールは、人が使用するのと同じアカウント全体のトークンを受け取ることがよくあります。誤ったコマンドは、そのトークンでカバーされているすべてのリポジトリと操作に到達する可能性があります。ブローカーは、プロバイダーのトークンを別のプロセスに保持します。エージェントは、ポリシーから権限を得るクライアント認証情報を受け取るため、不正なforce-pushはGitHubがそれを認識する前に失敗します。 ブローカーなし トークンをエージェントに渡します。エージェントはあなたが望んだ作業を行い、同じトークンがあなたのアカウント内の他のすべてにも到達します。 GitHubトークンをエージェントに渡します。エージェントはあなたが望んだブランチをプッシュし、同じトークンがデフォルトブランチ、acme/apiリポジトリ自体、および別のプライベートリポジトリにも到達します。 token YOU AGENT agent-a/parser-fix branch main default branch acme/api repository acme/secrets private repo UnYOLOを使用した場合 ブローカーがトークンを保持します。エージェントは同じ作業を要求し、許可されていない呼び出しは拒否されます。 GitHubトークンをブローカーに渡します。エージェントはブローカーにリクエストを送信し、ブローカーはそれをscope.jsonに対してチェックし、同じブランチプッシュを許可して結果を返し、他の3つは拒否します。 token request result scope.json YOU AGENT BROKER agent-a/parser-fix branch main default branch acme/api repository acme/secrets private repo リクエストパス すべてのブローカーは同じリクエストパスを使用します。分類と実行のみがプロバイダーに依存します。 1 クライアント認証 呼び出し元は、ブローカーがリクエストを受け入れる前に、名前付きブローカークライアントシークレットを提示します。 2 リクエストの分類 プロバイダーアダプターは、クライアントと操作をターゲット属性とともに識別します。 3 ポリシー評価 共有エンジンがそのタプルをルールファイルと照合します。 4 アクティブな付与 承認された付与は、有効期限と使用回数制限を持つ許可ルールとして機能します。 5 承認リクエスト リクエスト可能な操作は、オペレーターの受信トレイに表示され、Telegramにも表示される場合があります。 6 プロバイダーの実行 ブローカーは、プロバイダーの認証情報を使用して操作を実行し、結果のみを返します。 7 監査エントリ ブローカーは、シークレットを含めずに、決定と一致するルールIDを記録します。 決定順序、ルールの順序に関係なく固定 denydeny › active grant › allow › request › no_match Denyはすべてに優先し、承認された付与や、どのルールにも一致しないリクエストも拒否されます。 ポリシーエンジンのドキュメントを読む ポリシーファイル ブローカーは、起動時に1つのJSONルールファイルを承認ソースとしてロードします。直接読み取り、プルリクエストで変更を確認できます。UnYOLOはトラフィックから権限を推測しません。属性は有用な絞り込みを提供します。このテキストの隣のルールは、refs/heads/agent-a/**へのプッシュを許可します。refs/heads/mainはカバーされていないため、デフォルトブランチへのプッシュは拒否されます。不明なフィールド、重複したルールID、サポートされていない操作、無効なグロブは、サービスの起動を妨げます。 フルポリシー スキーマ allow { "rules": [ { "id": "agent-a-read-and-branch", "effect": "allow", "clients": ["agent-a"], "operations": [ "contents.read", "git.fetch", "git.push.fast_forward" ], "targets": [ { "kind": "repo", "owner": "acme", "name": "api" } ], "attrs": { "refs": ["refs/heads/agent-a/**"] } } ] } request { "rules": [ { "id": "request-force-push-to-main", "effect": "request", "clients": ["agent-a"], "operations": ["git.push.force"], "targets": [ { "kind": "repo", "owner": "acme", "name": "api" } ], "attrs": { "refs": ["refs/heads/main"] }, "grant_policy": { "mode": "window", "default_minutes": 5, "max_minutes": 10, "default_max_uses": 1, "max_uses": 1 } } ] } denydeny { "rules": [ { "id": "never-delete-refs", "effect": "deny", "clients": ["*"], "operations": ["git.ref.delete"], "targets": [{ "kind": "repo" }], "description": "Deletion is never delegated, even under an approved grant." } ] } オペレーターの承認 操作リクエストをマークすると、永続的な承認レコードが作成され、元の呼び出しが開いたままになります。承認されると、git pushは同じプッシュとして再開されます。拒否、有効期限切れ、またはアップストリーム状態の変更は、通常のGitエラーを返し、何も転送しません。オペレーターは、別のリスナー上の保護された受信トレイで、独自の認証情報を使用して決定します。Telegramも同じ承認レコードを表示できます。どちらのインターフェイスもリクエストを一度だけクローズし、承認は期間または使用回数を狭めることしかできません。 承認がどのように機能するか operator@host $ curl -sS --unix-socket "$OPERATOR_SOCK" \ -H "Authorization: Bearer $OPERATOR_TOKEN" \ localhost/api/operator/v1/requests?status=pending { "items": [ { "id": "g_01JQ8W3M", "revision": 3, "requester": "agent-a", "operation": "git.push.force", "presentation": { "title": "Rewrite history on acme/api", "risk": "high", "warnings": ["Removes 2 commits from main"] } } ] } # Approve, narrowing the window to two minutes. $ curl -sS -X POST .../g_01JQ8W3M/approve -d '{ "expected_revision": 3, "constraints": {"duration_seconds": 120} }' 200 state=active uses_remaining=1 含まれるブローカー リポジトリには、GitHubおよびHugging Faceブローカーが含まれています。sudo-brokerは承認されたUnixコマンドを処理します。それぞれが別々のプロセスとして実行され、他のプロバイダーの認証情報にアクセスできません。 gh-broker GitHub Appの認証情報を保持します。リポジトリスコープのリクエストの場合、そのリポジトリと操作に必要な最小限の権限に絞られた、短命のインストールトークンを発行します。 pull_request.create git.push.fast_forward contents.read ドキュメント hf-broker HubリポジトリおよびRouter推論用のHugging Faceトークンを保持します。GitおよびLFSプッシュを転送する前に解析するため、履歴のリライトはブローカーで停止します。 git.push.append repo.contents.read bucket.object.write ドキュメント sudo-broker ルート所有のカタログから別のUnixユーザーとして1つの正確なコマンドを実行します。シェル文字列や任意の実行可能ファイル、TTY、または呼び出し元が提供する環境を拒否します。 exec.command ドキュメント カスタムブローカー 組み込みのブローカーは、カスタムプロバイダーも利用できるのと同じフレームワークを使用します。内部APIキーまたはクラウドロールを保護するには、プロバイダー固有の分類子と実行者を実装します。共有パッケージは、ポリシーと承認の仕組みを提供します。アーキテクチャチェックは、プロバイダーをインポートする共有コードを拒否します。 あなたは書く クライアントと操作をターゲット属性とともに識別する分類子 操作とそのターゲットの種類、および受け入れられる属性を宣言するレジストリ 認証情報を保持し、アクションを実行する実行者 タイトル、リスクファクト、警告を含む制限付き承認の言葉遣い あなたは継承する 別々の認証情報でのクライアントとオペレーターの認証 ポリシーエンジンとその固定された決定順序 使用回数制限、予約、冪等なリトライを備えたグラントライフサイクル オペレーターの受信トレイ、SSEカーソル、Telegramチャネル Agent Operations V1、そのMCPブリッジ、および再起動リカバリ シークレットセーフ監査、インストーラー、サービスレンダリング、およびドクターチェック フレームワークの概要を読む GitHubクイックスタート リポジトリに対してgh-brokerを実行し、許可されたブランチをプッシュし、メインへのforce-pushが拒否されることを確認します。