Ambassador: Ambassador Edge Stack UI shows "Configuration Error" when using TLSContext and Host together

[buehler]

Describe the bug
By the time of writing, it is not possible to configure http2 within a Host CRD in ambassador on kubernetes. The required option would be something like the alpn_protocols (then set to h2 for http2) option of the TLSContext CRD. But the Host CRD is needed for acme certificates.

The problem is, when someone wants to connect to a service through ambassador with a grpc service, and the option above is not configured, the call will be downgraded to http1.1. This can either made working by setting and enabling the grpc_11_bridge or by just using unary non streaming calls.

After some conversation with @nbkrause he suggested to use the workaround and create a Host for the acme process to get the certificate and a TLSContext for the protocol definition.

When doing this, it produces the correct envoy configuration but the Edge Stack UI yells an error at me:

It does seem to work as intended, but the ui still produces this error.

To Reproduce
Steps to reproduce the behavior:

1. Create a Host CRD with some hostname (for acme - lets encrypt - certificates)
2. Create a TLSContext CRD with the same hostname (for alpn_protocols: h2)
3. See the error in the edge stack ui under "debugging" (and the logs of course)

Expected behavior
Either allow the host to define the protocols, or don't throw errors when a tlscontext uses the same hostnames to define additional properties :-)

Versions (please complete the following information):

• Ambassador: 1.0.0
• Kubernetes environment: bare metal
• Version 1.17.0

[adriangudas]

I'm experiencing a similar issue when trying to use a Host CRD to take advantage of the LetsEncrypt automation, but also trying to lock down the min_tls_version to v1.2 which is required to get an "A" score on SSLabs (https://www.ssllabs.com/). The min_tls_version directive is set in a TLSContext, but doesn't appear to be getting read (verifiable with curl --tlsv1.1 still passing).

Once I move the entire TLS configuration over to the TLSContext, including secrets, and then set ACME to 'none', it starts honouring the min_tls_version setting, but then I've lost certificate renewals via LetsEncrypt.

It doesn't seem possible to use both a Host CRD to automate LetsEncrypt, and also use a TLSContext for additional configuration such as min_tls_version, which is implied in the doc. Unless I'm missing something (which is possible - and someone please let me know if they have this working).

[conblem]

Same here

[fforootd]

some could say we see the same 😁

[HunterLarco]

+1 this is frusterating

[buehler]

@HunterLarco meanwhile...

I guess the did some implementation on this topic, but did not mention it.

Sadly enough it's a "naming convention" thingy:
https://www.getambassador.io/docs/latest/topics/running/tls/#hostand-tlscontext

So, I tested it.

If you use a host with the name foobar-host and then use the context with the name foobar-host-context, the error is gone and everything is correctly configured.

Thanks to @conblem for the nudge into the right direction.

But I wonder if the ambassador devs are changing something on this matter?

/cc @fforootd

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.