Feature Request: Ability to run with a URL prefix specified as an environmental variable

[aebrahim]

It would be very helpful if this site could run under a URL prefix, e.g. /access that could be configured at runtime by an environmental variable.

That way, instead of needing to use a new domain for this, we could add an entry (e.g. /access) to our already set up URL map.

[jpassing]

I'm a bit torn on this... there's nothing wrong with sharing a load balancer if the other backends are in different projects. But it's typically not a good idea to reuse the JIT Access project to deploy other applications because that raises the risk that those other applications can access the JIT Access service account (which is fairly highly-privileged). Does that make sense?

[aebrahim]

By the way, the link you sent is in corp so I don't have access.

Thanks for the response! I believe that in our specific use case, it would not make a difference which project the highly-privileged service account is in, because we use infrastructure-as-code through terraform to configure it, so the mechanism to assign privilege is not project-dependent. For more details, we maintain 3 separate projects, one for each of dev (pushed continuously on submit), preprod (used to QC prior to release), and prod. The access for service accounts in our prod project would be controlled just as tightly as any other "JIT Access Project" would be. Additionally, using a service account in the same project would let us test our JIT access configurations in dev and preprod prior to a deployment in prod. I hope the overly detailed background about our project is helpful!

There are a few reasons re-using a prefix on the same domain will be helpful for us:

1. No need to do a migration by adding another domain to google_compute_managed_ssl_certificate, which would otherwise cause downtime.
2. We can now use relative links in our internal dashboards to directly redirect to pages needed to get additional access, instead of needing to figure out the correct domain to link to for each environment.
3. This is relatively minor, but assigning DNS to domains is not automated for us (the demise of cloud domains will only make this harder to implement for us as a GCP shop). So each new domain we have to deploy means 3 more manual steps for us, one for each environment.