search

nats-io / nats-server

High-Performance server for NATS.io, the cloud and edge native messaging system.
https://nats.io
Apache License 2.0
15.82k stars 1.4k forks source link

Rate-limit for publishing messages #4891

Open AbstractiveNord opened 10 months ago

AbstractiveNord commented 10 months ago

Proposed change

Option per publisher, which can block or even cause a disconnection for user, spamming into NATS network.

Use case

Every time when NATS publisher is not 100% trusted entity.

Contribution

Yes.

derekcollison commented 10 months ago

So this is not about sending to other subjects, which we can lock down, but for valid subjects just to rate limit yes?

AbstractiveNord commented 10 months ago

So this is not about sending to other subjects, which we can lock down, but for valid subjects just to rate limit yes?

Yes. Even for allowed subjects, if we have NATS connection on client side, for example, in JS code on web page, we cannot protect the NATS network by blocking spam. This is the problem, which causes irrelevant backend, doing nothing more than just rate-limiting and proxy client HTTP requests into NATS requests.

AbstractiveNord commented 10 months ago

It's probably good idea to have a bunch of distributed clustered NATS Jetstream KV buckets with TTL configured, used by Core NATS for rate-limit users. Core NATS acts like sticky proxy, so by implementing this approach, it's possible to have sync hot cache on Core NATS proxies, updates through NATS KV watch subscription. Welcome to discuss, just first idea.

derekcollison commented 10 months ago

Not following that last comment.

The server code base does have a rate limiter, currently only in use as an opt-in for JetStream consumers.

That could be utilized possibly.

tjad commented 7 months ago

I think 1 consideration for this topic is about whether or not a managed cluster of NATS is in use.

I have seen in another thread the consideration using TC https://github.com/nats-io/nats-server/issues/346#issuecomment-252067566 . This does sound plausible if the solution is self-managed, then using the TC sounds like a viable option at a more ideal level. My concern comes in for managed clusters. It should probably be the onus of the cluster provider to allow such functionality/feature, however this can't be guaranteed as a feature between providers.

Also, TC is rate limiting at the bandwidth level, it may be more convenient to rate limit at a per message level - this would alleviate requirement to understand and do calculations around the message size.

Just food for thought.

dragonballa commented 5 months ago

Not following that last comment.

The server code base does have a rate limiter, currently only in use as an opt-in for JetStream consumers.

That could be utilized possibly.

I'm facing this exact situation where we don't know if the publisher is trustable or not. Can easily spam/DDOS

I'm looking for a solution I can use NOW

Is KV the way to go? Not sure what that rate limiter code you speak of looks like (or know where it is).

derekcollison commented 5 months ago

Nothing to limit the inbound rate outside of network throughput and max payload size at the moment.