Describe the bug The Ambassador container within ambassador pod does not spawn up properly on a local cluster with kubernetes 1.10.2

To Reproduce Steps to reproduce the behavior: A fresh install of kubernetes 1.10.2 on a local cluster. Follow the guidance to install ambassador-no-rbac.

Expected behavior expect ambassador to spawn up. but it give error code 137. Both liveness probe and Readiness probe failed with getsockopt: connection refused.

ambassador-6c7dd7799b-2mjzx   1/2       CrashLoopBackOff   13         37m

Versions (please complete the following information):

• Ambassador: 0.32.1
• Kubernetes environment: local cluster installed using kubeadm. Configured with calico.
• Version 1.10.2
• Ubuntu 16.04

Additional context Someone @richarddli suggested this is due to a dns problem, but local dns (/etc/resolve.conf) is configured using 8.8.8.8 and 8.8.4.4, I am sure at least I can access google website. (By deploying a busybox into my cluster, I checked my busybox container can ping google.com, but not sure for others.) Here are some extra log for debugging

[email protected]:~/my-kubeflow$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
I0503 10:46:23.833551       1 dns.go:48] version: 1.14.8
I0503 10:46:23.862220       1 server.go:71] Using configuration read from directory: /kube-dns-config with period 10s
I0503 10:46:23.862374       1 server.go:119] FLAG: --alsologtostderr="false"
I0503 10:46:23.862433       1 server.go:119] FLAG: --config-dir="/kube-dns-config"
I0503 10:46:23.862466       1 server.go:119] FLAG: --config-map=""
I0503 10:46:23.862485       1 server.go:119] FLAG: --config-map-namespace="kube-system"
I0503 10:46:23.862504       1 server.go:119] FLAG: --config-period="10s"
I0503 10:46:23.862532       1 server.go:119] FLAG: --dns-bind-address="0.0.0.0"
I0503 10:46:23.862551       1 server.go:119] FLAG: --dns-port="10053"
I0503 10:46:23.862592       1 server.go:119] FLAG: --domain="cluster.local."
I0503 10:46:23.862621       1 server.go:119] FLAG: --federations=""
I0503 10:46:23.862648       1 server.go:119] FLAG: --healthz-port="8081"
I0503 10:46:23.862668       1 server.go:119] FLAG: --initial-sync-timeout="1m0s"
I0503 10:46:23.862688       1 server.go:119] FLAG: --kube-master-url=""
I0503 10:46:23.862742       1 server.go:119] FLAG: --kubecfg-file=""
I0503 10:46:23.862761       1 server.go:119] FLAG: --log-backtrace-at=":0"
I0503 10:46:23.862794       1 server.go:119] FLAG: --log-dir=""
I0503 10:46:23.862815       1 server.go:119] FLAG: --log-flush-frequency="5s"
I0503 10:46:23.862835       1 server.go:119] FLAG: --logtostderr="true"
I0503 10:46:23.862854       1 server.go:119] FLAG: --nameservers=""
I0503 10:46:23.862872       1 server.go:119] FLAG: --stderrthreshold="2"
I0503 10:46:23.862891       1 server.go:119] FLAG: --v="2"
I0503 10:46:23.862911       1 server.go:119] FLAG: --version="false"
I0503 10:46:23.862953       1 server.go:119] FLAG: --vmodule=""
I0503 10:46:23.863269       1 server.go:201] Starting SkyDNS server (0.0.0.0:10053)
I0503 10:46:23.864231       1 server.go:220] Skydns metrics enabled (/metrics:10055)
I0503 10:46:23.864282       1 dns.go:146] Starting endpointsController
I0503 10:46:23.864363       1 dns.go:149] Starting serviceController
I0503 10:46:23.901849       1 logs.go:41] skydns: ready for queries on cluster.local. for tcp://0.0.0.0:10053 [rcache 0]
I0503 10:46:23.901936       1 logs.go:41] skydns: ready for queries on cluster.local. for udp://0.0.0.0:10053 [rcache 0]
I0503 10:46:24.364803       1 dns.go:170] Initialized services and endpoints from apiserver
I0503 10:46:24.364871       1 server.go:135] Setting up Healthz Handler (/readiness)
I0503 10:46:24.364935       1 server.go:140] Setting up cache handler (/cache)
I0503 10:46:24.364962       1 server.go:126] Status HTTP port 8081
I0504 04:33:43.169511       1 dns.go:555] Could not find endpoints for service "tf-hub-0" in namespace "kubeflow". DNS records will be created once endpoints show up.
I0515 01:02:23.572540       1 dns.go:555] Could not find endpoints for service "tf-hub-0" in namespace "kubeflow". DNS records will be created once endpoints show up.

