I'm currently working on a project where I want to apply rate limiting at the load balancer level to each user's IP address. The idea is to throttle any user that crosses a certain request limit in a given unit of time.
Note: I am using Google Cloud Armor.
The architecture involves a CDN in front of the load balancer. As I understand it, when using a CDN, the IP address that my load balancer sees for incoming requests is the CDN's IP, not the original client's IP.
I've already tried using XFF_IP for rate limiting and it seems to be working as expected. However, I'm not sure how to safeguard against potential spoofing of the XFF header. Any insights or recommendations would be appreciated.
I read Pulumi's documentation to gain understanding of the different keys I can enforce. XFF_IP is known to be faulty.
What measures can I take to prevent spoofing of the XFF header and ensure accurate rate limiting?
By default, Cloud Armor uses the connecting IP address in its IP inspection which isn't something that can be easily spoofed like a header value. The problem, as you correctly point out, is if the upstream services is a CDN. Many 3rd party CDNs will allow you to place the true client IP address within a separate header other than the XFF header value.
A new feature was recently released that allows you to inform Cloud Armor to use an alternate header for client IP inspection. It is currently only available in the beta channel of the CLI User-IP-Request-Header. This doesn't directly address the spoofing concern, but if you have a trusted upstream provider from Cloud Armor, it is a potential option to explore under the assumption if you have the client IP address placed in a "different" header value, Cloud Armor will use that value over the connecting IP value. Conceivably, it would be harder to spoof as it is effectively a header shared between the 3rd party upstream CDN and Cloud Armor.