Page MenuHomePhabricator

Create mechanism to allow the use of vanity domains by projects behind the Cloud VPS shared HTTP proxy
Open, Needs TriagePublicFeature

Description

The most common reason for a Cloud VPS project to request a floating IP (sometimes called a "static IP" or a "public IP") is to support the use of a custom "vanity" domain for their webservice.

IPv4 addresses are a scarce resource. Name based virtual hosting including SNI for use with TLS have been invented in part to allow hosting services such as Cloud VPS to consolidate many webservices behind a single IP. Bypassing the Cloud VPS shared proxies also creates new PII exposure for project maintainers to deal with in the form of visitor IP addresses in their webservice logs.

A more ideal solution than handing out IP addresses would be support in the Cloud VPS proxy service for using a custom domain. I think it would be reasonable for this to require some amount of administrative review and support. There may certainly be more adopters if the process was easier than it is today, but I would honestly be surprised if it resulted in more than 1-2 new domain setup requests per month as a worst case.

Event Timeline

Our Acme-chief system for provisioning Let's Encrypt certs has support for http-01 challenges. The ::profile::acme_chief class includes comments describing how to configure an nginx service to forward /.well-known/acme-challenge/... URLs to acme-chief for validation.

Supporting apex domains (like example.com) may be fragile because of DNS limitations on CNAME usage. For subdomains (like my-tool.example.com or www.example.com) it should be sufficient to create a CNAME record in the external DNS provider's system that points the subdomain at our wmcloud.org host.

I don't think that providing DNS services or domain parking should be considered in-scope for this feature.

Right now the Cloud VPS system makes a fairly heavy assumption that everything it handles has its DNS hosted on our Designate servers, and changing that is a somewhat large project.

A relatively simple solution would be to set up a new VM or two with the profile::wmcs::proxy::static profile (which was originally invented for the maps proxy), point a new (single) floating IP to that server and tell everyone using this system to ask us to manually update the mappings when they need those to be changed.

Change 1010505 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: add support for per-project zones

https://gerrit.wikimedia.org/r/1010505

Change 1010506 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] dynamicproxy: allow specifying different certs for each zone

https://gerrit.wikimedia.org/r/1010506

Change 1010505 merged by Majavah:

[operations/puppet@production] dynamicproxy: add support for per-project zones

https://gerrit.wikimedia.org/r/1010505

Change 1010506 merged by Majavah:

[operations/puppet@production] dynamicproxy: allow specifying different certs for each zone

https://gerrit.wikimedia.org/r/1010506

The patches merged above add support for adding zones that are not visible to all projects, and configuring an individual zone to use a specific TLS certificate. I believe the next steps are, roughly, to:

  • Add support for zones that are not managed in Designate. This includes setting up the proxy to route http01 ACME challenges to the acme-chief host.
  • Add support for configuring proxies in the zone apex.
  • Figure out and document a process for enabling this on a project.

Change 1011167 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] P:acme_chief: allow enabling http-01 spport

https://gerrit.wikimedia.org/r/1011167

Change 1011168 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/puppet@production] P:wmcs::novaproxy: proxy http-01 challenges to acme-chief

https://gerrit.wikimedia.org/r/1011168