[email protected]:~/my-kubeflow$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
I0503 10:46:24.860136       1 main.go:76] opts: {{/usr/sbin/dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053] true} /etc/k8s/dns/dnsmasq-nanny 10000000000}
I0503 10:46:24.870496       1 nanny.go:94] Starting dnsmasq [-k --cache-size=1000 --no-negcache --log-facility=- --server=/cluster.local/127.0.0.1#10053 --server=/in-addr.arpa/127.0.0.1#10053 --server=/ip6.arpa/127.0.0.1#10053]
I0503 10:46:25.334307       1 nanny.go:116] dnsmasq[12]: started, version 2.78 cachesize 1000
I0503 10:46:25.334618       1 nanny.go:116] dnsmasq[12]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify
I0503 10:46:25.334632       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain ip6.arpa
I0503 10:46:25.334638       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain in-addr.arpa
I0503 10:46:25.334643       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain cluster.local
I0503 10:46:25.334651       1 nanny.go:116] dnsmasq[12]: reading /etc/resolv.conf
I0503 10:46:25.334657       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain ip6.arpa
I0503 10:46:25.334662       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain in-addr.arpa
I0503 10:46:25.334668       1 nanny.go:116] dnsmasq[12]: using nameserver 127.0.0.1#10053 for domain cluster.local
I0503 10:46:25.334672       1 nanny.go:116] dnsmasq[12]: using nameserver 8.8.8.8#53
I0503 10:46:25.334678       1 nanny.go:116] dnsmasq[12]: using nameserver 8.8.4.4#53
I0503 10:46:25.334716       1 nanny.go:116] dnsmasq[12]: read /etc/hosts - 7 addresses
I0503 10:46:25.334851       1 nanny.go:119]
W0503 10:46:25.334861       1 nanny.go:120] Got EOF from stdout

[email protected]:~/my-kubeflow$ kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar
I0503 10:46:25.240827       1 main.go:51] Version v1.14.8
I0503 10:46:25.240868       1 server.go:45] Starting server (options {DnsMasqPort:53 DnsMasqAddr:127.0.0.1 DnsMasqPollIntervalMs:5000 Probes:[{Label:kubedns Server:127.0.0.1:10053 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:33} {Label:dnsmasq Server:127.0.0.1:53 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:33}] PrometheusAddr:0.0.0.0 PrometheusPort:10054 PrometheusPath:/metrics PrometheusNamespace:kubedns})
I0503 10:46:25.240906       1 dnsprobe.go:75] Starting dnsProbe {Label:kubedns Server:127.0.0.1:10053 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:33}
I0503 10:46:25.240992       1 dnsprobe.go:75] Starting dnsProbe {Label:dnsmasq Server:127.0.0.1:53 Name:kubernetes.default.svc.cluster.local. Interval:5s Type:33}
W0503 10:46:25.241374       1 server.go:64] Error getting metrics from dnsmasq: read udp 127.0.0.1:58432->127.0.0.1:53: read: connection refused

Can anyone help me have a look? Many thanks in advance!

Description

This bug has already been fixed in the past and it came back when updating the Helm Chart from 6.5.5 to 6.5.6 (or Ambassador 1.7.1 to 1.7.2).

Even if one follows the documentation for ClearText support, Ambassador categorically refuses to forward non HTTP requests and always forces redirection (HTTP 301).

