Allow Contour to work with Opaque secret as long as it contains tls.crt and tls.key

[tsaarni]

I would like Contour to accept secrets that are type Opaque as long as the secret has required fields: tls.crt and tls.key. Currently Contour checks for the validity of secrets by:

1. check that the secret contains fields: tls.crt and tls.key
2. check that the type field is set to kubernetes.io/tls

Having the type check (2) is not necessary for the secret to work - it is redundant and I would like to propose removing it. I do not propose any documentation changes - the type kubernetes.io/tls should still be recommended. According to the good old robustness principle ("Be conservative in what you do, be liberal in what you accept from others") Contour could work with other types as well as long as it contains the required certificate and key fields checked in (1).

The use case for this change is to allow referring to secret that was created as Opaque using something like kubectl create secret generic mycert --from-file=tls.crt --from-file=tls.key --from-file=ca.crt. The secret is not exactly conforming to the kubernetes.io/tls but would work if the additional check (2) was removed.

The topic is also discussed at Slack https://kubernetes.slack.com/archives/C8XRH2R4J/p1607344706059900

[skriss]

That seems OK to me, 👍.

Note that there's another similar but different validity check for secrets that gets called before adding a secret to the Contour cache of Kubernetes objects. I'm not totally clear on why there are two separate functions for this; it'd be nice to de-dupe if possible. Perhaps another maintainer has more context than me :)

[jpeach]

Mixed feelings about this (since IIRC I added the check). If nothing looks at the type, what's the point of it? If the type id consistently used and required, maybe that's helpful for an auditing or access control, but OTOH if there's no enforcement then there's no way to get consistent behavior.

[youngnick]

When we talked about this originally, I'm pretty sure it was just because that was the standard way to represent TLS details in Kubernetes. I think I'm okay with allowing this as long as we're clear that Secrets of type kubernetes.io/tls automatically meet the key requirements.