Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add tests for HTTPS #671

Merged
merged 1 commit into from
Mar 29, 2019
Merged

Add tests for HTTPS #671

merged 1 commit into from
Mar 29, 2019

Conversation

rramkumar1
Copy link
Contributor

@rramkumar1 rramkumar1 commented Mar 7, 2019 •
edited

Porting from k/k. Note that the PR to remove the tests in k/k is kubernetes/kubernetes#75840

This PR is already pretty big so I'll add transition tests in a followup.

Ref: #667

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 7, 2019
@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 7, 2019
@rramkumar1 rramkumar1 force-pushed the add-tests-for-https branch 3 times, most recently from ff23bfc to 3f6832d Compare March 8, 2019 19:17
@rramkumar1 rramkumar1 changed the title Add tests for HTTPS [WIP] Add tests for HTTPS Mar 8, 2019
@rramkumar1 rramkumar1 mentioned this pull request Mar 15, 2019
Closed
@rramkumar1
Copy link
Contributor Author

@bowei @MrHohn This is rebased and ready for a full review.

MrHohn
MrHohn approved these changes Mar 27, 2019
View reviewed changes
Copy link
Member

@MrHohn MrHohn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry that I missed this. LGTM overall

cmd/e2e-test/basic_https_test.go Outdated
name := fmt.Sprintf("cert%d--%s", i, s.Namespace)
cert, err := e2e.NewCert(name, h, tc.certType)
if err != nil {
t.Fatalf("error initializing cert: %v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (and a couple below): error -> Error

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

pkg/e2e/fixtures.go
@@ -153,3 +156,68 @@ func EnsureIngress(s *Sandbox, ing *v1beta1.Ingress) (*v1beta1.Ingress, error) {

return currentIng, nil
}

// DeleteSecret deletes a secret.
func DeleteSecret(s *Sandbox, name string) error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe putting these under cert.go as well?

func (c *Cert) Delete() {}
func (c *Cert) Create() {}
...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh..seems like this func is forgotten?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I purposefully left just that one since there may be a use case later to delete a secret not related to a cert.

cmd/e2e-test/basic_https_test.go
}
t.Logf("Ingress created (%s/%s)", s.Namespace, ing.Name)

ing, err = e2e.WaitForIngress(s, ing, nil)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't recall we have logic implemented to check if server responses with the correct cert based on request hostname. Similar to this https://github.com/kubernetes/kubernetes/blob/118e33dfcd8bf052f34d9a922145ab5f97e6a354/test/e2e/framework/ingress/ingress_utils.go#L638-L670.

Is that still necessary? (Maybe as followup if needed.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something but I don't know if that check is worth it. Is there a case when we could potentially configure GCLB to serve the wrong cert? My thinking was that this could only happen if the user made a config error.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One case that comes to my mind is in case of using multiple certs, if there is a bug that ingress controller attaches only one cert to GCLB, it will still pass this test. Should we at least check that all certs are attached?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we put a TODO / issue to fix this? We do need to check this behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I think checking that all certs are attached may be more worthwhile than checking if the "correct" cert is served. Will tackle that in the followup.

@rramkumar1 rramkumar1 force-pushed the add-tests-for-https branch 3 times, most recently from 3a358cb to 8c1147f Compare March 28, 2019 19:26
@rramkumar1 rramkumar1 mentioned this pull request Mar 28, 2019
Closed
@bowei
Copy link
Member

bowei commented Mar 28, 2019

/approve

@MrHohn
Copy link
Member

MrHohn commented Mar 29, 2019

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 29, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bowei, MrHohn, rramkumar1

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:
  • OWNERS [MrHohn,bowei,rramkumar1]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot merged commit ac81c7f into kubernetes:master Mar 29, 2019
@kubernetes kubernetes deleted a comment Mar 29, 2019
@rramkumar1 rramkumar1 mentioned this pull request Apr 8, 2019
Closed
@spiffxp spiffxp mentioned this pull request Sep 11, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@MrHohn MrHohn MrHohn approved these changes

@bowei bowei Awaiting requested review from bowei

@thockin thockin Awaiting requested review from thockin

Assignees

@bowei bowei

@MrHohn MrHohn

Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@rramkumar1 @bowei @MrHohn @k8s-ci-robot