contour: Contour should set a status message when an ingressroute references an invalid secret

What steps did you take and what happened:

created a secret of type kubernetes.io/dockerconfigjson
referenced unexpected secret type in Ingress specification for TLS configuration
received error message in logs

contour-6bdd96f88-ftrfp envoy [2019-06-13 05:03:08.569][000001][warning][config] [bazel-out/k8-opt/bin/source/common/config/_virtual_includes/grpc_mux_subscription_lib/common/config/grpc_mux_subscription_impl.h:70] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Proto constraint validation failed (ListenerValidationError.FilterChains[i]: ["embedded message failed validation"] | caused by FilterChainValidationError.TlsContext: ["embedded message failed validation"] | caused by DownstreamTlsContextValidationError.CommonTlsContext: ["embedded message failed validation"] | caused by CommonTlsContextValidationError.TlsCertificates[i]: ["embedded message failed validation"] | caused by TlsCertificateValidationError.CertificateChain: ["embedded message failed validation"] | caused by field: "specifier", reason: is required): name: "ingress_https"

What did you expect to happen: Error message in logs

secret namespace/name was malformed and unable to be loaded as a TLS listener

Environment:

Contour version: v0.11.0
Kubernetes version: (use kubectl version): v1.14.2
Kubernetes installer & version: kind v0.4.0-alpha
Cloud provider or hardware configuration: local
OS (e.g. from /etc/os-release): osx

Blocked:

All the issues we have about status

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (11 by maintainers)

Commits related to this issue

internal/e2e: assert that invalid certificates are not served via SDS Updates #1169 Signed-off-by: Dave Cheney <dave@cheney.net> — committed to davecheney/contour by davecheney 5 years ago

Most upvoted comments

Thanks for the update.

The problem with reporting an error on a malformed secret is where to do so,

Logging to contour’s stdout is the obvious place but this has several drawbacks.

those logs may not be accessible to the end user, they may not have permission to tail the logs of a container in the heptio-contour namespace.
these logs are likely to be verbose as a naïve implementation will emit a long line every time contour goes through a configuration rebuild cycle — read potentially any time something related to ingress changes in the api server.

The better place to put this information would be in the status field of a k8s object. The problem is secret has no status field that I know of. This leaves the ingress or ingressroute object itself. I think this is the best place to report a malformed secret.

Sadly status updating has been a sore point for contour for a long time. We plan to fix it, but this is blocked on work scheduled for 0.14 so the soonest we could deliver this feature is 0.15.

On 27 Jun 2019, at 03:20, shabx notifications@github.com wrote:

@davecheney , I brought your question with @pickledrick - Peter confirmed that checking in Contour versions > 0.12.1 is more strict and Contour and does not pass the object to Envoy so we don’t see the error returned from Envoy.

We have updated the ticket and told the customer if this is good enough. It looks like they were looking for a proper error message in the logs when there is a malformed secret reference. We can’t close the issue yet.

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

davecheney on Jun 27, 2019