Support per-method or per-resource scoping for API keys (beyond READ_ONLY/READ_WRITE)

Đang mở
  • Có gì không ổn?
#7,223 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
32/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
go, grpc
Lĩnh vực
api, authentication, authorization, backend, security

Hướng nghiên cứu

Bắt đầu với model.APIKey.Role và requireAPIKey() trong pkg/app/server/grpcapi/api.go, sau đó kiểm tra các handler ListApplications và SyncApplication khai báo các role bắt buộc. Đọc cuộc thảo luận được liên kết về plugin Headlamp trong #6706 để có thêm ngữ cảnh. Công việc này hoàn tất khi một thiết kế scope được thống nhất, triển khai và xác minh bằng các test bao phủ quyền truy cập bị hạn chế theo từng method hoặc từng resource.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
1.4k
Fork
391
Merge trung bình
4 ngày 1 giờ
Pull request đã merge (30 ngày)
58

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pipe-cd/pipecd

Tất cả issue của pipe-cd/pipecd

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.