Ignore default certificate during server initialization TLS loop

[zeeZ]

What this PR does / why we need it:

Currently, for each host, if the first (lowest resourceVersion) ingress configuration does not contain a TLS secret, the default certificate is set. This causes the controller to ignore newer ingress configurations that may reference a TLS secret.

This change allows configurations, where multiple ingress configurations exist for a host, with only one of them containing a TLS secret, to work more reliably.

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please email the CNCF helpdesk: [email protected]

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.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: zeeZ
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: dcbw

Assign the PR to them by writing /assign @dcbw in a comment when ready.

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

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

[codecov-io]

Codecov Report

Merging #2279 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master    #2279   +/-   ##
=======================================
  Coverage   40.92%   40.92%           
=======================================
  Files          72       72           
  Lines        5087     5087           
=======================================
  Hits         2082     2082           
  Misses       2716     2716           
  Partials      289      289

Impacted Files	Coverage Δ
internal/ingress/controller/controller.go	2.4% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c0ed143...ce1402d. Read the comment docs.

[antoineco]

Just to make sure I understand correctly, the issue you're describing happens when you deploy 2 separate Ingress objects similar to these?

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-cert
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: foobar
          servicePort: 80
  tls:
  - hosts:
    - foo.bar.com  # no custom cert

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: custom-cert
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /bar
        backend:
          serviceName: foobar
          servicePort: 80
  tls:
  - hosts:
    - foo.bar.com
    secretName: mysecret  # custom cert, but ignored

[zeeZ]

Yes.
If you create them in this order, the default certificate will be served.
If you create them in reverse order, mysecret is served.

The idea is to create a single custom-cert as a default somewhere, and then reuse the domain/certificate as in default-cert numerous times in other namespaces without having to maintain and upload copies of the exact same certificate.

This already works, just not consistently, since it depends on the age of all related objects.

I forgot to mention that this relates to #1944 (which I originally found when looking into this issue), except that I'm using an ingress object to serve as the "fallback" instead of a flag.

[aledbf]

Closing. PR #2972 changed the default behavior

[zeeZ]

I disagree. Running the current master (332b3ad) shows the same behaviour (using the foo.bar.com example above):

• apply default-cert, then custom-cert: default fake certificate
• apply custom-cert, then default-cert: mysecret certificate

The controller still sets the default certificate if it does not get one in the first attempt.

[zeeZ]

/reopen

This behavior still did not change.

[k8s-ci-robot]

@zeeZ: Failed to re-open PR: state cannot be changed. The ignore-default-certificate branch was force-pushed or recreated.

In response to this:

/reopen

This behavior still did not change.

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.