design: add fallback certificate design doc

[stevesloka]

Updates #1503

Signed-off-by: Steve Sloka slokas@vmware.com

[codecov]

Codecov Report

Merging #2428 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2428   +/-   ##
=======================================
  Coverage   76.72%   76.72%           
=======================================
  Files          68       68           
  Lines        5522     5522           
=======================================
  Hits         4237     4237           
  Misses       1188     1188           
  Partials       97       97           

---

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 b40d846...3c1d05c. Read the comment docs.

[jpeach]

Overall, I think this is a good proposal. I have a couple of questions about the mechanics of the envoy filters, and where we put the Contour config. If you prefer, we can address these in PRs.

The doc uses both "fallback certificate" and "default certificate", so we should standardize on one (I think default is the most common term?)

[jpeach]

The only comparable option I could find in the API was EnableWebsockets, so maybe we should make this EnableFallbackCertificate or EnableDefaultCertificate for consistency.

[stevesloka]

I like that better, thanks for the suggestion!

[jpeach]

I don't see this change, am I looking at the right commit?

[stevesloka]

So I played around with this in Envoy for a bit. I'm not sure we can enable the fallback cert for specific vhosts. My filter match at the end looks for any that does not match previous filters (e.g. SNI hosts).

So in practice, if we enable this, it must be on for all vhosts unless I'm misreading the docs.

[jpeach]

So I played around with this in Envoy for a bit. I'm not sure we can enable the fallback cert for specific vhosts. My filter match at the end looks for any that does not match previous filters (e.g. SNI hosts).

So in practice, if we enable this, it must be on for all vhosts unless I'm misreading the docs.

I think that what you can do is in this final filter chain, only add the vhosts that have opted in to accepting a default certificate, #2428 (comment)

[stevesloka]

@jpeach I updated the few comments. Also, I think I figured out the routing pieces to only allow the fallback cert to be part of the specific routing chain.

[jpeach]

The API looks good to me, just need to update the name of the fallback field.

[jpeach]

I don't see this change, am I looking at the right commit?

[stevesloka]

@jpeach I updated the design after some more work today. The big changes are the needs for having a new RDS config to point the fallback domains to: https://github.com/projectcontour/contour/blob/74217e0d1bf4f6833a67282e8157ea5bc08108e5/design/fallbackcert.md#envoy-api

[ravilr]

@stevesloka two questions:

1. What about hosts and route rules configured through K8s Ingress resource? will this expose the RDS routes from ingress.spec.rules[].host configured through K8s Ingress resource under the fallback certificate TLS listener ? if not, can we enable/gate that also through a ingress annotation please?
2. this feature could be used to also resolve Feature request: support external TLS with HTTP 301 upgrades #715 where the users are TLS terminating at an external LB and having Envoy behind that LB as a trusted proxy. Such deployments could now use the fallback certificate and configure the External LB->Envoy communication over TLS listener of Envoy.

[jpeach]

@stevesloka two questions:

1. What about hosts and route rules configured through K8s Ingress resource? will this expose the RDS routes from ingress.spec.rules[].host configured through K8s Ingress resource under the fallback certificate TLS listener ? if not, can we enable/gate that also through a ingress annotation please?

Supporting Ingress is tracked in #2453