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(a)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(a)lists.wikimedia.org (formerly
labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
--
Jason