プログラミング
UnYOLO: GitHubアカウント向けのAgent認証情報ブローカーおよびポリシーエンジン
UnYOLO: Agent credential broker and policy engine for your GitHub account (unyolo.io)
要約
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が拒否されることを確認します。