The README mentions that SLL/TLS support is a work in progess. SNI has landed in envoy now (https://github.com/envoyproxy/envoy/issues/95).
I'm wondering what is the plan / timeline for using that SNI support in contour? I have some projects blocked by the support, and if it's not fairly soon was wondering if it's an open project I could take on.
cmaloney
All 2 comments
It’s planned for the current, 0.3, release.
On 5 Dec 2017, at 09:02, Cody Maloney notifications@github.com wrote:
The README mentions that SLL/TLS support is a work in progess. SNI has landed in envoy now (envoyproxy/envoy#95).
I'm wondering what is the plan / timeline for using that SNI support in contour? I have some projects blocked by the support, and if it's not fairly soon was wondering if it's an open project I could take on.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
davecheney
on 4 Dec 2017
As the basic SNI functionality is in and TLS ingresses now work I'm going to mark this issue as closed. There will be more testing and polish to come for the 0.3 milestone in January, but this can be used in the contour:master image now.
Testing notes
Deployment
You must use the deployment/deployment-grpc-v2 manifests. These are different to the quickstart manifests mentioned in the project README. SNI support requires switching to the grpc api, which will become the default for the 0.3 release.
TLS secrets
Like other ingress controllers, contour watches for secret objects that contain tls.crt and tls.key values. You will need to manually configure these secret objects on a per ingress basis or use something like kube-lego to generate them from Let's Encrypt.
Contour will work with kube-lego, but requires you to edit the ingress class on the ingress object that kube-lego creates to handle the authentication challenge.
kubectl -n kube-lego edit ing
and change kubernetes.io/ingress.class: nginx to kubernetes.io/ingress.class: contour so that Contour will see the additional ingress. You will need to repeat this frequently as kube-lego rewrites the ingress object and will overwrite your change.
Contour should work with other Let's Encrypt operators like jetstack/cert-manager, but this has not been tested yet.
Known issues
- Virtually no annotations are supported, see #63 for example
- In EC2 the ELB is put into tcp passthrough mode, which causes the remote address to be overwritten with the internal ip address of the ELB. See #103 for PROXY protocol support.
davecheney
on 22 Dec 2017
Related issues
davecheney
·
4Comments
annismckenzie
·
3Comments
jonasrosland
·
6Comments
davecheney
·
6Comments
jpeach
·
7Comments
Most helpful comment
As the basic SNI functionality is in and TLS ingresses now work I'm going to mark this issue as closed. There will be more testing and polish to come for the 0.3 milestone in January, but this can be used in the
contour:masterimage now.Testing notes
Deployment
You must use the deployment/deployment-grpc-v2 manifests. These are different to the quickstart manifests mentioned in the project README. SNI support requires switching to the grpc api, which will become the default for the 0.3 release.
TLS secrets
Like other ingress controllers, contour watches for secret objects that contain
tls.crtandtls.keyvalues. You will need to manually configure these secret objects on a per ingress basis or use something like kube-lego to generate them from Let's Encrypt.Contour will work with kube-lego, but requires you to edit the ingress class on the ingress object that kube-lego creates to handle the authentication challenge.
and change
kubernetes.io/ingress.class: nginxtokubernetes.io/ingress.class: contourso that Contour will see the additional ingress. You will need to repeat this frequently as kube-lego rewrites the ingress object and will overwrite your change.Contour should work with other Let's Encrypt operators like jetstack/cert-manager, but this has not been tested yet.
Known issues