Yeah that would work and is the mechanism that allows people direct access to e.g. the bastions and the tools login machines. The other potential option is just to require people using the test setup to use some custom SSH config to proxy through the bastions to get there.

In T261900#6452479, @brennen wrote:

Thanks! I think I also need to ask for a hostname - that is, ideally people should be able to SSH to gitlab-test.wmcloud.org, and I don't think I can point that at the floating IP myself from Horizon? (It also conflicts with the existing web proxy.)

As you say, this hostname is currently an A record pointed to the shared HTTPS proxy service. There is no port discrimination in DNS, so you will need to either a) pick a different name for your custom ssh endpoint or b) stop using the shared HTTPS proxy and handle TLS termination yourself. The preferred way for handling custom DNS like this would be for us to create a zone matching your gitlab-test project name (gitlab-test.wmcloud.org.) and delegate ownership of that zone to your project. Then you can make DNS records in the zone as needed yourself using Horizon.

The project owned zone and a matching name at the shared proxy is also possible, so you can use the proxy and a related hostname for your ssh endpoint. That might look something like https://gitlab-test.wmcloud.org for the HTTPS endpoint and ssh.gitlab-test.wmcloud.org for the ssh endpoint. This would keep you from needing to handle TLS yourself, but does mean that your git clone URLs would vary on hostname as well as protocol.

or b) stop using the shared HTTPS proxy and handle TLS termination yourself

Yeah, this shouldn't be a problem; the GitLab omnibus setup we're using supports Let's Encrypt by default.

In T261900#6452596, @brennen wrote:

or b) stop using the shared HTTPS proxy and handle TLS termination yourself

Yeah, this shouldn't be a problem; the GitLab omnibus setup we're using supports Let's Encrypt by default.

@nskaggs the runbook for creating and transferring ownership of a zone is at https://wikitech.wikimedia.org/wiki/Portal:Cloud_VPS/Admin/DNS/Designate#DNS_zone_creating_/_transfers. I *think* you will have to remove the current proxy via Horizon before Designate will let you make the zone. Designate is interestingly picky about order of operations and name collisions (and record naming in general honestly).

Mentioned in SAL (#wikimedia-releng) [2020-09-11T19:27:58Z] <brennen> gitlab-test may experience some downtime as a result of zone transfer for T262516, T261900