---
apiVersion: getambassador.io/v2
kind: Module
metadata:
  name: ambassador
  namespace: ambassador
spec:
  config:
    enable_grpc_web: true
    use_proxy_proto: false
    use_remote_address: true
    x_forwarded_proto_redirect: false
...
apiVersion: getambassador.io/v2
kind: Host
metadata:
  name: ambassador
  namespace: ambassador
spec:
  hostname: "*.example.com"
  acmeProvider:
    authority: none
  requestPolicy:
    insecure:
      action: Route
      additionalPort: -1
...

Bumps k8s.io/api from 0.21.9 to 0.24.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps k8s.io/apimachinery from 0.21.9 to 0.24.4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Describe the bug If the Host header provided in a request includes the port, Ambassador responds with a 404 where there is an otherwise valid route.

To Reproduce Steps to reproduce the behavior:

1. Setup a Host and Mapping
2. curl https://myhostname.com will work because curl sends Host: myhostname.com
3. curl https://myhostname.com -H "Host: myhostname.com:443" will return a 404 with an empty body

Expected behavior Ambassador should ignore the port portion of the Host header, or at least treat the default ports as equivalent to the absence of a port.

Versions (please complete the following information):

• Ambassador: AES 1.1.0
• Kubernetes environment: Digital Ocean Managed Kubernetes
• Version: 1.16.2-do.3

Additional context Our client is using Qt's QNetworkAccessManager to send requests, but upon testing Ambassador I have found that requests were failing from our client (but working from browsers, curl, etc.) Initially I assumed this was a bug in Qt, but the RFC states that the Host header may include a port.

Describe the bug

When talking to a service through ambassador that has an auth service, was getting what appeared to be random responses between 200, 503, and 403. Had replica of 3 set for the ambassador deployment. Upon looking at the logs, one pod was always giving 200 responses, another 503, and another 403. Tried restarting the trouble pods with no luck.

As a workaround I made my deployment to just replica 1 and now only seem to be getting 200 responses. Only saw this bug when I upgraded to 0.53.1. Was previously on version 0.50.3.

Versions (please complete the following information):

• Ambassador: 0.53.1
• Kubernetes environment (bare metal)
• Version 1.13.1

Describe the bug

We had clean install of ambassador edge on aws instance running kubeadm 1.17.0. Then we deployed grpc hello world example but executing greeter_client.py result in an error. Also, grpc example pod log has some strange error

sudo docker logs 0a6f7953d987 -f E0129 08:00:33.483639279 9 http_server_filter.cc:299] GET request without QUERY E0129 08:01:33.479603017 9 http_server_filter.cc:299] GET request without QUERY E0129 08:02:33.482634173 9 http_server_filter.cc:299] GET request without QUERY

and running greeter_client.py with ambassador host and port give and error:

python greeter_client.py Traceback (most recent call last): File "greeter_client.py", line 38, in run() File "greeter_client.py", line 32, in run response = stub.SayHello(helloworld_pb2.HelloRequest(name='you')) File "/home/ubuntu/.local/lib/python2.7/site-packages/grpc/_channel.py", line 824, in call return _end_unary_response_blocking(state, call, False, None) File "/home/ubuntu/.local/lib/python2.7/site-packages/grpc/_channel.py", line 726, in _end_unary_response_blocking raise _InactiveRpcError(state) grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with: status = StatusCode.UNIMPLEMENTED details = "unknown service edge_stack_ui/helloworld.Greeter" debug_error_string = "{"created":"@1580285513.750873999","description":"Error received from peer ipv4:172.31.79.169:80","file":"src/core/lib/surface/call.cc","file_line":1056,"grpc_message":"unknown service edge_stack_ui/helloworld.Greeter","grpc_status":12}"

To Reproduce Steps to reproduce the behavior:

1. Clean install ambassador edge
2. configure host and certificate
3. download and deploy grpc example hello world
4. lanch greeter_client.py with ambassador host and port

