Skip to content
This repository has been archived by the owner on Aug 26, 2021. It is now read-only.

Support for same host duplicated across ingress objects #35

Open
renaudguerin opened this issue Sep 26, 2016 · 7 comments
Open

Support for same host duplicated across ingress objects #35

renaudguerin opened this issue Sep 26, 2016 · 7 comments

Comments

@renaudguerin
Copy link
Contributor

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
Copy link
Contributor

simonswine commented Sep 29, 2016

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
Copy link

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

@kilpatty
Copy link

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

@ankon
Copy link
Contributor

ankon commented Jun 19, 2017

I'm running with #142 in production, for the same use case (multiple ingress objects, each contributing parts of the whole).

@bartoszhernas
Copy link

Can someone merge #142 ?

teemow added a commit to giantswarm/happa that referenced this issue Jul 16, 2017
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
teemow added a commit to giantswarm/happa that referenced this issue Jul 16, 2017
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
@abevoelker
Copy link

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
Copy link

sjdweb commented May 14, 2018

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants