Support per-method or per-resource scoping for API keys (beyond READ_ONLY/READ_WRITE)
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 32/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- go, grpc
調査の方向性
pkg/app/server/grpcapi/api.go の model.APIKey.Role と requireAPIKey() から始め、必要なロールを宣言している ListApplications と SyncApplication のハンドラーを調べます。背景については、#6706 にあるリンク先の Headlamp プラグインの議論を読んでください。メソッド単位またはリソース単位での制限されたアクセスを対象とするテストによって、スコープ設計が合意され、実装され、検証された時点で完了です。
索引モデルが issue の本文から書いたものです。
説明
This came up while discussing the Headlamp plugin proposal in #6706.
Right now model.APIKey.Role is a two-tier enum — READ_ONLY / READ_WRITE — set once per key at the project level. Enforcement happens per-RPC through requireAPIKey() in pkg/app/server/grpcapi/api.go, where each handler declares its own required role (e.g. ListApplications requires READ_ONLY, SyncApplication requires READ_WRITE). But there's no scoping within a role — a READ_WRITE key satisfies every READ_WRITE check unconditionally, across every RPC.
This becomes a real limitation for external integrations that only need one specific action. For example, if a Headlamp plugin (or any similar tool) just wants to call SyncApplication, the only option today is handing it a full READ_WRITE key — which also unlocks AddApplication, DeleteApplication, and everything else in that tier. There's no way to issue a key that can do less than "all of READ_WRITE."
Filing this mainly to track the idea rather than propose a full design. A couple of directions that seem reasonable on the surface:
- An allowlist of specific RPCs/methods attached to a key, checked alongside the existing role.
- Narrower sub-roles for common cases (e.g. a "sync-only" role) instead of a single blanket
READ_WRITE.
Happy to help implement this if there's interest — just wanted to get the problem written down first in case others have opinions on the right shape for it.
- 主要言語
- Go
- スター
- 1.4k
- フォーク
- 391
- 平均マージ
- 4日 1時間
- マージ済み PR（30日）
- 58
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pipe-cd/pipecd のほかの issue
-
Applications at the repository root are not triggered by new commits対応中かも @Daksha1611 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 2 日以内に返信
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTING対応中かも @Dhirenderchoudhary が今日担当しました。 オープン
難易度 2/5 半日 初心者へのやさしさ 74/100
pipe-cd/pipecd#7626 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 2 日以内に返信
-
pipectl transfer restore application drops backed-up labels対応中かも @bhavishyajain545 が 1 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
pipe-cd/pipecd#7622 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 2 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
docker-compose: postgres healthcheck should probe TCP (pg_isready -h localhost)対応中かも @zezo-mohamed22 が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
OneBusAway/watchdog#305 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
self-care self-care:agent-discoverability
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
githubnext/gh-cao#20928 ·
メンテナーはふだん 1 日以内に返信
-
automation documentation
難易度 1/5 1時間未満 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
SocialGouv/iterion#3287 ·
メンテナーはふだん 1 日以内に返信