Expected behavior expected a reply $ python greeter_client.py Greeter client received: Hello, you!

Versions (please complete the following information):

• Ambassador Ede stack : [1.0.0]
• Kubernetes environment: Kubeadm
• Version [1.17.0]

Additional context Add any other context about the problem here.

Describe the bug url path is not preserved with redirect_cleartext_from set

To Reproduce

1. Follow TLS Termination documentation to create cert and store as kubernetes secret

2. Deploy ambassador with helm chart 2.2.1 with values:

service:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Module
      name: tls
      config:
        server:
          enabled: True
          secret: ambassador-certs
          redirect_cleartext_from: 8080

3. Deploy httpbin service to test redirect

---
apiVersion: v1
kind: Service
metadata:
  name: httpbin
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  httpbin_mapping
      prefix: /httpbin/
      service: httpbin.org:80
      host_rewrite: httpbin.org
spec:
  ports:
  - name: httpbin
    port: 80

4. curl the endpoint using http

curl -Li http://hostname/httpbin/

5. Result: path is not preserved on redirect

HTTP/1.1 301 Moved Permanently
location: https://hostname/
date: Wed, 24 Apr 2019 20:12:19 GMT
server: envoy
content-length: 0

HTTP/2 404 
date: Wed, 24 Apr 2019 20:12:19 GMT
server: envoy

Expected behavior Path should be preserved and redirect to https://hostname/httpbin/

Versions (please complete the following information):

• Ambassador: [0.60.0] (using Helm chart 2.2.1)
• Kubernetes environment: [AKS]
• Version [1.12.7]

Additional context

Describe the bug When AuthService returns a non-200 response to Ambassador, only one set-cookie header can be sent back to the client, all other set-cookie headers are stripped. All cookies have the same domain, max_age, etc.

To Reproduce Steps to reproduce the behavior:

1. Setup a v1 (0.50.1) AuthService that adds more than one set-cookie header on auth responses
2. Send a non-200 response (302 in this case so that the request does not continue upstream) from AuthService with >1 set-cookie header on response
3. Verify all set-cookie headers are present on response from AuthService as the response passes back through Ambassador; there should be >1 set-cookie header on the response from the AuthService and only 1 set-cookie header on the response that Ambassador filters and sends back to the client

Expected behavior We expect all set-cookie headers to be returned by Ambassador when the AuthService returns a response. Rolling the service back to Ambassador v0.40.2 results in the expected behavior.

Versions (please complete the following information):

• Ambassador: [e.g. 0.32.1]
• Kubernetes environment [e.g. Minikube, bare metal, Google Kubernetes Engine]
• Version [e.g. 1.8.1]

Additional context Here is logging we captured of the issue. Notice that x-request-destination is preserved but session is removed in the final response.

[2019-02-07 20:41:58.736][000059][debug][http] [source/common/http/async_client_impl.cc:96] async http request response headers (end_stream=false):
':status', '302'
'server', 'nginx/1.15.0'
'date', 'Thu, 07 Feb 2019 20:41:58 GMT'
'content-type', 'text/html; charset=utf-8'
'content-length', '941'
'connection', 'keep-alive'
'location', 'https://dev-syapse.auth0.com/authorize?response_type=code&client_id=Y4EF4s3mw3IvLKFUUggL9Xgz64g0pH6h&redirect_uri=https%3A%2F%2Fambassador.dev.syapse.com%2Fauthz%2Fv1%2Fauth0%2Fcomplete&scope=openid+profile+email+user_metadata+app_metadata&state=u63YpJcjSweLIFyOQpqfFL1ZvRSLxI&audience=https%3A%2F%2Fdev-syapse.auth0.com%2Fuserinfo&prompt=none'
'set-cookie', 'x-request-destination=https://oncology-web-2.dev.syapse.com/; Domain=.syapse.com; Path=/'
'vary', 'Cookie'
'set-cookie', 'session=.eJyrVopPLC3JMACTOZlJ8cmJOTlJicnZ8UpWShklJQXFVvr6iblJicXFiSn5RXopqWV6xZWJBcWpesn5ufogXVX6ZYZghoE-UKggJ7UkVUkH3djiksSSVJCZpWbGkQVeyVnB5ak-nm6V_oEFhWluPoZRZUHBPhWeSrUAJe00QQ.XFyYFg.8BzD07RYRXiRz8Iz2s-9U3S3XUg; Domain=.syapse.com; HttpOnly; Path=/'
'x-content-type-options', 'nosniff'
'x-frame-options', 'SAMEORIGIN'
'x-xss-protection', '1; mode=block'
'strict-transport-security', 'max-age=15768000; includeSubDomains'
'x-envoy-upstream-service-time', '27'

[2019-02-07 20:41:58.740][000059][debug][client] [source/common/http/codec_client.cc:95] [C141708] response complete
[2019-02-07 20:41:58.740][000059][debug][filter] [source/extensions/filters/http/ext_authz/ext_authz.cc:177] [C141707][S17486080943075874799] ext_authz rejected the request
[2019-02-07 20:41:58.740][000059][debug][http] [source/common/http/conn_manager_impl.cc:1096] [C141707][S17486080943075874799] encoding headers via codec (end_stream=false):
':status', '302'
'content-length', '941'
'content-type', 'text/plain'
'location', 'https://dev-syapse.auth0.com/authorize?response_type=code&client_id=Y4EF4s3mw3IvLKFUUggL9Xgz64g0pH6h&redirect_uri=https%3A%2F%2Fambassador.dev.syapse.com%2Fauthz%2Fv1%2Fauth0%2Fcomplete&scope=openid+profile+email+user_metadata+app_metadata&state=u63YpJcjSweLIFyOQpqfFL1ZvRSLxI&audience=https%3A%2F%2Fdev-syapse.auth0.com%2Fuserinfo&prompt=none'
'set-cookie', 'x-request-destination=https://oncology-web-2.dev.syapse.com/; Domain=.syapse.com; Path=/'
'date', 'Thu, 07 Feb 2019 20:41:58 GMT'
'server', 'envoy'

[2019-02-07 20:41:58.741][000059][debug][pool] [source/common/http/http1/conn_pool.cc:209] [C141708] response complete
[2019-02-07 20:41:58.741][000059][debug][pool] [source/common/http/http1/conn_pool.cc:247] [C141708] moving to ready[2019-02-07 20:41:58.736][000059][debug][http] [source/common/http/async_client_impl.cc:96] async http request response headers (end_stream=false):
':status', '302'
'server', 'nginx/1.15.0'
'date', 'Thu, 07 Feb 2019 20:41:58 GMT'
'content-type', 'text/html; charset=utf-8'
'content-length', '941'
'connection', 'keep-alive'
'location', 'https://dev-syapse.auth0.com/authorize?response_type=code&client_id=Y4EF4s3mw3IvLKFUUggL9Xgz64g0pH6h&redirect_uri=https%3A%2F%2Fambassador.dev.syapse.com%2Fauthz%2Fv1%2Fauth0%2Fcomplete&scope=openid+profile+email+user_metadata+app_metadata&state=u63YpJcjSweLIFyOQpqfFL1ZvRSLxI&audience=https%3A%2F%2Fdev-syapse.auth0.com%2Fuserinfo&prompt=none'
'set-cookie', 'x-request-destination=https://oncology-web-2.dev.syapse.com/; Domain=.syapse.com; Path=/'
'vary', 'Cookie'
'set-cookie', 'session=.eJyrVopPLC3JMACTOZlJ8cmJOTlJicnZ8UpWShklJQXFVvr6iblJicXFiSn5RXopqWV6xZWJBcWpesn5ufogXVX6ZYZghoE-UKggJ7UkVUkH3djiksSSVJCZpWbGkQVeyVnB5ak-nm6V_oEFhWluPoZRZUHBPhWeSrUAJe00QQ.XFyYFg.8BzD07RYRXiRz8Iz2s-9U3S3XUg; Domain=.syapse.com; HttpOnly; Path=/'
'x-content-type-options', 'nosniff'
'x-frame-options', 'SAMEORIGIN'
'x-xss-protection', '1; mode=block'
'strict-transport-security', 'max-age=15768000; includeSubDomains'
'x-envoy-upstream-service-time', '27'

