Per-user rate limiting on api-server REST endpoints

[1fanwang]

Description

The REST API on api-server is unbounded by default. A single user / service account making rapid calls (a CLI in a tight loop, misconfigured automation, a busy DAG generator) can exhaust request capacity and degrade access for the rest of a multi-tenant deployment. There's no built-in mechanism to cap per-user request rate.

For login throttling there's PR #58293 (closed) and the FAB rate-limiter for the legacy webserver — but those are about brute-force auth-page protection, not general API quota.

Use case / motivation

Multi-tenant Airflow deployments. One noisy tenant should not be able to DoS the api-server for everyone else. Today the workarounds are:

• (a) Put a rate-limiter (envoy/nginx) in front of api-server and tag by user — but the username isn't always available at the proxy layer for token-auth flows.
• (b) Cap concurrent gunicorn workers — but that caps total throughput, not per-user.

Neither is satisfying.

Proposal

Per-user rate-limiting middleware on api-server. Sketch:

• Keyed by authenticated principal (username from JWT / session / API token).
• Separate buckets for high-traffic endpoints (/api/v2/monitor/health, /api/v2/version) vs general API.
• Service-account principals get a higher (configurable) limit.
• Backend: in-memory by default; redis if configured (matches how the FAB rate-limiter is set up).
• Config: per-endpoint or per-route-prefix limits in airflow.cfg.

This is substantive enough that I'd prefer to discuss the shape on the mailing list before PR. Filing the issue so the discussion has a permanent home.

Are you willing to submit a PR?

• Yes, after design feedback

Code of Conduct

• I agree to follow this project's Code of Conduct

[potiuk]

I don't think we should do it in Airflow, to be honest. Usually things like that are done on all kinds of api gateways that you put in front of whatever app you have - and I see no particular reason Airflow will do better job than those gaeways.

[potiuk]

It goes totally opposite the way we've done with Auth - whenever there is something generic, that is not serving the "core" of airflow functionality, we should think how to move it out, not to bring it in.

I think that one is hard no for me if it comes to code changes.

And if you think this is a problem:

(a) Put a rate-limiter (envoy/nginx) in front of api-server and tag by user — but the username isn't always available at the proxy layer for token-auth flows.

We should rather think of a way how to expose the necesary missing things for the gateways rather than bringing in the whole functionalities they offer (Headers and cookies are the right ways to think about it I think).