Open Mokto opened 4 years ago
I encountered exactly the same issue on Ambassador 0.86.0 - TLS context is not applied for a TCP Mapping with host
specified.
Okay, so I've done a little bit of digging and I think I found the problem.
For V2TCPListener
TLS context looked up in the group
and it's never there, so the following branch is never taken:
In contrast, for V2Listener
TLS context is taken from the config
:
I've tried doing a quick patch of v2listener.py
to get TLS context from the config.ir.get_tls_contexts()
for V2TCPListener
and it seems to solve the issue: the TLS context now appears in the envoy config for the TCP mapping and the TCP mapping starts to work correctly (i.e. doing TLS termination as it supposed to).
Not sure what is the "proper" fix for this, but hopefully this info will help developers to address the issue.
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.
I'm running into the same problem with the following setup:
Error message:
listener '0.0.0.0:5672': multiple filter chains with the same matching rules are defined
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.
@ovk, I'm very sorry for missing your comment! Let me try your fix.
any updates @kflynn? We are running into exactly this issue too.
Hi @kflynn had any luck with a fix? We are hitting this in our project. Thanks!
Hello, @kflynn any update on this?
Any updates on this? We are trying amassador 1.5.5 @nbkrause ?
Just a hint for debugging purposes:
Don't set an ambassador_id on the pods or find a way how to specify the ambassador_id for a TCPMapping. This way it mostly works.
Hi, is a fix for this issue planned in the near future? We are hitting this in our project. Thanks.
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.
Not stale
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.
Not stale
Also running into a similar issue
We are facing the same issue. Is there any update?
Same issue with version 1.14.2
.
I defined just one Host
object and a TCPMapping
object.
The correct certificate is returned but the HTTP response is 404 Not Found.
---
apiVersion: getambassador.io/v2
kind: TCPMapping
metadata:
name: ambassador-mapping
namespace: myns
labels:
map: ambassador-mapping
spec:
ambassador_id: [ "ambassador1" ]
port: 8443
host: test.ambassador
host_regex: false
service: test-deploy-service:8443
tls: true
apiVersion: getambassador.io/v2
kind: Host
metadata:
name: ambassador-host
namespace: myns
spec:
ambassador_id: [ "ambassador1" ]
hostname: test.ambassador
tlsSecret:
name: mysecret-tls
When the Host
object is created this is added under spec:
selector:
matchLabels:
hostname: test.ambassador
However there is no label nor field named "hostname" in the TCPMapping
object.
How is it supposed to work ?
I am having this problem as well. Is anyone aware of a workaround?
Has anyone had this experience on Emissary or AES 2.x or greater? Checking the latest docs here, @bemipefe 's config looks correct to me. First, Emissary-ingress checks for any Host resources with TLS configured whose Host.spec.hostname glob-matches the TCPMapping.spec.host; if such a Host exists, then its TLS certificate and configuration is used..
yes, we experience this trying to TLS terminate a TCP Mapping on Emissary v 3.4.1
apiVersion: getambassador.io/v3alpha1
kind: Host
metadata:
name: arc-github-hook
namespace: actions-runner-system
spec:
hostname: "arc-github-hook.example.com"
tlsSecret:
name: webhook-tls-cert
tls:
min_tls_version: v1.2
max_tls_version: v1.3
alpn_protocols: h2[, http/1.1]
ecdh_curves:
- X25519
- P-256
---
apiVersion: getambassador.io/v3alpha1
kind: TCPMapping
metadata:
name: arc-github-hook
namespace: actions-runner-system
spec:
port: 9443
host: "arc-github-hook.example.com"
service: http://actions-runner-controller-github-webhook-server:8080
Debug log output:
[2023-02-15 12:40:55.060][37][debug][filter] [source/extensions/filters/listener/tls_inspector/tls_inspector.cc:86] tls inspector: new connection accepted
[2023-02-15 12:40:55.060][37][debug][filter] [source/extensions/filters/listener/tls_inspector/tls_inspector.cc:117] tls:onServerName(), requestedServerName: arc-github-hook.example.com
[2023-02-15 12:40:55.060][37][debug][filter] [source/common/tcp_proxy/tcp_proxy.cc:199] [C148859] new tcp proxy session
[2023-02-15 12:40:55.061][37][debug][filter] [source/common/tcp_proxy/tcp_proxy.cc:371] [C148859] Creating connection to cluster cluster_actions_runner_controller_github-D3A891DE11DE7378-0
[2023-02-15 12:40:55.061][37][debug][upstream] [source/common/upstream/cluster_manager_impl.cc:1731] no healthy host for TCP connection pool
[2023-02-15 12:40:55.061][37][debug][connection] [source/common/network/connection_impl.cc:139] [C148859] closing data_to_write=0 type=1
[2023-02-15 12:40:55.061][37][debug][connection] [source/common/network/connection_impl.cc:250] [C148859] closing socket: 1
Ok, thanks for the confirmation. I'll flag this as a community reported bug.
Describe the bug Hi! I've been struggling with this issue for the past afternoon, and after a lot of researches, I'm starting to suspect this is a bug. I can't apply a TCPMapping tls/host configuration. Without TLS I can connect to my rabbitmq server, but I can't use TLS termination. It is also impossible to use SNI (seems logical as tls doesn't work). By the way any webservice access works in HTTPS mode.
To Reproduce Steps to reproduce the behavior:
Install Ambassador with an additional port on the loadbalancer service :
TLSContext configuration :
Apply a TCPMapping
The TLSContext seems not to be applied to the 5671 listener. See my envoy configuration :
Versions (please complete the following information):
Thanks for your help!