-
Notifications
You must be signed in to change notification settings - Fork 83
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
Host cluster-local-domain TLS on local listener with SNI #1156
Host cluster-local-domain TLS on local listener with SNI #1156
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ReToCode The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #1156 +/- ##
==========================================
+ Coverage 80.81% 81.12% +0.30%
==========================================
Files 18 18
Lines 1392 1462 +70
==========================================
+ Hits 1125 1186 +61
- Misses 213 219 +6
- Partials 54 57 +3 ☔ View full report in Codecov by Sentry. |
8df6096
to
bb2aadb
Compare
@@ -48,11 +48,13 @@ import ( | |||
|
|||
type translatedIngress struct { | |||
name types.NamespacedName | |||
sniMatches []*envoy.SNIMatch | |||
localSNIMatches []*envoy.SNIMatch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking out loud is there a scenario where a ksvc wants to communicate with an egress target via the knative local gateway and the target does not need mutual tls. I was wondering about the use of auto_sni.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm sounds to me more like a Service-Mesh case. I don't think we ever want to go through kourier for egress traffic, right?
@@ -166,14 +166,14 @@ func TestDeleteIngressInfoWhenDoesNotExist(t *testing.T) { | |||
assert.DeepEqual(t, listenersBeforeDelete, listenersAfterDelete, protocmp.Transform()) | |||
} | |||
|
|||
func TestTLSListenerWithEnvCertsSecret(t *testing.T) { | |||
func TestExternalTLSListener(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to support
- TestExternalTLSListenerWithEnvCertsSecrets
- TestExternalTLSListenerWithInternalCertSecret
- ?
Local is only meant to use the config map config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I get your question.
The ExternalTLS Listener is for cluster-external domains and the cluster-local one is for the cluster-local domains. Both can have the SNI option (has already been there for the external one, this PR adds it for cluster-local) when a specific cert is there for a specific domain, and a general certificate for all other traffic (that is already there for both listeners).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but the tests were renamed and the source of the cert can be either env or some cm config. What do we support for internal and external cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I felt the naming did not really reflect what they test. Both cases can have a default cert for all domains and specific ones for specified domains, I think we do cover all of them for both cases with:
func TestExternalTLSListener(t *testing.T) {
// sets the default cert
t.Setenv(envCertsSecretNamespace, "certns")
t.Setenv(envCertsSecretName, "secretname")
// Test with only default domains
t.Run("without SNI matches", func(t *testing.T) {}
// Test with one added specific domain
t.Run("with a single SNI match", func(t *testing.T) {}
// Test with two added specific domains
t.Run("with multiple SNI matches", func(t *testing.T) {}
}
LGTM in general waiting for @nak3 before stamping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a plan to add conformance or e2e test for this cluster local domain TLS in networking or net-* repos like external domain for test/conformance/ingress/tls.go
?
Yes this is the plan in knative/serving#13855. I'm not sure yet how they can look like exactly. I think we should finish the implementation end to end for one ingress then add conformance tests. Also Serving will get additional end-2-end tests draft here. |
ff34a0d
to
a216e45
Compare
a216e45
to
9f3405e
Compare
/unhold Networking PR is merged: knative/networking#891, conformance tests is tracked in knative/serving#13855. So this is ready to be reviewed again @nak3 @skonto |
Tested in knative/serving#14703 stamping. |
/lgtm |
Changes
cluster-local-domain-tls
is enabled and a KSVC existsinternal
->local
to be consistent with the new encryption flags/hold requires knative/networking#891 to be merged first.
/kind enhancement
Fixes knative/serving#14218
Partially knative/serving#14624
Release Note
Docs
Will be done once the features is complete