Contour: Can't get tls TLSCertificateDelegation to work on master

Created on 6 Oct 2019 · 8Comments · Source: projectcontour/contour

I can't get TLSCertificateDelegation to work with master, TLS doesn't get enable on the HttpProxy of the app using a secret from another namespace.

What steps did you take and what happened:
Envoy uses NodePort:

$ kubectl -n projectcontour get svc
NAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
contour   ClusterIP   172.23.128.177   <none>        8001/TCP                     41h
envoy     NodePort    172.23.174.172   <none>        80:30467/TCP,443:30441/TCP   41h

Create TLS secret in NS projectcontour:

$ kubectl -n projectcontour get secret ingress-cert
NAME           TYPE                DATA   AGE
ingress-cert   kubernetes.io/tls   2      16h

Create a TLSCertificateDelegation in NS projectcontour:

$ kubectl -n projectcontour get TLSCertificateDelegation ingress-cert -o yaml
apiVersion: projectcontour.io/v1
kind: TLSCertificateDelegation
metadata:
  creationTimestamp: "2019-10-05T16:29:18Z"
  generation: 2
  name: ingress-cert
  namespace: projectcontour
  resourceVersion: "308120820"
  selfLink: /apis/projectcontour.io/v1/namespaces/projectcontour/tlscertificatedelegations/ingress-cert
  uid: e6e43b32-cbcf-446a-844c-6949791c55c9
spec:
  delegations:
  - secretName: ingress-cert
    targetNamespaces:
    - jap-s

Create a httpproxy in jap-s NS, status says it's valid:

$ kubectl -n jap-s get httpproxy  jap-performance-check-service -o yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  creationTimestamp: "2019-10-05T14:18:51Z"
  generation: 31
  name: jap-performance-check-service
  namespace: jap-s
  resourceVersion: "308345196"
  selfLink: /apis/projectcontour.io/v1/namespaces/jap-s/httpproxies/jap-performance-check-service
  uid: 7dd2ad29-8e86-4bea-a669-3c8cceddaf75
spec:
  routes:
  - conditions:
    - prefix: /jap/performance-check
    services:
    - name: jap-performance-check-service
      port: 443
  virtualhost:
    fqdn: jap-s.kubelab.mycorp.test
    tls:
      secretName: projectcontour/ingress-cert
status:
  currentStatus: valid
  description: valid HTTPProxy

The app is not reachable over https:

U112324@c90c1360 MINGW64 /
$ curl https://jap-s.kubelab.mycorp.test:30441/jap/performance-check/rest-ui/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0curl: (7) Failed to connect to jap-s.kubelab.mycorp.test port 30441: Connection refused

Http works:

$ curl http://jap-s.kubelab.mycorp.test:30467/jap/performance-check/rest-ui/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Swagger UI</title>
...

What did you expect to happen:
The app can be called over https using the cert from the secret ingress-cert.

Anything else you would like to add:

If I move the secret ingress-cert to the jap-s NS and reconfigure the HttpProxy to use it, tls works.
I see nothing interesting in the envoy or contour pod logs.
Didn't try other version of contour.

Environment:

Contour version: current (date 10.05.19) master Image from dockerhub (digest d3feadda0e98), install from examples/contour. Using NodePort for envoy.
Kubernetes version: (use kubectl version): v1.15.3
Kubernetes installer & version: puppet
Cloud provider or hardware configuration: vmaware
OS (e.g. from /etc/os-release): RHEL 7.6

kinbug prioritimportant-soon

Source

yvespp

Most helpful comment

@ghouscht @yvespp thank you for your issue report. I discovered that there are no end to end or feature tests for TLS cert delegation in httpproxy and as I'm writing some I'm increasingly worried that we didn't finish porting the feature over. Please stand by.

davecheney on 7 Oct 2019

👍2

All 8 comments

Related questions:

Does "*" work as a target NS in TLSCertificateDelegation? Only saw it mentioned in the concept but not the docs.
Should the TLSCertificateDelegation also work for kube Ingress resources? Only saw it mentioned in the concept but not the docs.

yvespp on 6 Oct 2019

Two both of your questions, yes.

I’ll look into the documentation issues tomorrow.

Thank you.

On 6 Oct 2019, at 20:36, Yves Peter notifications@github.com wrote:

Related questions:

Does "*" work as a target NS in TLSCertificateDelegation? Only saw it mentioned in the concept but not the docs.
Should the TLSCertificateDelegation also work for kube Ingress resources? Only saw it mentioned in the concept but not the docs.
—
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 6 Oct 2019

Had the same problem, it turned out that there are two different apiVersions/kind combinations for the delegations: tlscertificatedelegations.contour.heptio.com and tlscertificatedelegations.projectcontour.io. And somehow in my setup it only worked with apiVersion: contour.heptio.com/v1beta1 and kind: TLSCertificateDelegation.

ghouscht on 7 Oct 2019

That is correct, the former is the deprecated version from Ingressroute. The latter is the replacement in the project contour.io namespace.

davecheney on 7 Oct 2019

👍2

@yvespp should be working now. Please let us know how you go.

davecheney on 7 Oct 2019

@davecheney Tested with new master and it works now. Also tested wildcard in targetNamespaces in TLSCertificateDelegation and delegation with ingress resources.
Thanks for the quick fix!

yvespp on 8 Oct 2019

You’re welcome. Big props to @stevesloka for pushing this over the line.

On 8 Oct 2019, at 19:18, Yves Peter notifications@github.com wrote:

@davecheney Tested with new master and it works now. Also tested wildcard in targetNamespaces in TLSCertificateDelegation and delegation with ingress resources.
Thanks for the quick fix!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.