[2019-02-07 20:41:58.740][000059][debug][client] [source/common/http/codec_client.cc:95] [C141708] response complete
[2019-02-07 20:41:58.740][000059][debug][filter] [source/extensions/filters/http/ext_authz/ext_authz.cc:177] [C141707][S17486080943075874799] ext_authz rejected the request
[2019-02-07 20:41:58.740][000059][debug][http] [source/common/http/conn_manager_impl.cc:1096] [C141707][S17486080943075874799] encoding headers via codec (end_stream=false):
':status', '302'
'content-length', '941'
'content-type', 'text/plain'
'location', 'https://dev-syapse.auth0.com/authorize?response_type=code&client_id=Y4EF4s3mw3IvLKFUUggL9Xgz64g0pH6h&redirect_uri=https%3A%2F%2Fambassador.dev.syapse.com%2Fauthz%2Fv1%2Fauth0%2Fcomplete&scope=openid+profile+email+user_metadata+app_metadata&state=u63YpJcjSweLIFyOQpqfFL1ZvRSLxI&audience=https%3A%2F%2Fdev-syapse.auth0.com%2Fuserinfo&prompt=none'
'set-cookie', 'x-request-destination=https://oncology-web-2.dev.syapse.com/; Domain=.syapse.com; Path=/'
'date', 'Thu, 07 Feb 2019 20:41:58 GMT'
'server', 'envoy'

[2019-02-07 20:41:58.741][000059][debug][pool] [source/common/http/http1/conn_pool.cc:209] [C141708] response complete
[2019-02-07 20:41:58.741][000059][debug][pool] [source/common/http/http1/conn_pool.cc:247] [C141708] moving to ready

Here's the AuthService annotation that we are using:

  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: AuthService
      name: authentication
      auth_service: {auth-service-url-and-port}
      path_prefix: "/v1/validate"
      allowed_authorization_headers:
      - "set-cookie"
      - "session"
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: authz_mapping
      prefix: /authz/
      service: {auth-service-url-and-port}
      tls: true

We also verified this behavior against normal non-AuthService request/response flows, and did not see Ambassador filtering any response headers.

Description

The cap_net_bind_service capability allows a process to bind to a low port without root. While Kubernetes lets you allow a capability in the pod spec, the effective capabilities are wiped when the root -> user transition is made.

This change setcap's the binary so that it can assert that capability. e.g.

 securityContext:                                                                                                                                  |~
   capabilities:                                                                                                                                   |~
     add:                                                                                                                                          |~
       - NET_BIND_SERVICE

(there is no CAP_ at the beginning; K8s seems to add that)

If you don't want to bind to a low port, don't add the capability and we're back to the previous behavior. If you want to bind to a low port, add the capability and configure Ambassador appropriately.

Related Issues

This is a feature addition -- I want to be able to run this as a non root user but still bind to a low port.

Testing

Manual testing.

Todos

• [ ] Tests
• [ ] Documentation

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/[email protected]: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.

Bumps importlib-metadata from 5.0.0 to 6.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Description

Cause more confusion than its worth.

Checklist

• [x] Does my change need to be backported to a previous release?

  • release/v3.4 (after GA)
  • release/v2.5

• [ ] I made sure to update CHANGELOG.md.

  Remember, the CHANGELOG needs to mention:

  • Any new features
  • Any changes to our included version of Envoy
  • Any non-backward-compatible changes
  • Any deprecations

• [ ] This is unlikely to impact how Ambassador performs at scale.

  Remember, things that might have an impact at scale include:

  • Any significant changes in memory use that might require adjusting the memory limits
  • Any significant changes in CPU use that might require adjusting the CPU limits
  • Anything that might change how many replicas users should use
  • Changes that impact data-plane latency/scalability

