Page MenuHomePhabricator

Build authenticating reverse proxy for Cloud CirrusSearch replicas
Open, NormalPublic

Description

Experience has shown that Toolforge/Cloud VPS customers can and will accidentally overload shared resources by creating buggy or overenthusiastic client applications. To provide some ability to maintain service for the majority of users in the face of this reality it is important to have some form of access control that can be used to block badly behaving clients until their operators can fix them.

In the case of the Wiki Replicas and Toolforge Kubernetes clusters, built in mechanism for authentication are used with credentials that are managed by custom services (maintain-dbusers & maintain-kubeusers). Both custom services work in largely the same way:

  1. get a list of all eligible user via LDAP queries
  2. for each user check for existing credentials
  3. if none found then:
    1. generate new credentials
    2. store new credentials in application's native authn system
    3. persist new credentials to file system for client use

It seems reasonable that the authenticating reverse proxy can work the same way for provisioning credentials, but we do not have an existing authn system for ultimate storage and use, so we need to find or build such a system. It will need to be able to:

  • check some value provided in the request against the credential store
  • store valid credentials via some out-of-band management method
  • disable a user's access via some out-of-band management method
  • enable a user's access via some out-of-band management method

Event Timeline

bd808 triaged this task as Normal priority.Apr 4 2019, 5:41 AM
bd808 created this task.
bd808 added a comment.Apr 4 2019, 5:48 AM

One option would be to implement something like:

  • simple flask webservice to manage credential store (CRUD actions)
  • credentials stored in some durable method (sqlite, mysql, flatfile) and mirrored to redis
  • reverse proxy uses HTTP Basic auth + lua + redis to authenticate users
  • cli client to disable/enable a particular set of credentials
  • cli client to reset redis cache from durable storage

This design is a bit complex, but very similar to the existing dynamicproxy system that is used to manage Toolforge and Cloud VPS reverse proxies.

I'm considering having a go at this. I might use TLS client certificates rather than HTTP Basic auth + lua + redis.
@EBernhardson/@Mathew.onipe (or anyone else involved in cloudelastic), are you likely to get to this before mid-August?

bd808 moved this task from Backlog to WikiElastic on the Data-Services board.May 30 2019, 7:03 PM