Rate-limit expensive RPCs to prevent resource exhaustion
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
- 35/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ệ
- rust
- Lĩnh vực
- api, backend-api-design, security
Hướng nghiên cứu
Start by tracing the named RPC entry points: KMS key issuance/SignCert, Gateway RegisterCvm, and Verify. Define how anonymous, authenticated, shared-resource, and replica-spread requests should be limited, then validate floods and expensive invalid requests against early rejection, service preservation, retry guidance, bounded state, and exposed counters.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
Repeated calls to expensive RPCs—such as KMS key issuance / SignCert, Gateway RegisterCvm, and Verify—can exhaust CPU, disk, subprocess, or external-service resources and degrade service for other users.
Abuse can come from unauthenticated callers, invalid requests that are expensive to reject, or authenticated clients making otherwise valid requests. Authentication and concurrency limits alone do not bound sustained resource consumption.
Proposed direction
Introduce low-overhead, server-side rate limiting for expensive RPC paths:
- Configurable token buckets with sustained-rate and burst limits.
- A coarse limit before expensive authentication, attestation verification, or request processing.
- Additional per-client limits using verified instance/app identity where available. For anonymous callers, define an appropriate source-based policy; never trust arbitrary identity headers.
- Shared service/resource budgets to contain aggregate load, including requests spread across identities or endpoints.
- Reject excess requests early with a distinguishable rate-limit error and retry guidance.
- Bound limiter state and cleanup cost. Start process-local and document how limits behave across replicas.
Limits should accommodate normal boot, registration refresh, and certificate renewal bursts.
Validation
Test floods from anonymous callers, expensive invalid requests, and authenticated clients. Verify that limits bound accepted request rates, reject excess work early, and preserve service for unrelated clients. Expose rate-limit counters for tuning.
Related: #1258, #1259. Separate from concurrency/admission control in #1096.
- Ngôn ngữ chính
- Rust
- Star
- 546
- Fork
- 96
- Merge trung bình
- 19 giờ 22 phút
- Pull request đã merge (30 ngày)
- 109
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Dstack-TEE/dstack
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
Dstack-TEE/dstack#1301 ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Dstack-TEE/dstack#1300 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Dstack-TEE/dstack#1299 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
Dstack-TEE/dstack#1298 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Dstack-TEE/dstack#1297 ·
Tất cả issue của Dstack-TEE/dstack
Issue tương tự
-
risk:low runtime status:in-progress type:test
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
zeroclaw-labs/zeroclaw#11023 ·
-
good first issue refactor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
bevyengine/bevy#25861 ·