• [ ] My change is adequately tested.

  Remember when considering testing:

  • Your change needs to be specifically covered by tests.
    • Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
  • You also need to make sure that the entire area being changed has adequate test coverage.
    • If existing tests don't actually cover the entire area being changed, add tests.
    • This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
  • We should lean on the bulk of code being covered by unit tests, but...
  • ... an end-to-end test should cover the integration points

• [ ] I updated DEVELOPING.md with any any special dev tricks I had to use to work on this code efficiently.

• [ ] The changes in this PR have been reviewed for security concerns and adherence to security best practices.

Describe the bug We are running an Istio multi-cluster setup with 2 clusters. We are using Istio version 1.14.1 on all workloads, including emissary-ingress, which is injected with the istio-proxy sidecar via the istio.io/rev: 1-14-1 label on the emissary namespace; i.e. standard practice. This is all running on 2 GKE clusters running kubernetes versionv1.21.14-gke.4300

We installed emissary-ingresss following this documentation - https://www.getambassador.io/docs/emissary/latest/howtos/istio

If we exec into an emissary-ingress pod, we can communicate with workloads on the same cluster as expected. When we try to communicate with a workload on the remote cluster, we receive 504 Gateway Timeout responses. DNS resolution for remote services is working.

Another non-emissary pod in the same namespace as the emissary-ingress pods, can communicate with the remote service without issue. This seems to point to emissary-ingress as being the problem is this case.

Expected behavior To be able to communicate with remote services.

Versions (please complete the following information):

• emissary-ingress - 3.3.1
• helm chart version emissary-ingress-8.3.1
• Kubernetes environment - GKE
• Version - v1.21.14

Please describe your use case / problem. Currently apiext and the CRDs are kind of loosely managed from a helm user perspective. That means that as a helm user I have to manually delete and update the apiext deployment and the CRDs.

Describe the solution you'd like As a helm user I would expect to maintain only the emissary-ingress helm release, which "ships" its CRDs and the apiext deployment. One solution would be to define the CRDs and apiext in seperate helm charts, which the emissary-ingress helm chart depends on.

Describe alternatives you've considered Include the CRDs and the apiext deployment directly in the emissary-ingress chart as described here. That would work for the apiext deployment, but upgrading the CRDs would not be supported by it.

Additional context Part of https://github.com/emissary-ingress/emissary/issues/4531

Please describe your use case / problem. One of the best practices of Kubernetes is to define resource requests and limits. Requests are what the container is guaranteed to get. If a container requests a resource, Kubernetes will only schedule it on a node that can give it that resource. Limits, on the other hand, make sure a container never goes above a certain value. Currently apiext does not have these requests and limits defined.

Describe the solution you'd like Add resource requests and limits to the apiext deployment.

Describe alternatives you've considered Documentation why it is not defined and explain how customers can define their own resource request and limits. (e.g. with Kustomize)

Additional context Part of: https://github.com/emissary-ingress/emissary/issues/4531

Describe the bug How to use feature on ssl-passthrough in emissary

To Reproduce Steps to reproduce the behavior: I am not sure how to use ssl passthrough in emissary? In one the issue I can see that TCPMapping can be used but I dont know how to use it and it didnt worked for me. please help me resolving the issue How to use feature on ssl-passthrough in emissary

Expected behavior SSL passthrough must work

Versions (please complete the following information):

• Ambassador: [e.g. 0.32.1]
• Kubernetes environment [e.g. Minikube, bare metal, Google Kubernetes Engine]
• Version [e.g. 1.8.1]

Additional context Add any other context about the problem here. Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'I am not sure how to use ssl passthrough in emissary? In one the issue I can see that TCPMapping can be used but I dont know how to use it and it didnt worked for me. please help me resolving the issue
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Versions (please complete the following information):

• Ambassador: [e.g. 0.32.1]
• Kubernetes environment [e.g. Minikube, bare metal, Google Kubernetes Engine]
• Version [e.g. 1.8.1]

Additional context Add any other context about the problem here.