We're using the new Certificate Manager and #23495 does the trick if you create a wildcard certificate in advance. Wildcards are probably a better match for now, since you can have only twenty certificates, each with up to ten fully qualified domains, plus there's an yearly limit, too, so I'm reluctant to have the controller manager burn through such a scarce resource, especially if there are bugs or misconfigurations. An improvement might be to have the controller look up certificates by host/domain name, instead of having to hardcode the ARN.

See #19899 for lets encrypt integration. Having at least one way to get/renew real certs cross-platform makes sense, that's not to say we can't support multiple platform-specific ways.

I imagine that if a user creats something like:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  tls:
  - hosts:
    - foo.bar.com
    - foobar.bar.com
    secretName: ""
  backend:
    serviceName: echoserver-https
    servicePort: 80

A cluster wide cert controller (or a cert sidecar in the ingress controller) would notice this, get the certs and populate the secret field. Only then would the haproxy/nginx/cloudlb pick the Ingress up.

Taking this a step further, we could install admission controllers that never allowed non-https Ingress (like a cluster wide HSTS flag). Either a real (letsencrypt style), internal (pki server signed) or self signed cert is required.

Moving to 1.4; we can likely do this outside of core (e.g. kube-lego), so we won't do anything in 1.3 I believe

@justinsb ok to move this to 1.6? please holler if not appropriate

Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.

Given that there has been no activity in v1.7, moving to v1.8.

[MILESTONENOTIFIER] Milestone Removed

@justinsb

Important:
This issue was missing labels required for the v1.8 milestone for more than 7 days:

priority: Must specify exactly one of [priority/critical-urgent, priority/important-longterm, priority/important-soon].

Removing it from the milestone.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close