Support for same host duplicated across ingress objects

[renaudguerin]

Hi,

For various reasons I need to have the different paths for a host spread across different ingress objects (mainly to enable http basic-auth on some paths only, since there's no way to set this at the "rule" level and it can only be done using ingress-level annotations)

I couldn't find a way to make kube-lego play nice with this. I do want to share the same certificate/secret for the same host across these different ingress objects, but it complains with : the secret xxxxxx/default is used multiple times. These linked TLS ingress elements where ignored:

And it then ignores all TLS ingress elements, not just additional duplicates but even the first definition it encounters.

Is there a workaround I'm missing ? Could kube-lego handle duplicates more gracefully maybe (gather the list of hosts/secrets needed across all ingresses, de-duplicate if needed, and request) ?

[simonswine]

I was just scared by the complexity of implementing this. It should not be that hard after all, as we are assessing the host information as aggregated information once a change happens. But not exactly a priority for me...

[bartoszhernas]

Does it also skip certificates renewal? I am having the same problem :(

[kilpatty]

Any update on this? Or any place I can help implement it?

[ankon]

I'm running with https://github.com/jetstack/kube-lego/pull/142 in production, for the same use case (multiple ingress objects, each contributing parts of the whole).

[bartoszhernas]

Can someone merge #142 ?

[abevoelker]

Just ran into this today. GKE requires running two separate Ingresses for handling IPv4 and IPv6 traffic, so there are valid scenarios that this overzealous protection is breaking. Guess I'll try cert-manager or #142.

[sjdweb]

I've just hit this when the certificate expired. I've set the newer ingress to use a different secret and kube-lego seems to have sorted this out (they are the same host). Are there any risks doing this?