-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enabling Internal Encryption breaks DomainMappings when using Contour #862
Comments
Okay #860 didn't totally fix this, going to reopen while I address that |
This issue is stale because it has been open for 90 days with no |
I think the work to add https to clusterLocal routes here (knative-extensions/net-certmanager#538) might help in this scenario. |
This issue is stale because it has been open for 90 days with no |
there is an effort to rework some of the internal encryption changes for Knative (see https://github.com/orgs/knative/projects/63/views/1) As we progress with that, I plan to revisit net-contour. I will try to address this issue then |
This issue is stale because it has been open for 90 days with no |
/lifecycle frozen |
What version of Knative?
Relocating from knative/serving#13659 since this is just a Contour issue.
Working off main branch of knative-serving, net-contour
Discovered while trying to add internal encryption e2e tests for net-contour here: knative/serving#13536
Expected Behavior
When I create a DomainMapping for my Knative Service when Internal Encryption is enabled, I am able to reach the KService successfully.
Actual Behavior
DomainMappings fail to become ready, get stuck in "EndpointsNotReady"
net-contour controller says:
I also see this in envoy logs:
When I try this out with AutoTLS enabled, the domainmappings become ready, but I still get the error when I try hitting the endpoint.
Steps to Reproduce the Problem
Analysis
I think the problem is in part due to fact that DomainMappings point you back at the envoy.
If you look at the DAG, you can see all the routes point to a service on port 443. However, the one for hello goes to 80:
(DAG output comes from the Contour controller, see here)
That service spec looks like this:
Internal encryption was implemented so that ports named http2 are h2c when internal encryption is disabled, h2 when enabled.
This means that the HTTPProxy defines hitting the hello service on port 80 with h2 protocol.
So when Envoy tries to make the call, it uses https (for h2), but hits the http listener on Envoy.
When you put autotls on, there is at least a listener for 443 now, but it doesn't have the route data to deal with the request (since svc.cluster.local domains don't get TLS).
Suggestion
I think one way around this is to use the internal encryption secrets for the ClusterLocal visibility domains when internal encryption is enabled. That way you get a listener on 443 for those domains. Then you'd need to change the svc to also use 443. The trouble with that is that it is kinda venturing towards TLS for ClusterLocal routes, which is probably a big undertaking.
I suppose another, more simple option is to make the calls from the envoy back to itself not use encryption. But to me, that seems like leaving a hole in the internal encryption path.
The text was updated successfully, but these errors were encountered: