Chef Server (and Chef Automate) don't support running behind reverse proxy using URL routing

[jillson]

NOTE:
We use GitHub issues to track bugs and feature requests. If you need help please post to our Mailing List or join the Chef Community Slack.

• Chef Community Slack at http://community-slack.chef.io/.
• Chef Mailing List https://discourse.chef.io/

(Note that I looked; https://discourse.chef.io/t/changing-the-chef-server-name-and-or-url/5180 and https://discourse.chef.io/t/changing-chef-api-url/6813 were asked by the same person 3.5 and 5 years ago and no one responded)

Chef Server Version

[What version of Chef Server? Any plugins? Are you using Chef Backend? What versions?]
Chef Server, Chef Automate (latest versions as of Feb 2019)

Platform Details

[Operating system distribution and release version. Cloud provider and instance type if running in the cloud. Total/Free RAM and disk space. Is this running in a container?]
Running on RHEL / CentOS on EC2 instances on AWS

Configuration

[Standalone, Tiered, HA, Chef Backend? New install or upgrade? Ideally include your /etc/opscode/chef-server.rb or otherwise provide details of changes from the default]
Chef and Chef Automate are both running as non-HA

Scenario:

[What you are trying to achieve and you can't?]
We have a reverse proxy that only supports URL based proxying (i.e. we'd like https://myserver/chef to proxy to https://chef.internal and https://myserver/automate to proxy to https://automate.internal). There does not appear to be any documentation on how to do this; unlike gitlab or other tools where you can either specifcy an external URL or otherwise specify a subdirectory for the application to listen for, chef and chefautomate appear to only support a hostname (FQDN).

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]
Using stock configuration

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]
https://myexternalproxy/chef brings up the chef login page and all URL's are of the form /chef/ instead of just /

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]
Fails miserably; redirects to /

[markan]

I assume that https://myserver/automate likewise doesn't forward correctly?

If I understand things correctly you would like to access the web interface through this proxy. So chef stuff would go to chef-manage, and automate stuff would go to the automate server. I'm not sure where we stand with the new automate, but I suspect that chef-manage has some baked in assumptions about the the distinction between the host and resource portion of the URI.

So it sounds like any changes needed are going to be in the chef-manage and automate projects and so we'll need to work with them. I know there's no good way to file an issue against them, so for now we'll track this here until we sort this out in more detail.

If you want to also hit the chef server API (e.g. you want chef client/knife runs against that proxy) that will require a bit more work. The signing protocol signs the resource (e.g. chef) as part of the request, so stripping the resource will invalidate the signature, and fail.

[jillson]

That is correct; I was not able to get automate to support forwarding from /automate to a bare /. It looks like automate-ui portion should be amenable (since it's running Angular and has a base-href flag, but I didn't see any knobs to change it through config.toml ... as an aside, it would be nice if updates to chef-automate created a latest sym link (so e.g. I could write a chef recipe that can count on /hab/svc/automate-ui/latest/config/whatever to be the file I want to update via chef)) but other pieces were more problematic. Of course, one of the pieces that was most problematic was the Dex stuff (which not coincidentally I'm substantially less familiar with to know if there are any easy knobs to tweak things) and even after reverting things so automate is /, I'm still having issues with switching tabs for 60 seconds == forced to log back in, which I was initially attributing to bad interactions between applications (e.g. some other application was setting a cookie for / with the same name as chef-automate and so switching between them overwrites the other's cookie) ... so maybe Automate could be made to work. Good to know re: chef server / knife things.

Regarding

[mal]

We're also interested in this functionality, specifically for the API (which as mentioned is more problematic due to assumptions made when checking request signatures). Is that also covered by this feature request (I ask because it's tagged chef-manage and automate, but not opscode-erchef), or is it worth creating a second one to specifically cover the API? Thanks :)