Ambassador: Support multiple TLS certificates via SNI

[plombardi89]

Ambassador supports a single TLS certificate but I need to support multiple TLS certificates where we use different domains for different types of services.

*.kubernaut.io is for Kubernaut

scout.datawire.io is needed for another service.

We have other services coming down the pipeline that will also need to be able to be under a different domain and therefore require another TLS wildcard certificate.

[plombardi89]

Decided to do a little Googling... this might be a necessary prerequisite https://github.com/envoyproxy/envoy/issues/95

[pgold30]

Hi @plombardi89 , i see that the ticket you mention has been closed on Dec 2017 , and envoy support tls: added SNI support. from version 1.5 ( https://www.envoyproxy.io/docs/envoy/latest/intro/version_history#id1 ) Is there and estimated for this, or is even in the roadmap? we really need this feature to work with several certificates.

[kflynn]

This issue pretty much requires #463.

[adrianchifor]

Is anyone working on this? If not I can take a look; need this feature before we can take ambassador into prod.

[kflynn]

@adrianchifor #463 will be in Ambassador 0.36.0, which is coming up. If you want to take a look at SNI in Envoy, that would be wonderful. :smile: Are you in the Ambassador Slack already? https://d6e.co/slack

[jazoom]

Is there any way to work around this for the time being? I didn't realise Ambassador couldn't handle more than one TLS certificate/domain. And as others have said, this is required for using it in production.

[richarddli]

SNI is a high priority item (we're doing a bunch of internal work on a branch which is a precursor to SNI, among other things). In the meantime, you can run multiple ambassadors (see https://www.getambassador.io/reference/running#multiple-ambassadors-in-one-cluster) and give each ambassador a unique secret.

[jazoom]

I thought of something like that but didn't realise you had the ID system built in. I didn't go with this method because then I'd need an SNI reverse proxy to route to the correct Ambassador anyway, so I may as well just stick a TLS-terminating Nginx in front as a sidecar to handle port 443.

Or is the SNI reverse proxy not required if using the Ambassador ID? If traffic destined for https://example.com (ID 1) hits Ambassador with ID 2 (which has the cert for https://notexample.com), will it forward the traffic onto Ambassador with ID 1 to terminate the TLS appropriately?

[concaf]

Talking about the syntax to configure SNI via ambassador, we can let the end users to configure it using secrets or files, pretty similar to how they configure in the TLS module; just that they'd do it in mappings now.

This needs to be per mapping because the certs will tie themselves with the given envoy filter which is configured in a mapping.

• Secret -

      ---
      apiVersion: ambassador/v0
      kind:  Mapping
      name:  httpbin-mapping
      prefix: /httpbin/
      service: httpbin
      tls:
        servers:
        - example.com
        - www.example.com
        secret: httpbin-secret

• Filenames -

      ---
      apiVersion: ambassador/v0
      kind:  Mapping
      name:  httpbin-mapping
      prefix: /httpbin/
      service: httpbin
      tls:
        servers:
        - example.com
        - www.example.com
        cert_chain_file: /etc/certs/tls.crt
        private_key_file: /etc/certs/tls.key

Thoughts? @rhs @kflynn

References:

• https://www.envoyproxy.io/docs/envoy/latest/faq/sni

[kflynn]

Done in EA5. Further Kat work tracking in #814.