Reverse Proxy on Separate Host?

Hello All,

We are looking to deploy OOD and have a question regarding the Reverse Proxy Setup. We are curious is it possible to configure the reverse proxy on a separate host from our main OOD server? The reason for this is for security reasons we have our OOD isolated from the rest of our environment and it currently cannot talk to compute nodes directly which I believe is needed for the reverse proxy to work. We are curious if we can shift this part of the workflow to another host that does have the necessary connectivity to the compute nodes?

Sorry in advance if this question seems confusing and thanks in advance for the support!

Nate

Hi,
yes, you can. I had this setup at our site where I had two OODs running, each within the networks of different clusters, but wanted users to be able to submit and launch jobs across the clusters so I had to pass off the proxy from one OOD server to the other. Once the job was launched, the other OOD server was just handling the proxy. IIRC, I think you can, for instance, add an ONDEMAND_HOST.

Eric gave me this suggestion when I was doing this, change the submit.yml.erb file, for instance:

 batch_connect:
   template: vnc
  conn_params:
    - ONDEMAND_HOST
 script:
   accounting_id: "<%= account %>"
  job_environment:
    ONDEMAND_HOST: "this.is.a.custom.set.value"

Which results in the connection.yml file containing:

ONDEMAND_HOST: this.is.a.custom.set.value

Thanks! We will give this a shot and see if we can get it to work. I much appreciate the feedback.

Nate

@rsettlag One quick and maybe silly question … does the host that is running the reverse proxy (in your case inside each cluster) need to be exposed publicly for the proxy to work correctly? I suspect the answer is yes, and when users open something just a Jupyter notebook they are handed over to the host running the reverse proxy.

Thanks in advance for your insight.

Nate

Not sure what you mean by publicly, we are public within the VT network and access controls apply. In our case, this is behind the VT VPN.

Sorry @rsettlag, I should have been more clear … does the user need to access the reverse proxy directly via port 443 (behind VPN is fine)?

For example does the following occur:

Assumptions:

  • Main OOD Server (192.168.100.1)
  • Proxy Server running on Cluster (10.0.0.1)
  • Compute Node (10.0.0.2)

When a user wants to access a Jupyter Notebook, does the following workflow occur:

  • User launches an Jupyter Notebook on 192.168.100.1
  • Scheduler spins up a Jupyter Notebook on a compute node
  • User select “Connect to Jupyter” on 192.168.100.1
  • User is redirected to 10.0.0.1 which proxies out to 10.0.0.2

Hopefully that makes more sense? But it still might be as clear as mud?

Basically what I am getting as if the the Proxy Server is firewalled off so external users can’t access it directly, does the proxy process still work? I assume it does not.

I think the workflow is stated a little differently for clarity:

  • User uses the Jupyter Notebook APP on 192.168.100.1 which submits a job to scheduler
    
  • Scheduler spins up a Jupyter Notebook on a compute node
    
  • User select “Connect to Jupyter” on 192.168.100.1
    
  • User is redirected to 10.0.0.1 which proxies out to 10.0.0.2
    

So, now the question is what do users have access to.

if your users don’t have access to the internal proxy, they need a proxy from 192.168.100.1 to 10.0.0.1 which in turn proxies to 10.0.0.2. But it sounds like you can redirect.