Hi there,

I was wondering if you were planning on exposing some kind of rate-limiting option for the web proxies in horizon? I'm thinking this will effectively mean no more rate-limiting per remote address at the instance level. Every once in a while, our project gets hammered by script kiddies and our application service gets brought down. I've gone ahead and implemented rate limiting in nginx that has a very high limit set across all ip addresses that should basically work, but typically I would set the limits to be per-client-ip to the extent allowed by the practicalities of NAT. This is not a blocker in any way for us, and I'd rather make do with less user info wherever possible.

Thanks for making the development of tools and services for Wikimedia as painless as possible!

On Wed, Apr 1, 2020 at 8:31 AM Arturo Borrero Gonzalez <aborrero@wikimedia.org> wrote:

Hi there!

If you use a CloudVPS web proxy, this email is for you. Toolforge
developers/users can ignore this email.

We are introducing a change to eliminate the 'X-Forwarded-For' HTTP header that
the CloudVPS web proxy adds when forwarding the HTTP request to your instance.
This header contains the original IP address of the internet client that sent
the request. This is private information that we would like to reduce in our
environment [0].

You use the web proxy if you have a public web endpoint hosted in CloudVPS under
the wmflabs.org domain. These are generally configured using Horizon in the DNS
> Web Proxies section.

Examples of web proxy names:
* accounts.wmflabs.org
* glampipe.wmflabs.org
* incubator.wmflabs.org

Full list can be seen in the Openstack Browser tool [1].

We are ready to introduce this change [2], but wanted to give some heads up for
projects that do require this information for whatever reason. We would like to
hear from you in the next couple of weeks. Please contact us in the phabricator
task [0] and include some rationale why you need the XFF header.

This is the timeline this change will follow:

* 2020-04-01: this email, start collecting list of things that require XFF
* 2020-04-07: start evaluating list of things that require XFF
* 2020-04-15: introduce the change, with proper case whitelisting

When the change is introduced, in two weeks from now, proxy backends that were
not whitelisted will stop receiving the XFF header.

Please reach out for any questions or comments.

regards.

[0] https://phabricator.wikimedia.org/T135046
[1] https://openstack-browser.toolforge.org/project/project-proxy
[2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/583098

--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation

_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce@lists.wikimedia.org (formerly labs-announce@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce