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.

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

TLS for ingress identifier #1145

Open
esbie opened this issue Mar 16, 2017 · 6 comments
Open

TLS for ingress identifier #1145

esbie opened this issue Mar 16, 2017 · 6 comments

Comments

@esbie
Copy link
Contributor

esbie commented Mar 16, 2017

As an ingress-controller, we ought to support tls as defined here: https://kubernetes.io/docs/user-guide/ingress/#tls

@esbie
Copy link
Contributor Author

esbie commented May 3, 2017

This issue is blocking potential features like https://github.com/jetstack/kube-lego integration for LetsEncrypt

@esbie esbie added the istio label Jun 26, 2017
@esbie
Copy link
Contributor Author

esbie commented Jun 26, 2017

Also, Istio support should include tls via ingress resources (not necessarily SNI, but at least dynamic cert reloading)

@valdemon
Copy link

As this has been closed - does it mean the feature is perceived as unimportant and disappears from the Linkerd roadmap?

@wmorgan
Copy link
Member

wmorgan commented Feb 16, 2018

@klingerf and I chatted--closing was an oversight. Sorry. This is still on the roadmap. @valdemon do you have a use case for this feature?

@wmorgan wmorgan reopened this Feb 16, 2018
@valdemon
Copy link

valdemon commented Feb 17, 2018

@klingerf Our use case leverages the automatic TLS certificate lifecycle management for services exposed via k8s Ingress using LetsEncrypt and the kube-lego mentioned before by @esbie.

Currently I'm using NGINX Ingress Controller and it works for me well enough. We might be interested in switching to Linkerd Ingress Controller though, as soon as it provides this feature.

Except of having a single Ingress class (less of artifacts to deploy) I guess this would likely also give us better traceability (metrics) of network communication flow (provided by Linkerd-viz, Zipkin etc), starting already from the Ingress controller associated k8s service.

Below is our current Ingress example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-service
  namespace: my-system
  annotations:
    kubernetes.io/tls-acme: "true"
    ingress.kubernetes.io/secure-backends: "true"
    kubernetes.io/ingress.class: "nginx"
    external-dns.alpha.kubernetes.io/hostname: "my-service.example.org."
    external-dns.alpha.kubernetes.io/ttl: 60
spec:
  tls:
    - hosts:
      - my-service.example.org
      secretName: my-service-ingress-tls
  rules:
  - host: my-service.example.org
    http:
      paths:
      - backend:
          serviceName: my-service
          servicePort: 4140

@wmorgan
Copy link
Member

wmorgan commented Feb 18, 2018

@valdemon Thanks, that's very helpful.

Tim-Brooks pushed a commit to Tim-Brooks/linkerd that referenced this issue Dec 20, 2018
* v0.4.4 release notes

* Tweak wording about adblocker fix

Signed-off-by: Kevin Lingerfelt <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants