Ambassador: Host CRD does not route insecure requests

[daninthewoods]

Describe the bug
Despite using the Host CRD for http-only in the docs, Ambassador refuses to route non-http requests and always forces 301 redirect.

To Reproduce
Use the following k8s yaml

apiVersion: getambassador.io/v2
kind: Host
metadata:
  name: minimal-host
spec:
  hostname: host.example.com
  acmeProvider:
    authority: none
requestPolicy:
  insecure:
    action: route
---
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
  name: hello-world-mapping
spec:
  prefix: /hello-world/
  service: hello-world
---
apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  selector:
    app: hello-world
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: infrastructureascode/hello-world

Curl to curl -v http://host.example.com:30845/hello-world/
See 301 redirect

*   Trying 192.168.64.5...
* TCP_NODELAY set
* Connected to host.example.com (192.168.64.5) port 30845 (#0)
> GET /hello-world/ HTTP/1.1
> Host: host.example.com:30845
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< location: https://host.example.com:30845/hello-world/
< date: Sun, 19 Jan 2020 15:15:13 GMT
< server: envoy
< content-length: 0
<
* Connection #0 to host host.example.com left intact

Expected behavior
Expect Host definition to allow http-only requests, no redirects.

Versions (please complete the following information):

• Image: quay.io/datawire/aes:1.0.0
• Image ID: docker-pullable://quay.io/datawire/aes@sha256:4a6577ca83178fbbfd8295d68312b2d92b6820dfd97e6a36e2ec1337ac4cf66b
• minikube version: v1.6.2

Additional context
I review of the generated envoy.json file shows the vhost host.example.com has an entry for the /hello-world/ path, but it is set to redirect: true. Seems like the insecure-action route is not being recognized.

[daninthewoods]

sanitized.zip

[mrtnfchs]

It seems that I'm experiencing the same behaviour. I've tried creating a Host resource in multiple ways and it seems my settings are ignored. Ambassador keeps on redirecting http traffic and I'm not able to overwrite it with Reject or Route

[sadeghhp]

I have this problem too!
HTTP only is not working

[jfrabaute]

Hi,

I just sent a PR with a possible fix (Working on my env.).
If people having the issue can test an ambassador with the fix, that would be great.

Thanks !

[buehler]

Dear Ambassador Team

This issue is really annoying :-) (so to speak)
We are running into the same issue here. We have a service that can't handle https connections and _needs_ to be http. Right now, we cannot use ambassador to route to the service, since all calls get redirected.

Is there any possibility that this fix will get merged?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jfrabaute]

Not stale.

Is it still buggy in the latest versions of ambassador?
The PR https://github.com/datawire/ambassador/pull/2499 we use works fine for our custom build based on 1.3.1.
I haven't had the time to work on either checking if this is fixed in a new version of ambassador, or porting this PR to the latest version (this is probably what I'm going to do if latest version is still not ok).

[mauriceackel]

@jfrabaute I can confirm that this is still an issue in version 1.7.4 (installed via helm). A fix would be highly appreciated 🙏

[mauriceackel]

@kflynn This issue deserves a higher priority, as it renders any non https traffic impossible

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[buehler]

not stale :)

[Shivam9268]

+1
We also face this problem.

[majjie]

+1 Happening here too.

[kflynn]

So the reason that the setup described up top in this issue isn't working in 1.10 is that the Host CRD is invalid: the requestPolicy block needs one more level of indentation. Setting the Host CRD up as follows works fine for me:

apiVersion: getambassador.io/v2
kind: Host
metadata:
  name: minimal-host
spec:
  hostname: interesting-torvalds-4476-beta.edgestack.me
  acmeProvider:
    authority: none
  requestPolicy:
    insecure:
      action: Route

Note that requestPolicy is indented to be a peer of acmeProvider under spec.

This raises some interesting questions:

• First and foremost, can we tighten the validation so that you'll get errors about this sort of invalid resource?? (The answer needs to be yes, we'll figure out how.)
• Second, I doublechecked all the docs at https://www.getambassador.io/docs/latest/topics/running/host-crd/ and they look good. I did _not_ go back and check all the historic versions, so I'm not sure if we screwed them up in the past, but it's _definitely_ possible. If so, mea culpa!
• Lastly, I don't even want to admit how many times I looked at that CRD without seeing the error. 🙁

I'm going to close this issue, but please reopen if other badness is going on. Thanks!

[mauriceackel]

Hi all, this is interesting..

I just went back in time and checked the docs of previous versions. Then I got curious and checked the code which I also had troubles with and it turns out I was using a valid resource description. However, I was using version 1.7.4 at that time.. Perhaps this issue got somehow fixed in a later version so that it is no issue in 1.10 anymore?!

@Shivam9268 and @majjie Which versions are you running?

And thank you @kflynn for looking into this!

[kflynn]

@mauriceackel I'm sad to say that there were _definitely_ issues with Host CRDs in various 1.7 releases, so it's entirely possible that that was the root of your problem. (And there's still more to be done.)

[buehler]

Thank you for the work @kflynn I'm trying to check it as soon as possible.

[majjie]

@mauriceackel - I'm running version 1.9.1

I've double checked my YAML, and it all seems good. But I'm happy to be corrected:

Host names may have been changed to protect the innocent :)

Still getting redirected to 443 every time.

```---
apiVersion: getambassador.io/v2
kind: Host
metadata:
name: internal-id-host
spec:
hostname: id.internal.foo.com
acmeProvider:
authority: none
requestPolicy:
insecure:
action: Route

[kflynn]

@majjie My immediate thought is to wonder about ambassador_id or AMBASSADOR_SINGLE_NAMESPACE -- you're sure that Ambassador is loading that CRD? Next step would probably be to set AMBASSADOR_DEBUG=diagd and send me the pod logs (after looking them over to remove sensitive things)...

[majjie]

@kflynn - fair question, I'll get you a readout from the pod presently.

In the mean time, I can say that other hosts in the same cluster with acme providers set are working. A sample being:

```apiVersion: getambassador.io/v2
kind: Host
metadata:
name: external-id-host
spec:
hostname: id.foo.com
acmeProvider:
email: [email protected]

[kflynn]

@majjie Ahhh -- take a look at #2888 and see if that describes your problem? We're still working on that one. 🙁

[majjie]

Ah! OK... that looks like it. Kind of relieved. In truth, I'm not sure how to set AMBASSADOR_DEBUG=diagd I'm still relatively new to all of this. Google wasn't being much use about it.

I have a workaround for the time being, so holding tight is no biggy. Thanks for your help.

[kflynn]

Cool, thanks. Anyone else here, I'd definitely recommend checking out #2888 -- tag yourself on that one if it matches your situation. Thanks!!