Add endpoint to proxy HTTP request to build services
This is a follow-up issue for #205 (closed).
For security reasons, mostly because we can't trust the services running in the containers (Kubernetes), we can't use the main domain to proxy requests to the runner. For that matter, we're adding a new param to Workhorse called userContentDomain
. For demonstration purposes let's assume the domain is gitlabusercontent.com
.
The general workflow of the whole feature will be like the following:
- The user will start the web IDE terminal
- The FE service will detect that the terminal job is running and will ask the backed for some information about the web IDE terminal.
- Within this information, we will return the proxy URL, something like
https://gitlab.com/namespace/project/-/jobs/123/proxy
- Within this information, we will return the proxy URL, something like
- When the user clicks or activates the Live preview functionality, the FE will create an iframe using the url
https://gitlab.com/namespace/project/-/jobs/123/proxy
with the paramsservice
andport
. - This url will go to the
JobsController
where we will perform some authorizations and, if the user can access the proxy, we will redirect the user to the proper url with the paramtoken
(generated on the fly),service
andport
.- This new url will have the structure
http://randomstring.gitlabusercontent.com
. -
randomstring
is a random hex string generated each time the user asks for a proxy url. Why adding a subdomain instead of using the main proxy domain? Because we're going to use sessions and we don't want to store the session in the primary domain but in a subdomain. - The
token
param is a token encoded with JWT using the Workhorse secret. This way, if the token is invalid, the request will reach Workhorse and, when it tries to decode it, an error will be raised and an unnecessary request avoided to get to Rails for preauthorization. - The JWT token will have a very short expiration time (1 minute or even less)
- This new url will have the structure
- When the request
http://randomstring.gitlabusercontent.com?token=foobar&service=example_service&port=1234
reaches Workhorse we will get the build service info (mostly from the query params) and save them into the session. - Workhorse will also try to decode
token
. If the decoding fails, we stop the request and return an HTTP error. - With the build service info, we will build the Rails API endpoint url and make the preauthorization request.
- If everything goes smoothly, the build runner info will be sent back to Workhorse.
- Workhorse will store this info as well in the session to avoid, for every request to the same build, checking again the preuthorization endpoint.
- After the preauthorization, we will redirect the user to
http://randomstring.gitlabusercontent.com
and, from that point, any request will be proxied to the runner
Edited by Francisco Javier López (ex-Gitlab)