-
Notifications
You must be signed in to change notification settings - Fork 264
Support for same host duplicated across ingress objects #35
Comments
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... |
Does it also skip certificates renewal? I am having the same problem :( |
Any update on this? Or any place I can help implement it? |
I'm running with #142 in production, for the same use case (multiple ingress objects, each contributing parts of the whole). |
Can someone merge #142 ? |
make sure that if requests are terminated in the ingress controller via letsencrypt the service runs via http. architect is currently replacing the SHAs in our helm charts. it's hardcoded that architect will template files called deployment.yaml. this is why i renamed the deployment.yaml to happa-deployment.yaml. the problem is now that architect doesn't replace the SHA anymore. so helm doesn't apply this against the cluster anymore. the temporary fix is to install the latest version of happa image. also distinguish lego secrets by a name. otherwise lego complains about the duplicate ingresses. ``` the secret giantswarm/ is used multiple times. These linked TLS ingress elements where ignored: ingress giantswarm/api (hosts: api.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/desmotes (hosts: desmotes.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/happa (hosts: happa.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/passage (hosts: passage.g8s.heisenberg.eu-central-1.aws.gigantic.io) ``` See: jetstack/kube-lego#35
make sure that if requests are terminated in the ingress controller via letsencrypt the service runs via http. architect is currently replacing the SHAs in our helm charts. it's hardcoded that architect will template files called deployment.yaml. this is why i renamed the deployment.yaml to happa-deployment.yaml. the problem is now that architect doesn't replace the SHA anymore. so helm doesn't apply this against the cluster anymore. the temporary fix is to install the latest version of happa image. also distinguish lego secrets by a name. otherwise lego complains about the duplicate ingresses. ``` the secret giantswarm/ is used multiple times. These linked TLS ingress elements where ignored: ingress giantswarm/api (hosts: api.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/desmotes (hosts: desmotes.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/happa (hosts: happa.g8s.heisenberg.eu-central-1.aws.gigantic.io), ingress giantswarm/passage (hosts: passage.g8s.heisenberg.eu-central-1.aws.gigantic.io) ``` See: jetstack/kube-lego#35
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. |
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? |
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) ?
The text was updated successfully, but these errors were encountered: