Add per-identity proxied-data rate limit#8
Open
kesavn-13 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a simple per-identity data limit for traffic proxied through the gateway. The limiter is keyed by the same source identity already used by the gateway policy path, so the limit is attached to the agent identity rather than something weaker like IP address.
Why I chose this design
I treated the gateway as the right place for this feature because it is already the enforcement point. It sees the mTLS identity, checks policy, and then moves the actual proxied bytes. The dashboard and demo repos are useful for visibility and local setup, but the data-limit decision belongs in the gateway itself.
I kept the first version intentionally small: an in-memory fixed-window byte counter per identity. My current SPAR work is around secure infrastructure and local/offline agent workflows, and one thing I have been learning there is that security controls are easier to trust when they are small, auditable, and placed at clear boundaries. For this task, I preferred a simple local limiter over adding another dependency or service too early.
Implementation
Added
src/rate_limit.rs.Added optional
[rate_limit]config.Wired a shared
RateLimiterintoMakeProxyService.Replaced the tunnel copy path with a small bidirectional copy loop that counts proxied bytes.
Updated integration test setup to pass a disabled limiter so existing tests keep their previous behavior.
The limiter counts traffic in both directions. If an identity exceeds its configured byte budget during the current window, the gateway closes the tunnel and logs the rate-limit event.
Testing
Ran: