-
Notifications
You must be signed in to change notification settings - Fork 472
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
Issue #1579 TLSRoute Passthrough Conformance Test (normative) #1587
Issue #1579 TLSRoute Passthrough Conformance Test (normative) #1587
Conversation
Hi @candita. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
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.
Did you test this on any implementations?
conformance/base/manifests.yaml
Outdated
app: infra-backend-v4 | ||
spec: | ||
containers: | ||
- name: infra-backend-v4 |
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 we need a 4th backend (with 2 replicas)? Or can we just add TLS to the existing ones?
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.
Agree that reusing an existing backend would be ideal here if we can.
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.
To conveniently use the existing echoserver
image, I created a new backend with the environment variables TLS_SERVER_CERT
and TLS_SERVER_PRIVKEY
for this image to serve certificates. See https://github.com/kubernetes-sigs/ingress-controller-conformance/blob/master/images/echoserver/echoserver.go#L109.
I also had to supply access to a new secret that is created during test Setup.
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.
Please let me know if this is ok.
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 think this could likely be added to an existing backend without breaking any conformance tests. Would be worth trying at least.
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.
The TLS backend, infra-backend-v4, is the only one using port/targetPort 443/8443. It is also the only one setup with env variables TLS_SERVER_CERT and TLS_SERVER_PRIVKEY, which as mentioned directs it to validate certs in the echoserver app.
It works fine with 1 replica for now, and will be reused for the rest of the TLSRoute Passthrough conformance tests. I think putting all of this together, that TLSRoute Passthrough should have its own configuration with non-standard ports and env variables.
I will rename it from infra-backend-v4 to tls-backend so that it is clear that this is a specially configured backend.
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'm OK with a new backend here, but can we add this TLS listener to an existing Gateway instead of adding a new Gateway just for this test?
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.
Thanks for all the work on this @candita! Looks like a great start.
conformance/base/manifests.yaml
Outdated
app: infra-backend-v4 | ||
spec: | ||
containers: | ||
- name: infra-backend-v4 |
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.
Agree that reusing an existing backend would be ideal here if we can.
Yes, I tested on Istio, but had to tweak it to make it get past some of the condition naming updates in Gateway API. |
…mative) rebase
d8212e6
to
ab91a3f
Compare
ffde551
to
22f2099
Compare
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.
Thanks @candita! I haven't had a chance to run this test yet, but this looks promising from what I can tell.
conformance/base/manifests.yaml
Outdated
app: infra-backend-v4 | ||
spec: | ||
containers: | ||
- name: infra-backend-v4 |
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 think this could likely be added to an existing backend without breaking any conformance tests. Would be worth trying at least.
JFYI, I was able to run this test and have it pass against Contour's implementation which has support for TLS passthrough. I haven't reviewed the code yet but will try to do so soon. Thanks! |
0aecd97
to
c2db3c5
Compare
dd79b10
to
6a39c14
Compare
@robscott: GitHub didn't allow me to request PR reviews from the following users: arkodg. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
conformance/utils/tls/tls.go
Outdated
// for MakeRequestAndExpectEventuallyConsistentResponse to consider the response "consistent" | ||
// before making additional assertions on the response body. If this number is not reached within | ||
// maxTimeToConsistency, the test will fail. | ||
const requiredConsecutiveSuccesses = 3 |
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.
nit: should this knob live closer to where maxTimeToConsistency
is defined since its applies to the conformance suite in general
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.
Sure. It was used in http.go as well, so I made it a global parameter of timeoutConfig in timeout.go
site-src/concepts/conformance.md
Outdated
|
||
```shell | ||
go test ./conformance --gateway-class my-class | ||
go test ./conformance/... -args -gateway-class=istio |
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.
nit: maybe stick to the neutral my-class
string ?
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.
You're right. When I began this, I wasn't sure if I needed to create a new gatewayClass, and it was helpful for me to get the example for one implementation. I reworded the rest of this in an attempt to make it clearer to newcomers. Maybe at some point we could list all the gateway-class names.
@@ -43,6 +46,9 @@ type Request struct { | |||
Method string | |||
Headers map[string][]string | |||
UnfollowRedirect bool | |||
CertPem []byte | |||
KeyPem []byte | |||
Server string |
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.
can the Host field be reused ?
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 considered Host
and Server
to be different. Server
is one of the TLSRoute.Spec.Hostnames
that aligns with CertPem
and KeyPem
, and is passed as the TLSClientConfig.ServerName
. Since TLSRoute.Spec.Hostnames
can contain wildcards, it might not match the host. Ie, we could have a TLS server *.example.com but a request host abc.example.com.
If you'd like to run a single test instead of the entire conformance suite, find your test name | ||
`(suite.ConformanceTest.ShortName)` and use it like this: | ||
```shell | ||
go test ./conformance/... --run TestConformance/YOURTESTNAME --gateway-class=istio |
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 can use flag supported-features
to specify the tests to run, for example:
go test ./conformance/... -supported-features=TLSRoute -gateway-class=my-class
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.
In this case, I wanted to explain how to run a single test case by name. I haven't quite figured out how to use the supported-features flag to my advantage, so I would ask for someone else to document that.
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.
test works with contour and from a quick look seems correct 👍🏽
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.
LGTM thanks !
/label tide/merge-method-squash |
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arkodg, candita, robscott, shaneutt 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 |
@candita: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/retest |
Issue #1579 TLSRoute Passthrough Conformance Test (normative)
What type of PR is this?
/area conformance
What this PR does / why we need it:
This is the first test specified in the TLSRoute Passthrough Conformance Test suite, the normative test. This test may be used as reference to learn more about designing conformance tests, particularly for TLSRoute Passthrough.
Which issue(s) this PR fixes:
This addresses part of Issue #1579
Does this PR introduce a user-facing change?: