Rate-limit expensive RPCs to prevent resource exhaustion
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- api, backend-api-design, security
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Rust
- Stelle
- 551
- Fork
- 97
- Merge medio
- 1g 8h
- PR unite (30g)
- 182
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Dstack-TEE/dstack
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Dstack-TEE/dstack#1384 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
Dstack-TEE/dstack#1301 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Dstack-TEE/dstack#1300 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Dstack-TEE/dstack#1299 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Dstack-TEE/dstack#1298 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Dstack-TEE/dstack
Issue simili
-
area:casework bug criticality:p3 triage:needs-implementation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
registrystack/registry-stack#1623 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DioxusLabs/anyrender#98 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
leptos-rs/leptos#4885 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
longbridge/gpui-kit#3276 ·
I maintainer di solito rispondono entro 1 giorno